From: Alexander Duyck <alexander.h.duyck@intel.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: "Dave, Tushar N" <tushar.n.dave@intel.com>,
"Fastabend, John R" <john.r.fastabend@intel.com>,
Michal Miroslaw <mirqus@gmail.com>,
"Kirsher, Jeffrey T" <jeffrey.t.kirsher@intel.com>,
"davem@davemloft.net" <davem@davemloft.net>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"gospo@redhat.com" <gospo@redhat.com>,
"sassmann@redhat.com" <sassmann@redhat.com>
Subject: Re: [net] e1000: Small packets may get corrupted during padding by HW
Date: Mon, 17 Sep 2012 13:53:56 -0700 [thread overview]
Message-ID: <50578DE4.7080806@intel.com> (raw)
In-Reply-To: <1347868702.26523.79.camel@edumazet-glaptop>
On 09/17/2012 12:58 AM, Eric Dumazet wrote:
> On Mon, 2012-09-17 at 07:33 +0000, Dave, Tushar N wrote:
>>> -----Original Message-----
>>> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
>>> On Behalf Of John Fastabend
>>> Also wouldn't you want an unlikely() in your patch?
>> No because it is quite normal to have packet < ETH_ZLEN. e.g. ARP packets.
> ARP packets ? Hardly a performance problem.
>
> Or make sure all these packets have enough tailroom, or else you are
> going to hit the cost of reallocating packets.
>
> I would better point TCP pure ACK packets, since their size can be 54
> bytes.
>
> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> index cfe6ffe..aefc681 100644
> --- a/net/ipv4/tcp_output.c
> +++ b/net/ipv4/tcp_output.c
> @@ -3083,8 +3083,9 @@ void tcp_send_ack(struct sock *sk)
> /* We are not putting this on the write queue, so
> * tcp_transmit_skb() will set the ownership to this
> * sock.
> + * Add 64 bytes of tailroom so that some drivers can use skb_pad()
> */
> - buff = alloc_skb(MAX_TCP_HEADER, sk_gfp_atomic(sk, GFP_ATOMIC));
> + buff = alloc_skb(MAX_TCP_HEADER + 64, sk_gfp_atomic(sk, GFP_ATOMIC));
> if (buff == NULL) {
> inet_csk_schedule_ack(sk);
> inet_csk(sk)->icsk_ack.ato = TCP_ATO_MIN;
For most systems that extra padding should already be added since
alloc_skb will cache line align the buffer anyway.
A more general fix might be to make it so that alloc_skb cannot allocate
less than 60 byte buffers on systems with a cache line size smaller than
64 bytes.
Thanks,
Alex
next prev parent reply other threads:[~2012-09-17 20:53 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-15 20:16 [net] e1000: Small packets may get corrupted during padding by HW Jeff Kirsher
2012-09-15 20:44 ` Michał Mirosław
2012-09-16 1:25 ` Dave, Tushar N
2012-09-16 1:48 ` John Fastabend
2012-09-16 2:30 ` John Fastabend
2012-09-17 7:33 ` Dave, Tushar N
2012-09-17 7:58 ` Eric Dumazet
2012-09-17 20:53 ` Alexander Duyck [this message]
2012-09-17 21:02 ` Eric Dumazet
2012-09-18 3:01 ` Alexander Duyck
2012-09-18 3:03 ` David Miller
2012-09-18 3:27 ` Alexander Duyck
2012-09-18 5:45 ` Eric Dumazet
2012-09-18 5:55 ` Alexander Duyck
2012-09-17 16:31 ` David Miller
2012-09-17 16:39 ` Dave, Tushar N
2012-09-17 19:40 ` Alexander Duyck
2012-09-18 20:33 ` David Miller
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=50578DE4.7080806@intel.com \
--to=alexander.h.duyck@intel.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=gospo@redhat.com \
--cc=jeffrey.t.kirsher@intel.com \
--cc=john.r.fastabend@intel.com \
--cc=mirqus@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=sassmann@redhat.com \
--cc=tushar.n.dave@intel.com \
/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.