All of lore.kernel.org
 help / color / mirror / Atom feed
From: Auke Kok <auke-jan.h.kok@intel.com>
To: Andrew Morton <akpm@osdl.org>
Cc: Evgeniy Polyakov <johnpol@2ka.mipt.ru>,
	David Miller <davem@davemloft.net>,
	Holger.Kiehl@dwd.de, linux-kernel@vger.kernel.org,
	linux-net@vger.kernel.org, netdev@vger.kernel.org,
	john.ronciak@intel.com
Subject: Re: 2.6.1[78] page allocation failure. order:3, mode:0x20
Date: Sun, 24 Sep 2006 14:15:42 -0700	[thread overview]
Message-ID: <4516F57E.7090603@intel.com> (raw)
In-Reply-To: <20060924152651.GA2077@2ka.mipt.ru>

Evgeniy Polyakov wrote:
> On Fri, Sep 22, 2006 at 10:33:48PM -0700, Andrew Morton (akpm@osdl.org) wrote:
>>> The NET_IP_ALIGN existed not just for fun :)  There are ramifications
>>> for removing it.
>> It's still there, isn't it?
>>
>> For the 9k MTU case, for example, we end up allocating 16384 byte skbs
>> instead of 32786 kbytes ones.
> 
> This patch will not help - netdev_alloc_skb() adds additional
> NET_SKB_PAD and then alloc_skb() adds sizeof(struct skb_shared_info).
> And even if you acconut for them in adapter->rx_buf_len, chip still can
> overwrite that area (in the thread mentioned in this e-mail thread
> before I posted such patch and received a dump of sizes chip receives -
> there were a lot of _different_ ones which were too close to the limit).

I just did the math on it and it does not compute as I wanted too, we're 
basically flowing to the next larger buffersize 2 mtu bytes earlier, undoing 
any benefit completely.

There is not much that can fix this issue since the hardware will always 
receive in 2-order buffers and dma that back in its entirity, so we must always 
claim size for NET_IP_ALIGN and NET_SKB_PAD after the 2-order bufsz. For the 
9kb mtu case (16kb hw bufsz), we're stuck with 32kb slab allocations. bummer.

Andrew, please drop this patch.

Auke

> 
>> diff -puN drivers/net/e1000/e1000_main.c~e1000-account-for-net_ip_align-when-calculating-bufsiz drivers/net/e1000/e1000_main.c
>> --- a/drivers/net/e1000/e1000_main.c~e1000-account-for-net_ip_align-when-calculating-bufsiz
>> +++ a/drivers/net/e1000/e1000_main.c
>> @@ -1101,7 +1101,7 @@ e1000_sw_init(struct e1000_adapter *adap
>>  
>>  	pci_read_config_word(pdev, PCI_COMMAND, &hw->pci_cmd_word);
>>  
>> -	adapter->rx_buffer_len = MAXIMUM_ETHERNET_VLAN_SIZE;
>> +	adapter->rx_buffer_len = MAXIMUM_ETHERNET_VLAN_SIZE + NET_IP_ALIGN;
>>  	adapter->rx_ps_bsize0 = E1000_RXBUFFER_128;
>>  	hw->max_frame_size = netdev->mtu +
>>  			     ENET_HEADER_SIZE + ETHERNET_FCS_SIZE;
>> @@ -3163,26 +3163,27 @@ e1000_change_mtu(struct net_device *netd
>>  	 * larger slab size
>>  	 * i.e. RXBUFFER_2048 --> size-4096 slab */
>>  
>> -	if (max_frame <= E1000_RXBUFFER_256)
>> +	if (max_frame + NET_IP_ALIGN <= E1000_RXBUFFER_256)
>>  		adapter->rx_buffer_len = E1000_RXBUFFER_256;
>> -	else if (max_frame <= E1000_RXBUFFER_512)
>> +	else if (max_frame + NET_IP_ALIGN <= E1000_RXBUFFER_512)
>>  		adapter->rx_buffer_len = E1000_RXBUFFER_512;
>> -	else if (max_frame <= E1000_RXBUFFER_1024)
>> +	else if (max_frame + NET_IP_ALIGN <= E1000_RXBUFFER_1024)
>>  		adapter->rx_buffer_len = E1000_RXBUFFER_1024;
>> -	else if (max_frame <= E1000_RXBUFFER_2048)
>> +	else if (max_frame + NET_IP_ALIGN <= E1000_RXBUFFER_2048)
>>  		adapter->rx_buffer_len = E1000_RXBUFFER_2048;
>> -	else if (max_frame <= E1000_RXBUFFER_4096)
>> +	else if (max_frame + NET_IP_ALIGN <= E1000_RXBUFFER_4096)
>>  		adapter->rx_buffer_len = E1000_RXBUFFER_4096;
>> -	else if (max_frame <= E1000_RXBUFFER_8192)
>> +	else if (max_frame + NET_IP_ALIGN <= E1000_RXBUFFER_8192)
>>  		adapter->rx_buffer_len = E1000_RXBUFFER_8192;
>> -	else if (max_frame <= E1000_RXBUFFER_16384)
>> +	else
>>  		adapter->rx_buffer_len = E1000_RXBUFFER_16384;
>>  
>>  	/* adjust allocation if LPE protects us, and we aren't using SBP */
>>  	if (!adapter->hw.tbi_compatibility_on &&
>>  	    ((max_frame == MAXIMUM_ETHERNET_FRAME_SIZE) ||
>>  	     (max_frame == MAXIMUM_ETHERNET_VLAN_SIZE)))
>> -		adapter->rx_buffer_len = MAXIMUM_ETHERNET_VLAN_SIZE;
>> +		adapter->rx_buffer_len = MAXIMUM_ETHERNET_VLAN_SIZE +
>> +					NET_IP_ALIGN;
>>  
>>  	netdev->mtu = new_mtu;
>>  
>> @@ -4002,7 +4003,8 @@ e1000_alloc_rx_buffers(struct e1000_adap
>>  	struct e1000_buffer *buffer_info;
>>  	struct sk_buff *skb;
>>  	unsigned int i;
>> -	unsigned int bufsz = adapter->rx_buffer_len + NET_IP_ALIGN;
>> +	/* we have already accounted for NET_IP_ALIGN */
>> +	unsigned int bufsz = adapter->rx_buffer_len;
>>  
>>  	i = rx_ring->next_to_use;
>>  	buffer_info = &rx_ring->buffer_info[i];
>> _
>>
>> -
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

  reply	other threads:[~2006-09-24 21:29 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-22  7:27 2.6.1[78] page allocation failure. order:3, mode:0x20 Holger Kiehl
2006-09-22  7:42 ` Andrew Morton
2006-09-22 12:03   ` Holger Kiehl
2006-09-22 12:12     ` Evgeniy Polyakov
2006-09-22 17:10   ` Auke Kok
2006-09-23  4:50     ` Andrew Morton
2006-09-23  5:25       ` David Miller
2006-09-23  5:33         ` Andrew Morton
2006-09-23 18:50           ` Auke Kok
2006-09-23 20:03             ` David Miller
2006-09-24 15:26           ` Evgeniy Polyakov
2006-09-24 21:15             ` Auke Kok [this message]
  -- strict thread matches above, loose matches on Subject: below --
2006-09-25  8:38 Roy de Boer

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=4516F57E.7090603@intel.com \
    --to=auke-jan.h.kok@intel.com \
    --cc=Holger.Kiehl@dwd.de \
    --cc=akpm@osdl.org \
    --cc=davem@davemloft.net \
    --cc=john.ronciak@intel.com \
    --cc=johnpol@2ka.mipt.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-net@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.