NETIF_F_FRAGLIST and NETIF_F_SG difference

NETIF_F_FRAGLIST and NETIF_F_SG difference

[raj ravi]

Hi,
http://lxr.linux.no/#linux+v2.6.33/include/linux/netdevice.h
In include/linux/netdevice.h I can see two definiton for "Scatter
Gather IO" namely NETIF_F_FRAGLIST  and NETIF_F_SG

Please let me know the difference between the two.... if there is no
difference why two Macros ??


#define NETIF_F_SG 1 /* Scatter/gather IO. */
#define NETIF_F_IP_CSUM 2 /* Can checksum TCP/UDP over IPv4. */
#define NETIF_F_NO_CSUM 4 /* Does not require checksum. F.e. loopack. */
#define NETIF_F_HW_CSUM 8 /* Can checksum all the packets. */
#define NETIF_F_IPV6_CSUM 16 /* Can checksum TCP/UDP over IPV6 */
#define NETIF_F_HIGHDMA 32 /* Can DMA to high memory. */
#define NETIF_F_FRAGLIST 64 /* Scatter/gather IO. */

Thx!
Kavi

Re: NETIF_F_FRAGLIST and NETIF_F_SG difference

[Ben Hutchings]

On Mon, 2010-03-01 at 16:32 +0530, raj ravi wrote:
> Hi,
> http://lxr.linux.no/#linux+v2.6.33/include/linux/netdevice.h
> In include/linux/netdevice.h I can see two definiton for "Scatter
> Gather IO" namely NETIF_F_FRAGLIST  and NETIF_F_SG
> 
> Please let me know the difference between the two.... if there is no
> difference why two Macros ??
> 
> 
> #define NETIF_F_SG 1 /* Scatter/gather IO. */

This means the device can transmit an skb with extra data attached
through skb_shinfo(skb)->frags.

> #define NETIF_F_IP_CSUM 2 /* Can checksum TCP/UDP over IPv4. */
> #define NETIF_F_NO_CSUM 4 /* Does not require checksum. F.e. loopack. */
> #define NETIF_F_HW_CSUM 8 /* Can checksum all the packets. */
> #define NETIF_F_IPV6_CSUM 16 /* Can checksum TCP/UDP over IPV6 */
> #define NETIF_F_HIGHDMA 32 /* Can DMA to high memory. */
> #define NETIF_F_FRAGLIST 64 /* Scatter/gather IO. */

This means the device can transmit an skb with extra data attached
through skb->frags.

(I don't know why there are two ways of adding extra data.  The latter
does not seem to be used often.)

Note that these flags really refer only to DMA gather.  There is no need
for a feature flag for DMA scatter, since the driver controls RX buffer
allocation.

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

Re: NETIF_F_FRAGLIST and NETIF_F_SG difference

[David Miller]

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.

Re: NETIF_F_FRAGLIST and NETIF_F_SG difference

[Ben Hutchings]

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?

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

Re: NETIF_F_FRAGLIST and NETIF_F_SG difference

[David Miller]

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.