> On Dec 20, 2023, at 12:15, Scheffenegger, Richard <rsch...@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>
