Increasing TCP TSO size support

"Scheffenegger, Richard" <[email protected]>
Newsgroups gmane.os.freebsd.devel.transport,gmane.os.freebsd.devel.net
Message-ID <[email protected]>
Hi,

We have run a test for a RPC workload with 1MB IO sizes, and collected 
the tcp_default_output() len(gth) during the first pass in the output loop.

In such a scenario, where the application frequently introduces small 
pauses (since the next large IO is only sent after the corresponding 
request from the client has been received and processed) between sending 
additional data, the current TSO limit of 64kB TSO maximum (45*1448 in 
effect) requires multiple passes in the output routine to send all the 
allowable (cwnd limited) data.

I'll try to get a data collection with better granulariy above 90 000 
bytes - but even here the average strongly indicates that a majority of 
transmission opportunities are in the 512 kB area - probably also having 
to do with LRO and ACK thinning effects by the client.

With other words, the tcp output has to run about 9 times with TSO, to 
transmit all elegible data - increasing the FreeBSD supported maximum 
TSO size to what current hardware could handle (256kB..1MB) would reduce 
the CPU burden here.


Is increasing the sofware supported TSO size to allow for what the NICs 
could nowadays do something anyone apart from us would be interested in 
(in particular, those who work with the drivers)?


Best regards,

   Richard




tso size (transmissions < 1448 would not be accounted here at all)

                     # count

<1000 	0
<2000 	23
<3000 	111
<4000 	40
<5000 	30
<7000 	14
<8000 	134
<9000 	442
<10000 	9396
<20000 	46227
<30000 	25646
<40000 	33060
<60000 	23162
<70000 	24368
<80000 	19772
<90000 	40101
 >=90000 	75384169
Average: 	578844.44
OpenPGP_0x17BE5899E0B1439B.asc (application/pgp-keys, 677 B)
-----BEGIN PGP PUBLIC KEY BLOCK-----

xjMEY/i74RYJKwYBBAHaRw8BAQdAwtnvjlFVnnzNXO9hjHtB6MPGSY19L/BHh/iz
iPF0FzrNK1JpY2hhcmQgU2NoZWZmZW5lZ2dlciA8cnNjaGVmZkBmcmVlYnNkLm9y
Zz7CmgQTFgoAQhYhBDZLt5msg0Ras820cRe+WJngsUObBQJj+LvhAhsDBQkJZgGA
BQsJCAcCAyICAQYVCgkICwIEFgIDAQIeBwIXgAAKCRAXvliZ4LFDm4ylAQCSw2/n
vht8kExJ31M+3qpjOqdVypMp+/Ojvh5Zlsk96QEA5HCBkteJcrohwRA7llZvLH3m
25hcJdzmDh39mc0cSgPOOARj+LvhEgorBgEEAZdVAQUBAQdA1Dim8ZWpXRS5i9hb
3O4RNHub8XvqTTkYyiZ2lSkXDwYDAQgHwn4EGBYKACYWIQQ2S7eZrINEWrPNtHEX
vliZ4LFDmwUCY/i74QIbDAUJCWYBgAAKCRAXvliZ4LFDm2TGAQDcg+bAEPqOH+JC
IND8wZ62MwnjFyXFv73qevXkUHHNSgEApUgpHW9f6UaIAQpc3R185xjz6tk8XXBx
eYpxKgIAeQ8=
=BwxS
-----END PGP PUBLIC KEY BLOCK-----
OpenPGP_signature.asc (application/pgp-signature, 236 B)
-----BEGIN PGP SIGNATURE-----

wnsEABYIACMWIQQ2S7eZrINEWrPNtHEXvliZ4LFDmwUCZby0KgUDAAAAAAAKCRAXvliZ4LFDm73n
AQC00+GZ7IDDzaPlORXmsNmMrrKgmFRT/rH6+MIpnbvA8AEA+130h9m/ksyrLjAOFWgXqG68ByH7
+gaZN4mhV5Q13Q0=
=QnaZ
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.