[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <D0829981.5EDAD%matthew.vick@intel.com>
Date: Sat, 8 Nov 2014 00:51:13 +0000
From: "Vick, Matthew" <matthew.vick@...el.com>
To: Joe Stringer <joestringer@...ira.com>
CC: "alexander.duyck@...il.com" <alexander.duyck@...il.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"Dept-GELinuxNICDev@...gic.com" <Dept-GELinuxNICDev@...gic.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"sathya.perla@...lex.com" <sathya.perla@...lex.com>,
"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
Linux NICS <Linux-nics@...el.com>,
"amirv@...lanox.com" <amirv@...lanox.com>,
"shahed.shaikh@...gic.com" <shahed.shaikh@...gic.com>,
"therbert@...gle.com" <therbert@...gle.com>,
"Or Gerlitz" <gerlitz.or@...il.com>
Subject: Re: [PATCH net 3/5] fm10k: Implement ndo_gso_check()
On 11/7/14, 2:35 PM, "Joe Stringer" <joestringer@...ira.com> wrote:
>Sure, I think fm10k_tx_encap_offload() is a good place for the header
>length
>check. Separately, my question above was regarding the idea of a helper
>for
>SKB_GSO_{GRE,UDP_TUNNEL}. The only reason it might be useful for the
>fm10k
>driver is because all encap is checked in the fm10k_tx_encap_offload()
>function.
>Other drivers don't seem to handle different tunnels together like this
>though,
>so I'm inclined to stick with the below for now.
>
>
>static bool fm10k_gso_check(struct sk_buff *skb, struct net_device *dev)
>
>{
>
> return (!(skb_shinfo(skb)->gso_type &
>
> (SKB_GSO_UDP_TUNNEL | SKB_GSO_GRE)) ||
>
> fm10k_tx_encap_offload(skb));
>
>}
>
>Cheers,
>Joe
I agree. I think that makes the most sense.
Cheers,
Matthew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists