On 02/20/2013 01:42 PM, Eric Dumazet wrote:
> On Wed, 2013-02-20 at 13:23 -0800, Alexander Duyck wrote:
>
>> NET_SKB_PAD is defined for the s390. It is already 32. If you look it
>> up we only have 2 definitions for NET_SKB_PAD, one specific to the s390
>> architecture and the other one in skbuff
On 02/20/2013 11:22 AM, Eric Dumazet wrote:
> On Wed, 2013-02-20 at 10:16 -0800, Alexander Duyck wrote:
>
>> The problem is the 256 byte alignment for L1_CACHE_BYTES is increasing
>> the size of the data and shared info significantly pushing us past the
>> 2K limit.
>>
>> I'll look into this since
On 02/19/2013 05:09 PM, Eric Dumazet wrote:
> On Tue, Feb 19, 2013 at 2:30 PM, Allan, Bruce W
> wrote:
>>> -Original Message-
>>> From: Andrew Morton [mailto:a...@linux-foundation.org]
>>> Sent: Tuesday, February 19, 2013 2:27 PM
>>> To: Wu, Fengguang
>>> Cc: Daniel Santos; Kirsher, Jeffr
This is an informative message sent by mailserver
at mail.iotaflow.com.
Your mail message did not pass through the server content filter:
From:
To:
Subject: ***SPAM*** Re: here
Date: Thu, 21 Feb 2013 22:05:20 -0800
Problem: Prohibited file extension
MIME type: application/octet-s
On Wed, 2013-02-20 at 14:47 -0800, Alexander Duyck wrote:
> Huh? I'm not seeing what you are saying. The NET_SKB_PAD is the value
> that is in the last set of parenthesis since it was:
> (NET_SKB_PAD + NET_IP_ALIGN + IGB_TS_HDR_LEN + ETH_FRAME_LEN + ETH_FCS_LEN)
> that is the bit that became
On Wed, 2013-02-20 at 13:23 -0800, Alexander Duyck wrote:
> NET_SKB_PAD is defined for the s390. It is already 32. If you look it
> up we only have 2 definitions for NET_SKB_PAD, one specific to the s390
> architecture and the other one in skbuff.h.
>
Andrew traces disagree, as they were :
>>
On Wed, 2013-02-20 at 10:16 -0800, Alexander Duyck wrote:
>
> The problem is the 256 byte alignment for L1_CACHE_BYTES is increasing
> the size of the data and shared info significantly pushing us past the
> 2K limit.
>
> I'll look into this since it likely affects ixgbe as well.
Thats what I s
Ah, I misread, I was thinking of reading PPS stats. On the same note,
you may look at trafgen too, in the netsniff-ng suite.
It's uses a zero-copy TX_RING from user space, 1Gbps line rate has
been reported.
On Wed, Feb 20, 2013 at 10:18 AM, Stephen Hemminger
wrote:
> On Wed, 20 Feb 2013 01:23:33
On Wed, 20 Feb 2013 01:23:33 -0500 (EST)
Drew Smith wrote:
> Is there a good tool for testing packets per second (PPS) of an interface? My
> test app starts showing dropped packets at 75k UDP PPS in each direction
> (1500 concurrent g711 VOIP calls). I would assume the Intel i350 NIC could
> s
ifpps, a part of the netsniff-ng suite, is a good tool. It doesn't
rely on libpcap and reads directly from procfs e.g. /proc/net/dev.
http://netsniff-ng.org/ For screenshots and examples, see
https://help.ubuntu.com/community/Netsniff-NG
or https://sickbits.net/ifpps-top-like-network-statistic-tool
On Tue, 2013-02-19 at 08:58 -0800, Phil Oester wrote:
> Hi Jeff -
>
> Eric Dumazet suggested I send this to you, as he believes it to be a driver
> bug.
>
> Phil Oester
>
Thanks!
Added the e1000-devel mailing list as well as Bruce Allan (e1000e driver
maintainer).
>
> - Forwarded messa
On 02/17/2013 01:26 AM, Sasikanth babu wrote:
> On Sat, Feb 16, 2013 at 12:29 AM, Sasikanth babu
> wrote:
>> On Sat, Feb 16, 2013 at 12:11 AM, Alexander Duyck
>> wrote:
>>> On 02/15/2013 10:31 AM, Sasikanth babu wrote:
On Fri, Feb 15, 2013 at 10:50 PM, Alexander Duyck
wrote:
> On 0
> -Original Message-
> From: Andrew Morton [mailto:a...@linux-foundation.org]
> Sent: Tuesday, February 19, 2013 2:27 PM
> To: Wu, Fengguang
> Cc: Daniel Santos; Kirsher, Jeffrey T; Brandeburg, Jesse; Allan, Bruce W;
> net...@vger.kernel.org
> Subject: Re: [next:akpm 16/587]
> drivers/net/e
13 matches
Mail list logo