[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <57DA21F4.20700@gmail.com>
Date: Wed, 14 Sep 2016 21:22:12 -0700
From: John Fastabend <john.fastabend@...il.com>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>,
"Brown, Aaron F" <aaron.f.brown@...el.com>
Cc: "bblanco@...mgrid.com" <bblanco@...mgrid.com>,
"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
"brouer@...hat.com" <brouer@...hat.com>,
"davem@...emloft.net" <davem@...emloft.net>,
"xiyou.wangcong@...il.com" <xiyou.wangcong@...il.com>,
"intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>,
"u9012063@...il.com" <u9012063@...il.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [Intel-wired-lan] [net-next PATCH v3 1/3] e1000: track BQL bytes
regardless of skb or not
On 16-09-14 05:43 PM, Alexei Starovoitov wrote:
> On Wed, Sep 14, 2016 at 11:57:24PM +0000, Brown, Aaron F wrote:
>>> From: Intel-wired-lan [mailto:intel-wired-lan-bounces@...ts.osuosl.org] On
>>> Behalf Of John Fastabend
>>> Sent: Monday, September 12, 2016 3:13 PM
>>> To: bblanco@...mgrid.com; john.fastabend@...il.com;
>>> alexei.starovoitov@...il.com; Kirsher, Jeffrey T
>>> <jeffrey.t.kirsher@...el.com>; brouer@...hat.com; davem@...emloft.net
>>> Cc: xiyou.wangcong@...il.com; intel-wired-lan@...ts.osuosl.org;
>>> u9012063@...il.com; netdev@...r.kernel.org
>>> Subject: [Intel-wired-lan] [net-next PATCH v3 1/3] e1000: track BQL bytes
>>> regardless of skb or not
>>>
>>> The BQL API does not reference the sk_buff nor does the driver need to
>>> reference the sk_buff to calculate the length of a transmitted frame.
>>> This patch removes an sk_buff reference from the xmit irq path and
>>> also allows packets sent from XDP to use BQL.
>>>
>>> Signed-off-by: John Fastabend <john.r.fastabend@...el.com>
>>> ---
>>> drivers/net/ethernet/intel/e1000/e1000_main.c | 7 ++-----
>>> 1 file changed, 2 insertions(+), 5 deletions(-)
>>
>> This patch is causing all my e1000 adapters to fail a simple ftp session with really slow response (hashing on) followed by adapter resets. I have seen this on 4 different e1000 nics now, an 82543GC, 82544GC, 82546EB and an 82545GM. On a few occasions I get a splat captured to dmesg. Here is an example:
>> --------------------------------
>> ------------[ cut here ]------------
>> WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:316 dev_watchdog+0x1c2/0x1d0
>> NETDEV WATCHDOG: eth1 (e1000): transmit queue 0 timed out
>
> Thanks a lot for the tests! Really appreciate it.
>
Thanks.
Jeff, please drop the series for now obviously this wont work. It needs
some work.
Powered by blists - more mailing lists