[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20120620.225653.1103922403304200286.davem@davemloft.net>
Date: Wed, 20 Jun 2012 22:56:53 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: eric.dumazet@...il.com
Cc: alexander.h.duyck@...el.com, netdev@...r.kernel.org,
jeffrey.t.kirsher@...el.com
Subject: Re: [PATCH] net: Update netdev_alloc_frag to work more efficiently
with TCP and GRO
From: Eric Dumazet <eric.dumazet@...il.com>
Date: Wed, 20 Jun 2012 10:17:03 +0200
> By the way, big cost in netdev_alloc_frag() is the irq
> masking/restore We probably could have a version for softirq
> users...
That's an extremely disappointing way for us to be losing cycles.
Everyone pays this price purely because:
1) __netdev_alloc_skb() uses netdev_alloc_frag()
and:
2) #1 is invoked, either directly or indirectly, by tons
of slow non-NAPI drivers.
This got me looking into the plathora of interfaces we let drivers use
to allocate RX buffers. It's a big mess.
We have dev_alloc_skb() which essentially calls __netdev_alloc_skb()
with a NULL device argument. This is terrible because it means that
if we want to do something interesting on a per-device level we can't
rely upon the device being non-NULL in __netdev_alloc_skb().
I looked at the remaining dev_alloc_skb() users and these are in places
which are allocating packets in a module which is one level removed from
the netdevice level. For example, ATM and infiniband IPATH.
What these callers want is something more like:
static inline struct sk_buff *alloc_skb_and_reserve_pad(unsinged int length,
gfp_t gfp_mask)
{
struct sk_buff *skb = __alloc_skb(length + NET_SKB_PAD, gfp_mask,
0, NUMA_NO_NODE);
if (likely(skb))
skb_reserve(skb, NET_SKB_PAD);
return skb;
}
Then we won't have the NULL device case for __netdev_alloc_skb() any more.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists