[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <55CECE51.1050608@cumulusnetworks.com>
Date: Fri, 14 Aug 2015 23:29:53 -0600
From: David Ahern <dsa@...ulusnetworks.com>
To: Tom Herbert <tom@...bertland.com>,
Shrijeet Mukherjee <shm@...ulusnetworks.com>
CC: Linux Kernel Network Developers <netdev@...r.kernel.org>,
Roopa Prabhu <roopa@...ulusnetworks.com>,
Andy Gospodarek <gospo@...ulusnetworks.com>,
Jon Toppins <jtoppins@...ulusnetworks.com>,
Nikolay Aleksandrov <nikolay@...ulusnetworks.com>,
Dinesh Dutt <ddutt@...ulusnetworks.com>,
Hannes Frederic Sowa <hannes@...essinduktion.org>,
Nicolas Dichtel <nicolas.dichtel@...nd.com>,
Stephen Hemminger <stephen@...workplumber.org>,
Jamal Hadi Salim <hadi@...atatu.com>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
"David S. Miller" <davem@...emloft.net>, svaidya@...cade.com
Subject: Re: [PATCH net-next 04/11] udp: Handle VRF device in sendmsg
On 8/14/15 9:16 PM, Tom Herbert wrote:
> At least collect this code into one (static inline) function to better
> minimize the code churn in udp. If this is general functionality that
> can be used by other drivers then abstract it out as such. Also, if
> the VRF driver is not configured it seems like this code should
> compiled out. As it stands now "if (netif_index_is_vrf(net, ipc.oif))
> {" adds a conditional to every call of udp_sendmsg rather or not we
> are using VRF :-(.
Sure. I wanted to make sure all of the VRF related changes compiled out
when the VRF driver is not enabled. This one slipped by me. I'll send a
patch next week along with a couple of others per Eric D's comments.
David
--
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