> 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? Just to relate to bnx2x/qede differences in current implementation - when this GRO hw-offload was added to bnx2x, it has already supported classical LRO, and due to above statement whenever LRO was set driver aggregated incoming traffic as classic LRO. I agree that in hindsight the lack of distinction between sw/hw GRO was hurting us. qede isn't implementing LRO, so we could easily mark this feature under LRO there - but question is, given that the adapter can support LRO, if we're going to suffer from all the shotrages that arise from putting this feature under LRO, why should we bother? You can argue that we might need a new feature bit for control over such a feature; If we don't do that, is there any gain in all of this?
