Date: Mon, 11 Jun 2007 21:35:28 +0200 From: Andre Oppermann <andre@freebsd.org> To: Scott Long <scottl@samsco.org> Cc: cvs-src@FreeBSD.org, Andrew Gallatin <gallatin@FreeBSD.org>, cvs-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/sys mbuf.h src/sys/net if_ethersubr.c src/sys/dev/mxge mxge_lro.c Message-ID: <466DA400.6000003@freebsd.org> In-Reply-To: <466D9D94.1020908@samsco.org> References: <200706111459.l5BExvTp020932@repoman.freebsd.org> <466D9BBB.1060601@freebsd.org> <466D9D94.1020908@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Scott Long wrote: > Andre Oppermann wrote: >> Andrew Gallatin wrote: >>> gallatin 2007-06-11 14:59:56 UTC >>> >>> FreeBSD src repository >>> >>> Modified files: >>> sys/sys mbuf.h sys/net >>> if_ethersubr.c sys/dev/mxge mxge_lro.c Log: >>> Allow drivers, such as cxgb and mxge, which support LRO to bypass >>> the MTU check in ether_input() on LRO merged frames. >>> Discussed with: kmacy >> Not discussed with: andre >> >> Your change isn't the right way to make this work. LRO is an interface >> capability (that should have the option to disable it) and the test in >> ether_input() should go on that instead. LRO is not an information >> that is needed beyond ether_input() and thus doesn't have to be a mbuf >> flag. >> >> I've indicated that I'm working in this area as well and at least >> dropping an email or a ping IRC would have been nice. I would have >> told you the above right away. My common version of LRO isn't ready >> yet as I'm a bit short on time and I chose to concentrate on TCP it- >> self. We only have to make sure that we don't exclude a common LRO >> implementation due to API/ABI issues for 7.1R. >> > > Drew's commit looks simple and non-obtrusive enough that it can likely > be replaced once your perfected LRO implementation is done and in the > tree. Until that happens, I can't imagine a good reason to block his > and Kip's work. I'm blocking nothing. Read again what I wrote. I complained about a technically wrong approach to solve a particular side problem. In the meantime it got backed out because someone else complained too. -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?466DA400.6000003>