On Fri, Dec 29, 2017 at 7:12 AM, Alexander Duyck <alexander.du...@gmail.com> wrote: > On Fri, Dec 29, 2017 at 4:43 AM, Sabrina Dubroca <s...@queasysnail.net> wrote: >> 2017-12-22, 10:14:32 -0800, Alexander Duyck wrote: >>> On Fri, Dec 22, 2017 at 6:57 AM, Sabrina Dubroca <s...@queasysnail.net> >>> wrote: >>> > IIUC, with the patches that were applied, each driver can define >>> > whether GRO_HW depends on GRO? From a user's perspective, this >>> > inconsistent behavior is going to be quite confusing. >>> > >>> > Worse than inconsistent behavior, it looks like a driver deciding that >>> > GRO_HW doesn't depend on GRO is going to introduce a change of >>> > behavior. Previously, when GRO was disabled, there wouldn't be any >>> > packet over MTU handed to the network stack. Now, even if GRO is >>> > disabled, GRO_HW might still be enabled, so we might get over-MTU >>> > packets because of hardware GRO. >>> >>> This isn't actually true. LRO was still handling packets larger than >>> MTU over even when GRO was disabled. >> >> Sure, LRO will also cause that, but we're speaking in the context of >> GRO here, which means no LRO. > > We are talking about GRO_HW. Which is basically aggregation being > performed in hardware. The choice of name is unfortunate though since > it implies this is GRO when what is actually happening is just > GRO-like. Really the only difference between LRO and GRO_HW is that > the frames are better formed in the final result. It is a matter of > what is performed versus where it is performed.
I think the name GRO_HW is perfectly fine. It is GRO aggregation done in hardware, and hardware providing extra information to the driver to setup the SKB just like GRO. I don't know what better name to call it than GRO_HW.
