[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54F06E03.7050303@mojatatu.com>
Date: Fri, 27 Feb 2015 08:15:47 -0500
From: Jamal Hadi Salim <jhs@...atatu.com>
To: Jiri Pirko <jiri@...nulli.us>,
Sowmini Varadhan <sowmini.varadhan@...cle.com>
CC: netdev@...r.kernel.org, davem@...emloft.net, nhorman@...driver.com,
andy@...yhouse.net, tgraf@...g.ch, dborkman@...hat.com,
ogerlitz@...lanox.com, jesse@...ira.com, jpettit@...ira.com,
joestringer@...ira.com, john.r.fastabend@...el.com,
sfeldma@...il.com, f.fainelli@...il.com, roopa@...ulusnetworks.com,
linville@...driver.com, simon.horman@...ronome.com,
shrijeet@...il.com, gospo@...ulusnetworks.com, bcrl@...ck.org
Subject: Named sockets WAS(Re: Flows! Offload them.
Sorry - catching up with the discussion; so many parallel topics
buried..
I just wanna put my TU ("thumbs up", yes I didnt want to do the
pedestrian +1) for the named socket concept. With the explosion of
in-kernel sockets all which intend to do host protocol processing
this would be a very nice abstraction to have.
But i do believe this could also be useful for user space redirecting;
we already have very scalable socket code interfacing which could be
taken advantage of.
cheers,
jamal
On 02/26/15 06:39, Jiri Pirko wrote:
> Thu, Feb 26, 2015 at 12:22:52PM CET, sowmini.varadhan@...cle.com wrote:
>> On (02/26/15 08:42), Jiri Pirko wrote:
>>> 6) implement "named sockets" (working name) and implement TC support for that
>>> -ingress qdisc attach, act_mirred target
>>> 7) allow tunnels (VXLAN, Geneve, GRE) to be created as named sockets
>>
>> Can you elaborate a bit on the above two?
>
> Sure. If you look into net/openvswitch/vport-vxlan.c for example, there
> is a socket created by vxlan_sock_add. vxlan_rcv is called on rx and
> vxlan_xmit_skb to xmit.
>
> What I have on mind is to allow to create tunnels using "ip" but not as
> a device but rather just as a wrapper of these functions (and others alike).
>
> To identify the instance we name it (OVS has it identified and vport).
> After that, tc could allow to attach ingress qdisk not only to a device,
> but to this named socket as well. Similary with tc action mirred, it would
> be possible to forward not only to a device, but to this named socket as
> well. All should be very light.
>
>
>>
>> FWIW I've been looking at the problem of RDS over TCP, which is
>> an instance of layered sockets that tunnels the application payload
>> in TCP.
>>
>> RDS over IB provides QoS support using the features available in
>> IB- to supply an analog of that for RDS-TCP, you'd need to plug
>> into tc's CBQ support, and also provide hooks for packet (.1p, dscp)
>> marking.
>>
>> Perhaps there is some overlap to what you are thinking of in #6 and #7
>> above?
>
> I'm not talking about QoS at all. See the description above.
>
> Jiri
>
>>
>> --Sowmini
--
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