On Thu, Jan 27, 2022 at 2:17 PM [email protected] <[email protected]> wrote: > > FWIW, GRO/GSO give no end of headaches to the idea of new TCP options, esp. > the current ones to extend option space after the SYN > (draft-ietf-tcpm-tcp-edo).
GRO and GSO are software implementations and in most deployments > > Although I appreciate their zeal for optimization, implementers of GRO/GSO > still need to play by the rules of TCP and UDP. It’s not clear they are > (e.g., coalescing packets with different unknown options), and when they > don’t, I want to be clear that it is they that are the problem. > Joe, GRO and GSO are software implementations in kernel networking stacks and in most cases these are open source projects of Linux or FreeBSD. If they have flaws or there's areas for improvement, then by all means submit patches to the respective project-- that, after all, is the whole premise of an open source project. The hardware cognates, TSO and LRO, do tend to be more closed and for this reason they haven't gotten much traction-- TSO has seen a some amount of deployment, but LRO hasn't because of the problems of putting fairly complex algorithms in hardware. That problem is addressed once we have sufficiently programmable hardware so the stack can program things like GSO and GRO in hardware as easily in hardware and of course this should be done in ubiquitous open source that works across all hardware vendors. Tom > I agree that the common Unix socket interface has performance flaws, but > perhaps it’s that interface that needs to evolve. > > Joe > > — > Joe Touch, temporal epistemologist > www.strayalpha.com > > On Jan 27, 2022, at 1:29 PM, Behcet Sarikaya <[email protected]> wrote: > > Hi Folks, > > Thanks Christian for explaining how GSO/GRO are used by Quic implementations. > So the use is not mandated in Quic RFCs but rather used in implementations. > > > _______________________________________________ > Int-area mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
