[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHA+R7NkWxbLM_T202o86G_0MgmpHG71jV+2_fQ3JCjZu9sw1g@mail.gmail.com>
Date: Mon, 28 Jul 2014 14:26:08 -0700
From: Cong Wang <cwang@...pensource.com>
To: Alexander Duyck <alexander.h.duyck@...el.com>
Cc: Amir Vadai <amirv@...lanox.com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
netdev <netdev@...r.kernel.org>,
Or Gerlitz <ogerlitz@...lanox.com>,
Yevgeny Petrilin <yevgenyp@...lanox.com>,
Ido Shamay <idos@...lanox.com>,
Eric Dumazet <eric.dumazet@...il.com>
Subject: Re: [PATCH net-next V1 1/2] net: Header length compution function
On Mon, Jul 28, 2014 at 7:50 AM, Alexander Duyck
<alexander.h.duyck@...el.com> wrote:
> On 07/28/2014 04:28 AM, Amir Vadai wrote:
>> +u32 eth_frame_headlen(void *data, unsigned int len)
>> +{
>> + const struct ethhdr *eth = data;
>> + struct sk_buff skb;
>> +
>> + if (unlikely(len < ETH_HLEN))
>> + return len;
>> +
>> + skb.protocol = eth->h_proto;
>> + skb.head = data + ETH_HLEN;
>> + skb.data = skb.head;
>> + skb_reset_network_header(&skb);
>> + skb.len = len - ETH_HLEN;
>> + skb.data_len = 0;
>> + return __skb_get_poff(&skb) + ETH_HLEN;
>> +}
>
> I'm still not a big fan of allocating an sk_buff on the stack. Seems
> like it isn't maintainable and really opens things up to possible issues
> if someone ever extends the __skb_get_poff call. But I'm not going to
> force the issue since for now this isn't impacting igb or ixgbe.
>
+1
I think you can refactor the code to pass all these input as
arguments instead of a whole skbuff.
--
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