[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CA+mtBx8ON8+UtsGPtiDnqzKq8BH10-8_zU2_=CjiDnkqZo0okw@mail.gmail.com>
Date: Wed, 21 Jan 2015 14:55:35 -0800
From: Tom Herbert <therbert@...gle.com>
To: Or Gerlitz <gerlitz.or@...il.com>
Cc: David Miller <davem@...emloft.net>, Thomas Graf <tgraf@...g.ch>,
Linux Netdev List <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 1/2] udp: Do not require sock in udp_tunnel_xmit_skb
On Wed, Jan 21, 2015 at 2:37 PM, Or Gerlitz <gerlitz.or@...il.com> wrote:
> On Thu, Jan 22, 2015 at 12:24 AM, Tom Herbert <therbert@...gle.com> wrote:
>> On Wed, Jan 21, 2015 at 12:57 PM, Or Gerlitz <gerlitz.or@...il.com> wrote:
>>> On Wed, Jan 21, 2015 at 12:24 AM, Tom Herbert <therbert@...gle.com> wrote:
>>>> vxlan_xmit_one calls udp_flow_src_port to get a source port value
>>>> based on the encapsulated flow.
>>>
>>> OK, got it -- does a by-product of invoking udp_flow_src_port on the
>>> skb is having an hash mark on the skb which is based on the inner
>>> packet and can (is?) used for TX queue selection over MQ devices?
>>
>> Yes, that should be fine. The hash can be used all the way up to TCP
>> and save in the TCP socket as the rxhash for a connection. This was
>> RFS, XPS, etc. will work for TCP over an encapsulation.
>
>
> so.. can be used or is already used today? Also we're talking on the
> TX path, so I wasn't sure to follow on your mentioning of RFS...
Yes. AFAIK all encapsulation implementations are single queue and
otherwise transparent to the application layer for the hash and queue
selection.
Is there a particular feature you're having trouble with?
Thanks,
Tom
--
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