Quoting r. David Miller [EMAIL PROTECTED]:
Subject: Re: Dropping NETIF_F_SG since no checksum feature.
From: Michael S. Tsirkin [EMAIL PROTECTED]
Date: Thu, 12 Oct 2006 21:12:06 +0200
Quoting r. David Miller [EMAIL PROTECTED]:
Subject: Re: Dropping NETIF_F_SG since no checksum feature
Quoting r. David Miller [EMAIL PROTECTED]:
Subject: Re: Dropping NETIF_F_SG since no checksum feature.
From: Michael S. Tsirkin [EMAIL PROTECTED]
Date: Wed, 11 Oct 2006 23:23:39 +0200
With my patch, there is a huge performance gain by increasing MTU to 64K.
And it seems the only way
From: Michael S. Tsirkin [EMAIL PROTECTED]
Date: Thu, 12 Oct 2006 21:12:06 +0200
Quoting r. David Miller [EMAIL PROTECTED]:
Subject: Re: Dropping NETIF_F_SG since no checksum feature.
Numbers?
I created two subnets on top of the same pair infiniband HCAs:
I was asking for SG vs. non
Quoting r. David Miller [EMAIL PROTECTED]:
Subject: Re: Dropping NETIF_F_SG since no checksum feature.
From: Michael S. Tsirkin [EMAIL PROTECTED]
Date: Wed, 11 Oct 2006 02:13:38 +0200
Maybe I can patch linux to allow SG without checksum?
Dave, maybe you could drop a hint or two
Hi,
On Wed, Oct 11, 2006 at 11:05:04AM +0200, Michael S. Tsirkin wrote:
Quoting r. David Miller [EMAIL PROTECTED]:
Subject: Re: Dropping NETIF_F_SG since no checksum feature.
From: Michael S. Tsirkin [EMAIL PROTECTED]
Date: Wed, 11 Oct 2006 02:13:38 +0200
Maybe I can patch linux
From: Michael S. Tsirkin [EMAIL PROTECTED]
Date: Wed, 11 Oct 2006 11:05:04 +0200
So, it seems that if I set NETIF_F_SG but clear NETIF_F_ALL_CSUM,
data will be copied over rather than sent directly.
So why does dev.c have to force set NETIF_F_SG to off then?
Because it's more efficient to
Quoting r. David Miller [EMAIL PROTECTED]:
Subject: Re: Dropping NETIF_F_SG since no checksum feature.
From: Michael S. Tsirkin [EMAIL PROTECTED]
Date: Wed, 11 Oct 2006 11:05:04 +0200
So, it seems that if I set NETIF_F_SG but clear NETIF_F_ALL_CSUM,
data will be copied over rather than
Quoting Steven Whitehouse [EMAIL PROTECTED]:
ssize_t tcp_sendpage(struct socket *sock, struct page *page, int offset,
size_t size, int flags)
{
ssize_t res;
struct sock *sk = sock-sk;
if (!(sk-sk_route_caps NETIF_F_SG) ||
Hi,
On Wed, Oct 11, 2006 at 05:01:03PM +0200, Michael S. Tsirkin wrote:
Quoting Steven Whitehouse [EMAIL PROTECTED]:
ssize_t tcp_sendpage(struct socket *sock, struct page *page, int offset,
size_t size, int flags)
{
ssize_t res;
struct sock *sk
From: Michael S. Tsirkin [EMAIL PROTECTED]
Date: Wed, 11 Oct 2006 17:01:03 +0200
Quoting Steven Whitehouse [EMAIL PROTECTED]:
ssize_t tcp_sendpage(struct socket *sock, struct page *page, int offset,
size_t size, int flags)
{
ssize_t res;
struct
Quoting r. Steven Whitehouse [EMAIL PROTECTED]:
Subject: Re: Dropping NETIF_F_SG since no checksum feature.
Hi,
On Wed, Oct 11, 2006 at 05:01:03PM +0200, Michael S. Tsirkin wrote:
Quoting Steven Whitehouse [EMAIL PROTECTED]:
ssize_t tcp_sendpage(struct socket *sock, struct page *page
On Wed, 11 Oct 2006 21:11:38 +0100
Steven Whitehouse [EMAIL PROTECTED] wrote:
Hi,
On Wed, Oct 11, 2006 at 05:01:03PM +0200, Michael S. Tsirkin wrote:
Quoting Steven Whitehouse [EMAIL PROTECTED]:
ssize_t tcp_sendpage(struct socket *sock, struct page *page, int offset,
From: Michael S. Tsirkin [EMAIL PROTECTED]
Date: Wed, 11 Oct 2006 23:23:39 +0200
With my patch, there is a huge performance gain by increasing MTU to 64K.
And it seems the only way to do this is by S/G.
Numbers?
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a
Quoting r. David Miller [EMAIL PROTECTED]:
Subject: Re: Dropping NETIF_F_SG since no checksum feature.
From: Michael S. Tsirkin [EMAIL PROTECTED]
Date: Wed, 11 Oct 2006 17:01:03 +0200
Quoting Steven Whitehouse [EMAIL PROTECTED]:
ssize_t tcp_sendpage(struct socket *sock, struct page
Quoting r. Stephen Hemminger [EMAIL PROTECTED]:
Subject: Re: Dropping NETIF_F_SG since no checksum feature.
O
You might want to try ignoring the check in dev.c and testing
to see if there is a performance gain. It wouldn't be hard to test
a modified version and validate
Quoting r. Stephen Hemminger [EMAIL PROTECTED]:
Subject: Re: Dropping NETIF_F_SG since no checksum feature.
On Wed, 11 Oct 2006 21:11:38 +0100
Steven Whitehouse [EMAIL PROTECTED] wrote:
Hi,
On Wed, Oct 11, 2006 at 05:01:03PM +0200, Michael S. Tsirkin wrote:
Quoting Steven
O
You might want to try ignoring the check in dev.c and testing
to see if there is a performance gain. It wouldn't be hard to test
a modified version and validate the performance change.
Yes. With my patch, there is a huge performance gain by increasing MTU to 64K.
And it seems the
Quoting r. Stephen Hemminger [EMAIL PROTECTED]:
Subject: Re: Dropping NETIF_F_SG since no checksum feature.
On Mon, 9 Oct 2006 19:47:05 +0200
Michael S. Tsirkin [EMAIL PROTECTED] wrote:
Hi!
I'm trying to build a network device driver supporting a very large MTU
(around 64K)
on top
On Tue, 10 Oct 2006 16:43:30 +0200
Michael S. Tsirkin [EMAIL PROTECTED] wrote:
Quoting r. Stephen Hemminger [EMAIL PROTECTED]:
Subject: Re: Dropping NETIF_F_SG since no checksum feature.
On Mon, 9 Oct 2006 19:47:05 +0200
Michael S. Tsirkin [EMAIL PROTECTED] wrote:
Hi!
I'm
Michael Maybe I can patch linux to allow SG without checksum?
Michael Dave, maybe you could drop a hint or two on whether this
Michael is worthwhile and what are the issues that need
Michael addressing to make this work?
What do you really gain by allowing SG without checksum?
Quoting r. Roland Dreier [EMAIL PROTECTED]:
Subject: Re: Dropping NETIF_F_SG since no checksum feature.
Michael Maybe I can patch linux to allow SG without checksum?
Michael Dave, maybe you could drop a hint or two on whether this
Michael is worthwhile and what are the issues
From: Michael S. Tsirkin [EMAIL PROTECTED]
Date: Wed, 11 Oct 2006 02:13:38 +0200
Maybe I can patch linux to allow SG without checksum?
Dave, maybe you could drop a hint or two on whether this is worthwhile
and what are the issues that need addressing to make this work?
I imagine it's not
Michael My guess was, an extra pass over data is likely to be
Michael expensive - dirtying the cache if nothing else. But I do
Michael plan to measure that, and see.
I don't get it -- where's the extra pass? If you can't compute the
checksum on the NIC then you have to compute
From: Roland Dreier [EMAIL PROTECTED]
Date: Tue, 10 Oct 2006 20:33:46 -0700
Michael My guess was, an extra pass over data is likely to be
Michael expensive - dirtying the cache if nothing else. But I do
Michael plan to measure that, and see.
I don't get it -- where's the extra
David Also, if you don't do checksumming on the card we MUST copy
David the data (be it from a user buffer, or from a filesystem
David page cache page) into a private buffer since if the data
David changes the checksum would become invalid, as I mentioned
David in another email
From: Roland Dreier [EMAIL PROTECTED]
Date: Tue, 10 Oct 2006 20:42:20 -0700
On the other hand I'm not sure how useful such a netdevice would be --
will non-sendfile() paths generate big packets even if the MTU is 64KB?
non-sendfile() paths will generate big packets just fine, as long
as the
David non-sendfile() paths will generate big packets just fine,
David as long as the application is providing that much data.
OK, cool. Will the big packets be non-linear skbs?
Because then it would make sense for a device with a huge MTU to want
to accept them without linearizing them,
From: Roland Dreier [EMAIL PROTECTED]
Date: Tue, 10 Oct 2006 20:49:09 -0700
David non-sendfile() paths will generate big packets just fine,
David as long as the application is providing that much data.
OK, cool. Will the big packets be non-linear skbs?
If you had SG enabled (and
On Mon, 9 Oct 2006 19:47:05 +0200
Michael S. Tsirkin [EMAIL PROTECTED] wrote:
Hi!
I'm trying to build a network device driver supporting a very large MTU
(around 64K)
on top of an infiniband connection, and I've hit a couple of issues I'd
appreciate some feedback on:
1. On the send side,
29 matches
Mail list logo
