Re: TSO + ECN
- In reply to: Scheffenegger, Richard: "TSO + ECN"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 20 Dec 2023 12:27:06 UTC
> On Dec 20, 2023, at 12:15, Scheffenegger, Richard <rscheff@freebsd.org> wrote: > > Hi, > > I am curious if anyone here has expirience with the handling of ECN in TSO-enabled drivers/hardware... Some data pointer if I read the specification correctly. Have a look at the specification of the 10GBit/sec card ix: https://cdrdv2-public.intel.com/331520/82599-datasheet-v3-4.pdf According to section 7.2.4 and 8.2.3.9.3 and 8.2.3.9.4 the * first segment gets all flags except PSH and FIN. * middle segments get all flags except PSH and FIN. * last segment gets all flags except the CWR. I think you should be able to change the masks. Best regards Michael > > The other day I found that the virtio driver would bail out with ENOTSUP when encountering the TCP CWR header bit on a TSO-enabled flow, when the host does not also claim ECN-support for TSO. > > But this made me wonder, how the expected behavior is. > > Presumably, this means that the hardware (or driver) would clear the CWR bit after the first packet is sent, correct? > > However, in light of the upcoming AccECN signalling protocol, that is not what TSO should be doing (with AccECN, all segments should retain the exact same header flags, maybe expect PSH). > > Probably "non-ECN" capable TSO offload would actually work better with AccECN - and if the above behavior is what ECN-aware TSO is doing, AccECN sessions would need to somehow work around that (e.g. spoon-feeding any segment with CWR set individually - e.g. bypassing the TSO capabilities in tcp_output)? > > > Would appreciate any feedback around this... > > Best regards, > Richard > <OpenPGP_0x17BE5899E0B1439B.asc>