Ben Hutchings [off-list ref] writes:

On Mon, 2013-06-17 at 11:05 +0930, Rusty Russell wrote:

quoted

I thought LRO was deprecated and GRO was the new hotness, but I haven't
been following.  Do we still care about LRO?

The old software LRO implementation, inet_lro, is deprecated in favour
of GRO and is now only used by one or two drivers.  Hardware/firmware
implementations of LRO are still in use and not deprecated, but we try
to disable them on devices for which forwarding is enabled because of
this information loss.

Right, thanks for the clarification.

Hardware implementations of LRO which can't meet GRO rules are only
semi-useful, and that should be fed back to vendors.  Hard.

The problem I was talking about is this: you can put macvlan on top of a
device that has LRO enabled, and then if the macvtap/macvlan device is
used for forwarding the output packets might not look the same as those
originally received.  So LRO should be disabled on the underlying device
whenever forwarding is enabled on the macvtap/macvlan device; however we
can't necessarily tell when that happens as the forwarding might be done
inside a VM.  Maybe this is just too obscure a use case to worry much
about getting it right automatically.

The VM needs to tell us it's OK with such mangling, otherwise we
shouldn't do it (at least by default).  The same way we'd be annoyed if
a card rev started doing LRO without the driver explicitly enabling it.

Cheers,
Rusty.