netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnd Hannemann <arnd@arndnet.de>
To: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org, olel@ans.pl
Subject: Re: problems with e1000 and jumboframes
Date: Thu, 03 Aug 2006 23:40:27 +0200	[thread overview]
Message-ID: <44D26D4B.4090609@arndnet.de> (raw)
In-Reply-To: <20060803182911.GA8692@2ka.mipt.ru>

Evgeniy Polyakov wrote:
> On Thu, Aug 03, 2006 at 08:09:07PM +0200, Arnd Hannemann (arnd@arndnet.de) wrote:
>> Evgeniy Polyakov schrieb:
>>> On Thu, Aug 03, 2006 at 07:16:31PM +0400, Evgeniy Polyakov (johnpol@2ka.mipt.ru) wrote:
>>>>>> then skb_alloc adds a little
>>>>>> (sizeof(struct skb_shared_info)) at the end, and this ends up
>>>>>> in 32k request just for 9k jumbo frame.
>>>>> Strange, why this skb_shared_info cannon be added before first alignment? 
>>>>> And what about smaller frames like 1500, does this driver behave similar 
>>>>> (first align then add)?
>>>> It can be.
>>>> Could attached  (completely untested) patch help?
>>> Actually this patch will not help, this new one could.
>>>
>> I applied the attached pachted. And got this output:
>>
>>> Intel(R) PRO/1000 Network Driver - bufsz 13762
>>> ...

>> I'm a bit puzzled that there are so much allocations. However the patch
>> seems to work. (at least not obviously breaks things for me yet)
> 
> Very strange output actually - comments in the code say that frame size
> can not exceed 0x3f00, but in this log it is much more than 16128 and
> that is after sizeof(struct skb_shared_info) has been removed...
> Could you please remove debug output and run some network stress test in
> parallel with high disk/memory activity to check if that does not break
> your system and watch /proc/slabinfo for 16k and 32k sized pools.

The system seems to be still stable.

>From /proc/slabinfo during netio test:
> size-32768(DMA)        0      0  32768    1    8 : tunables    8    4    0 : slabdata      0      0      0
> size-32768            84     89  32768    1    8 : tunables    8    4    0 : slabdata     84     89      0
> size-16384(DMA)        0      0  16384    1    4 : tunables    8    4    0 : slabdata      0      0      0
> size-16384           184    188  16384    1    4 : tunables    8    4    0 : slabdata    184    188      0

Netio results:

NETIO - Network Throughput Benchmark, Version 1.26
(C) 1997-2005 Kai Uwe Rommel

TCP connection established.
Packet size  1k bytes:  72320 KByte/s Tx,  86656 KByte/s Rx.
Packet size  2k bytes:  71400 KByte/s Tx,  94703 KByte/s Rx.
Packet size  4k bytes:  71544 KByte/s Tx,  88463 KByte/s Rx.
Packet size  8k bytes:  70392 KByte/s Tx,  92127 KByte/s Rx.
Packet size 16k bytes:  70512 KByte/s Tx,  102607 KByte/s Rx.
Packet size 32k bytes:  71705 KByte/s Tx,  101083 KByte/s Rx.
Done.

Strange ist that receiving seems to be much faster than transmitting.


> -- 
> 	Evgeniy Polyakov

Thanks,
Arnd




  reply	other threads:[~2006-08-03 21:40 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-03 13:48 problems with e1000 and jumboframes Arnd Hannemann
2006-08-03 13:59 ` Evgeniy Polyakov
2006-08-03 14:37   ` Arnd Hannemann
2006-08-03 15:03     ` Evgeniy Polyakov
2006-08-03 15:08       ` Krzysztof Oledzki
2006-08-03 15:16         ` Evgeniy Polyakov
2006-08-03 15:37           ` Arnd Hannemann
2006-08-03 15:43             ` Evgeniy Polyakov
2006-08-03 15:41           ` Evgeniy Polyakov
2006-08-03 18:09             ` Arnd Hannemann
2006-08-03 18:29               ` Evgeniy Polyakov
2006-08-03 21:40                 ` Arnd Hannemann [this message]
2006-08-03 15:57           ` Chris Leech
2006-08-03 16:10             ` Evgeniy Polyakov
2006-08-03 20:32               ` Chris Leech
2006-08-04  6:20                 ` Evgeniy Polyakov
2006-08-04 15:16                   ` Chris Leech
2006-08-03 16:24             ` Arnd Hannemann
2006-08-03 20:34               ` Chris Leech
2006-08-04  5:59                 ` Herbert Xu
2006-08-04  6:15                   ` Evgeniy Polyakov
2006-08-04 15:34                     ` Chris Leech
2006-08-04 19:42                       ` Evgeniy Polyakov
2006-08-04 21:02                         ` Jesse Brandeburg
2006-08-05  9:58                           ` Evgeniy Polyakov
2006-08-05 10:09                             ` Herbert Xu
2006-08-05 10:24                               ` Evgeniy Polyakov
2006-08-05 10:33                                 ` Herbert Xu
2006-08-05 10:41                                   ` Evgeniy Polyakov
2006-08-03 15:23         ` Evgeniy Polyakov
2006-08-04  5:52   ` Herbert Xu
2006-08-04  5:55     ` David Miller
2006-08-04  5:58       ` Evgeniy Polyakov
2006-08-03 14:24 ` Benjamin LaHaise
2006-08-03 14:49   ` Krzysztof Oledzki
2006-08-03 14:52     ` Benjamin LaHaise
2006-08-03 15:04       ` Krzysztof Oledzki
2006-08-03 15:32   ` Arnd Hannemann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=44D26D4B.4090609@arndnet.de \
    --to=arnd@arndnet.de \
    --cc=johnpol@2ka.mipt.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=olel@ans.pl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).