AndrewL733 wrote:
> The cause of this problem seems to be compiling the Myricom driver with
> the ALLOC_ORDER=2 option. When I use the in-kernel driver, (1.3.2) or
> recompile the Myricom 1.4.0 driver WITHOUT the option, the problem seems
> to go away even after heavy hammering of the system.
>
>
AndrewL733 wrote:
The cause of this problem seems to be compiling the Myricom driver with
the ALLOC_ORDER=2 option. When I use the in-kernel driver, (1.3.2) or
recompile the Myricom 1.4.0 driver WITHOUT the option, the problem seems
to go away even after heavy hammering of the system.
The
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
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?
&
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?
No, it is not.
When a device is brought down, one of the first things
that happens
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 and respond
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 co
[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)
[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)
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, then block
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/myri10ge.c b
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 <[EM
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/drive
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/drivers/net
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 [EMAIL
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
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. Fixed
h 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_HLEN
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
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
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_HLEN to ETH_ZLEN, but I'm not sure
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() in ne
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() in net/ipv4/ip_input.c:ip_rcv()
I think I missed
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
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
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
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
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
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
30 matches
Mail list logo
