Ease up, Joe - just ease up.
> -----Original Message----- > From: Int-area [mailto:[email protected]] On Behalf Of > [email protected] > Sent: Thursday, January 27, 2022 3:44 PM > To: Tom Herbert <[email protected]> > Cc: [email protected] > Subject: [EXTERNAL] Re: [Int-area] IP parcels > > EXT email: be mindful of links/attachments. > > > > Hi, Tom, > > > On Jan 27, 2022, at 2:46 PM, Tom Herbert <[email protected]> wrote: > > > > 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 > > Ubiquitously deployed Linux kernel software at one point had a bug that > failed to lock the inode structure during modification. Uniquity > didn’t make that magically correct. > > >> 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. > > That’s not how open source works. > > The onus is on those who currently maintain the code to ensure it complies > with current protocols. I noted that I and others have > experience that it doesn’t. > > It is not the responsibility of the user community to fix their bugs or > ensure that their approach remains viable. > > > 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. > > None of that has anything to do with the issue I raised. > > Both hardware and software implementations of these optimizations MUST > strictly comply with protocol specs. When they encounter > options they don’t know, it’s not their prerogative to do anything beyond > “disable” for that stream. That’s not our experience, though. > > Joe > > _______________________________________________ > 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
