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 =A0and 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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Ben Hutchings]

Post by 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. */

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

Post by raj ravi
#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.

[David Miller]

From: Ben Hutchings <***@solarflare.com>
Date: Mon, 01 Mar 2010 12:58:41 +0000

Post by Ben Hutchings
(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.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Ben Hutchings]

Post by David Miller
Date: Mon, 01 Mar 2010 12:58:41 +0000

Post by Ben Hutchings
(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.

[David Miller]

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

Post by Ben Hutchings

Post by David Miller
Date: Mon, 01 Mar 2010 12:58:41 +0000

Post by Ben Hutchings
(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.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html