Stephen Hemminger wrote:
On Thu, 13 Dec 2007 06:19:38 -0800 (PST)
David Miller <[EMAIL PROTECTED]> wrote:
From: Andrew Gallatin <[EMAIL PROTECTED]>
Date: Thu, 13 Dec 2007 09:13:54 -0500
If the netif_running() check is indeed required to make a device break
out of napi polling an
Joonwoo Park wrote:
> 2007/12/13, Kok, Auke <[EMAIL PROTECTED]>:
>> David Miller wrote:
>>> From: Andrew Gallatin <[EMAIL PROTECTED]>
>>> Date: Wed, 12 Dec 2007 12:29:23 -0500
>>>
>>>> Is the netif_running() check even required?
>>
Remove the bogus netif_running() check from myri10ge_poll().
This eliminates any chance that myri10ge_poll() can trigger
an oops by calling netif_rx_complete() and returning
with work_done == budget.
Signed-off-by: Andrew Gallatin <[EMAIL PROTECTED]>
diff --git a/drivers/net/myri10ge/myri
David Miller wrote:
From: Andrew Gallatin <[EMAIL PROTECTED]>
Date: Wed, 12 Dec 2007 12:29:23 -0500
Is the netif_running() check even required?
No, it is not.
When a device is brought down, one of the first things
that happens is that we wait for all pending NAPI polls
to complete
[I apologize for loosing threading, I'm replying from the archives]
> The problem is that the driver is doing a NAPI completion and
> re-enabling chip interrupts with work_done == weight, and that is
> illegal.
The only time at least myri10ge will do this is due to
the !netif_running(netdev) che
require strict alignment (seen on sparc64).
Myri10GE is updated to use this field.
Signed off by: Andrew Gallatin <[EMAIL PROTECTED]>
diff --git a/drivers/net/myri10ge/myri10ge.c b/drivers/net/myri10ge/myri10ge.c
index 0f306dd..8def865 100644
--- a/drivers/net/myri10ge/myri10ge.c
+++ b/drive
Herbert Xu wrote:
On Fri, Nov 30, 2007 at 02:35:43PM -0500, Andrew Gallatin wrote:
Isn't the value of 2 ethernet-specific (to round the 14-byte header up
to 16)? Given that the rest of the lro code is fairly careful to
calculate mac_hdr_len etc it seems as if it would be cleaner to make
say 2. It would be nice to have another macro
> > for that I suppose.
>
> It is certainly simple enough to say 2. Thank you for pointing
> this out. I have attached a patch to do that..
>
> Signed off by: Andrew Gallatin <[EMAIL PROTECTED]>
Isn't the va
Herbert Xu wrote:
Andrew Gallatin <[EMAIL PROTECTED]> wrote:
diff --git a/net/ipv4/inet_lro.c b/net/ipv4/inet_lro.c
index ac3b1d3..91e9371 100644
--- a/net/ipv4/inet_lro.c
+++ b/net/ipv4/inet_lro.c
@@ -401,10 +401,11 @@ static struct sk_buff *lro_gen_skb(struc
int data_len
The inet_lro.c:lro_gen_skb() function fails to include
NET_IP_ALIGN padding at the front of the sk_buffs it creates,
leading to alignment warnings on architectures which require
strict alignment (seen on sparc64). The attached patch
adds NET_IP_ALIGN padding.
Signed off by: Andrew Gallatin
David Miller wrote:
> From: Andrew Gallatin <[EMAIL PROTECTED]>
> Date: Tue, 20 Nov 2007 06:47:57 -0500
>
>> David Miller wrote:
>> > From: Herbert Xu <[EMAIL PROTECTED]>
>> > Date: Tue, 20 Nov 2007 14:09:18 +0800
>> >
>> >>
David Miller wrote:
> From: Herbert Xu <[EMAIL PROTECTED]>
> Date: Tue, 20 Nov 2007 14:09:18 +0800
>
>> David Miller <[EMAIL PROTECTED]> wrote:
>>> Fundamentally, I really don't like this change, it batches to the
>>> point where it begins to erode the natural ACK clocking of TCP, and I
>>> theref
Stephen Hemminger wrote:
On Wed, 31 Oct 2007 17:40:06 -0400
Andrew Gallatin <[EMAIL PROTECTED]> wrote:
When testing the myri10ge driver with 2.6.24-rc1, I found
that the machine crashed under heavy load:
Unable to handle kernel paging request at 00100108 RIP:
[] net_rx_action
work > weight); warning in
net_rx_action triggering. I've moved the increment of work_done
inside the loop. Note that this would only be a problem when we had
exceeded our budget.
Signed off by: Andrew Gallatin <[EMAIL PROTECTED]>
Andrew Gallatin Myricom Inc
diff --git a/driver
713
Myri10GE + patched inet_lro:
196712 65536 6553660.00 9249.65 7.21 45.90 0.255 1.626
Signed off by: Andrew Gallatin <[EMAIL PROTECTED]>
Andrew Gallatin
Myricom Inc.
diff --git a/net/ipv4/inet_lro.c b/net/ipv4/inet_lro.c
index ac3b1d3..eba145b 100644
--- a/net/ipv4
David Miller wrote:
> I had to add the following patch to fix the build after
> the LRO changes, I have no idea how you could have compile
> tested that patch let alone done any real testing on it :-/
Whoops. I'm very sorry about that. Future patches will be submitted
by our Linux guy, who know
Kok, Auke wrote:
Andrew Gallatin wrote:
To follow up on Jan-Bernd Themann's LRO patch earlier today,
this patch shows how the generic LRO interface can be used for
page based drivers.
Again, many thanks to Jan-Bernd Themann for leading this effort.
Drew
Singed off by: Andrew Gallatin &l
To follow up on Jan-Bernd Themann's LRO patch earlier today,
this patch shows how the generic LRO interface can be used for
page based drivers.
Again, many thanks to Jan-Bernd Themann for leading this effort.
Drew
Singed off by: Andrew Gallatin <[EMAIL PROTECTED]>
diff -urNp a/
Jan-Bernd Themann wrote:
On Monday 30 July 2007 22:32, Andrew Gallatin wrote:
Second, you still need to set skb->ip_summed = CHECKSUM_UNNECESSARY
when modified packets are flushed, else the stack will see bad
checksums for packets from CHECKSUM_COMPLETE drivers using the
skb interface. Fi
Both patches are signed off by Andrew Gallatin
<[EMAIL PROTECTED]>
First, the LRO_MAX_PG_HLEN is still a problem. Minimally sized 60
byte frames still cause problems in lro_gen_skb due to skb->len
going negative. Fixed in the attached patch. It may be simpler
to just drop LRO_MAX_PG_
Here is a quick reply before something more official can
be written up:
Linas Vepstas wrote:
> -- what is LRO?
Large Receive Offload
> -- Basic principles of operation?
LRO is analogous to a receive side version of TSO. The NIC (or
driver) merges several consecutive segments from the same c
Jan-Bernd Themann wrote:
> On Wednesday 25 July 2007 19:17, Andrew Gallatin wrote:
>> 3) Padded frames.
>>
>> I may be missing something, but I don't see where you
>> either strip padding from frames or reject padded frames.
>> (see the pskb_trim_rcsum()
Hi,
I've ported myri10ge to use the new LRO interface. I have attached a
preliminary patch to myri10ge. I'm very pleased to note that the
performance is on-par with my own LRO used by our out-of-tree driver.
(except when using mixed MTUS, see performance data below).
As I expected, actually po
On 7/20/07, Jan-Bernd Themann <[EMAIL PROTECTED]> wrote:
Hi,
Thanks a lot for your comments so far.
This generic LRO patch differs from the last one in several points.
A new interface for a "receive in pages" mode has been added and tested
with an eHEA prototype. Seems to work well.
Does this e
On 7/11/07, Jan-Bernd Themann <[EMAIL PROTECTED]> wrote:
Generic Large Receive Offload proposal
I'm very glad that somebody is stepping up to take responsibility
for this!
I'm the primary author of the Myricom Myri10GE driver, and its LRO mechanism
(which has been rejected several times when p
On 4/5/06, Ben Greear <[EMAIL PROTECTED]> wrote:
> Andrew Gallatin wrote:
> > I'm working on a driver for a 10GbE nic. I've just gotten to the point
> > where I
> > am verifying that 802.1q vlans work without hardware vlan offload. It
> > seems lik
I'm working on a driver for a 10GbE nic. I've just gotten to the point where I
am verifying that 802.1q vlans work without hardware vlan offload. It
seems like
the netdev features flags (NETIF_F_SG|NETIF_F_IP_CSUM|NETIF_F_TSO) are not
being inherited by the vlan device. This leads to very high
27 matches
Mail list logo
