>> Claiming that hardware assist GRO is not possible is a plain mantra.
> I have no issue claiming hardware assist GRO is possible. My problem > is saying that the GRO feature flag can be used to enable it. I would > argue that any packet aggregation at the device or driver level is LRO > regardless of how close it comes to GRO feature wise. GRO should only > be occurring in the receive path after calling the appropriate GRO > function. Otherwise it becomes really difficult to work around any > possible issues that the hardware assisted GRO introduces without > paying a huge penalty. We need to keep these feature flags separate. > I thought that was the whole reason why we have the distinction > between LRO and GRO in the first place. Then again, if you're basically saying every HW-assisted offload on receive should be done under LRO flag, what would be the use case where a GRO-assisted offload would help? I.e., afaik LRO is superior to GRO in `brute force' - it creates better packed packets and utilizes memory better [with all the obvious cons such as inability for defragmentation]. So if you'd have the choice of having an adpater perform 'classic' LRO aggregation or something that resembles a GRO packet, what would be the gain from doing the latter?
