I am thinking of implementing harware scatter/gatter support( NETIF_F_SG) in my
ethernet driver. The network device cannot do HW checksuming.
Will the IP stack make use of the SG support and will there be any significant performance
improvement?
Jocke
Joakim Tjernlund wrote:
> I am thinking of implementing harware scatter/gatter support( NETIF_F_SG) in my
> ethernet driver. The network device cannot do HW checksuming.
>
> Will the IP stack make use of the SG support and will there be any significant performance
> improvement?
No; you need HW checksumming for NETIF_F_SG to be useful.
If HW checksumming is not available, scatter-gather is useless, because
the net stack must always make a pass over the data to checksum it.
Since it must do that, it can linearize the skb at the same time,
eliminating the need for SG.
Jeff
> Joakim Tjernlund wrote:
> > I am thinking of implementing harware scatter/gatter support( NETIF_F_SG) in my
> > ethernet driver. The network device cannot do HW checksuming.
> >
> > Will the IP stack make use of the SG support and will there be any significant performance
> > improvement?
>
>
> No; you need HW checksumming for NETIF_F_SG to be useful.
>
> If HW checksumming is not available, scatter-gather is useless, because
> the net stack must always make a pass over the data to checksum it.
> Since it must do that, it can linearize the skb at the same time,
> eliminating the need for SG.
>
> Jeff
linearize = copy small buffers inte one big buffer, or?
Surley the copy operation will cost something?
Jocke
Joakim Tjernlund <[email protected]> :
[...]
> Surley the copy operation will cost something?
Cost is hidden while checksumming.
--
Ueimor
> Joakim Tjernlund <[email protected]> :
> [...]
> > Surley the copy operation will cost something?
>
> Cost is hidden while checksumming.
>
> --
> Ueimor
Yes, I realize that you can make the cost much smaller by checksumming and
copying at the same time. However for every word that is checksummed one must
execute an extra store. That store will also hit the L1 cache, flushing more
important data to memory, so maybe the cost is visible?
Jocke
> Joakim Tjernlund wrote:
> > I am thinking of implementing harware scatter/gatter support( NETIF_F_SG) in my
> > ethernet driver. The network device cannot do HW checksuming.
> >
> > Will the IP stack make use of the SG support and will there be any significant performance
> > improvement?
>
>
> No; you need HW checksumming for NETIF_F_SG to be useful.
>
> If HW checksumming is not available, scatter-gather is useless, because
> the net stack must always make a pass over the data to checksum it.
> Since it must do that, it can linearize the skb at the same time,
> eliminating the need for SG.
>
> Jeff
I think HW checksumming and SG are independent. Either one of them should
not require the other one in any context.
Zero copy sendfile() does not require HW checksum to do zero copy, right?
If HW checksum is present, then you get some extra performance as a bonus.
(hmm, one could make SG mandatory and the devices that don't support it can
implement it in their driver. Just an idea)
Jocke
On Sun, 2 Feb 2003 02:39:41 +0100, Joakim Tjernlund <[email protected]> wrote:
>
> I think HW checksumming and SG are independent. Either one of them should
> not require the other one in any context.
They should be independent in general, but they aren't when the particular
case of TCP/IPv4 is concerned.
> Zero copy sendfile() does not require HW checksum to do zero copy, right?
Wrong...
> If HW checksum is present, then you get some extra performance as a bonus.
You get zerocopy, yes. :-) No HW cksum, no zerocopy.
Don't let this stop you, however. It's always possible that other networking
stacks will eventually make use of SG while not requiring HW TCP/UDP cksums.
None of them do right now, but...
> (hmm, one could make SG mandatory and the devices that don't support it can
> implement it in their driver. Just an idea)
Not really, that way lies driver madness. The less complexity in the driver,
the better.
Ion
[starfire driver maintainer]
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
> On Sun, 2 Feb 2003 02:39:41 +0100, Joakim Tjernlund <[email protected]> wrote:
> >
> > I think HW checksumming and SG are independent. Either one of them should
> > not require the other one in any context.
>
> They should be independent in general, but they aren't when the particular
> case of TCP/IPv4 is concerned.
>
> > Zero copy sendfile() does not require HW checksum to do zero copy, right?
>
> Wrong...
>
> > If HW checksum is present, then you get some extra performance as a bonus.
>
> You get zerocopy, yes. :-) No HW cksum, no zerocopy.
OK, but it should be easy to remove HW cksum as a condition to do zerocopy?
>
> Don't let this stop you, however. It's always possible that other networking
> stacks will eventually make use of SG while not requiring HW TCP/UDP cksums.
> None of them do right now, but...
zerocopy without requiring HW cksums only OR could for instance the forwarding
procdure also benefit from SG without requiring HW cksums?
>
> > (hmm, one could make SG mandatory and the devices that don't support it can
> > implement it in their driver. Just an idea)
>
> Not really, that way lies driver madness. The less complexity in the driver,
> the better.
Just a wild idea, forget it. You are right
Joakim
>
> Ion
> [starfire driver maintainer]
On Mon, 3 Feb 2003, Joakim Tjernlund wrote:
> > You get zerocopy, yes. :-) No HW cksum, no zerocopy.
>
> OK, but it should be easy to remove HW cksum as a condition to do zerocopy?
Nope. You're looking at this the wrong way: the goal is not zero copy, but
zero data access by CPU. Once you realize that, it's clear that SG alone
is no good.
This is not necessarily the only approach, but it is the current approach
in the Linux IPv4 stack. It's not worth the effort to re-engineer the code
in order to support the fast-disappearing hardware which supports SG but
not cksums.
> zerocopy without requiring HW cksums only OR could for instance the forwarding
> procdure also benefit from SG without requiring HW cksums?
The forwarding procedure is already dealing with linear buffers because
99.99% of the network cards on the market receive packets into one linear
buffer. So again SG is useless for that.
Ion
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
> On Mon, 3 Feb 2003, Joakim Tjernlund wrote:
>
> > > You get zerocopy, yes. :-) No HW cksum, no zerocopy.
> >
> > OK, but it should be easy to remove HW cksum as a condition to do zerocopy?
>
> Nope. You're looking at this the wrong way: the goal is not zero copy, but
> zero data access by CPU. Once you realize that, it's clear that SG alone
> is no good.
>
> This is not necessarily the only approach, but it is the current approach
> in the Linux IPv4 stack. It's not worth the effort to re-engineer the code
> in order to support the fast-disappearing hardware which supports SG but
> not cksums.
Agreed.
>
> > zerocopy without requiring HW cksums only OR could for instance the forwarding
> > procdure also benefit from SG without requiring HW cksums?
>
> The forwarding procedure is already dealing with linear buffers because
> 99.99% of the network cards on the market receive packets into one linear
> buffer. So again SG is useless for that.
I see, thanks for your patience with me.
Joakim
>
> Ion