Re: NETIF_F_FRAGLIST and NETIF_F_SG difference

[David Miller <davem@davemloft.net>]

From: Ben Hutchings <bhutchings@solarflare.com>
Date: Tue, 02 Mar 2010 02:51:58 +0000

> On Mon, 2010-03-01 at 17:40 -0800, David Miller wrote:
>> From: Ben Hutchings <bhutchings@solarflare.com>
>> Date: Mon, 01 Mar 2010 12:58:41 +0000
>> 
>> > (I don't know why there are two ways of adding extra data.  The latter
>> > does not seem to be used often.)
>> 
>> It's the most efficient way to handle IPv4/IPv6 fragmentation and
>> reassembly.
> 
> But fragmentation results in a series of packets to be transmitted
> separately (not gathered) and reassembly is only done at endpoints.  So
> when would we see a fragment list on the transmit path?

If the device indicates it can take the set of fragments as a bundle,
with only one IP header at the front, instead of individual fully
header'd IP frames.

This was the original intention of what this net device feature flag
was to be used for.

The device does all of the IP header creation for the individual
frames, bumping the fragment ID and flags, etc.  Just like it does
for TSO.

Some broadcom chips can do this, if I recall correctly.

But that never materialized.  Instead it now simply means that
the frag list based linkage is supported, and the packet is an
entire fully formed frame.

GSO/GRO makes use of the current interpretation so that the it's
bundles can be passed around efficiently from RX to TX.  Mostly the
feature bit is set by layered and virtualization devices.