[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <47f1a7e2-0d3a-e324-20c5-ba3aed216ddf@gmail.com>
Date: Sun, 27 Oct 2019 21:16:42 -0600
From: David Ahern <dsahern@...il.com>
To: Toke Høiland-Jørgensen <toke@...hat.com>,
Toshiaki Makita <toshiaki.makita1@...il.com>,
John Fastabend <john.fastabend@...il.com>,
Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Martin KaFai Lau <kafai@...com>,
Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <jakub.kicinski@...ronome.com>,
Jesper Dangaard Brouer <hawk@...nel.org>,
Jamal Hadi Salim <jhs@...atatu.com>,
Cong Wang <xiyou.wangcong@...il.com>,
Jiri Pirko <jiri@...nulli.us>,
Pablo Neira Ayuso <pablo@...filter.org>,
Jozsef Kadlecsik <kadlec@...filter.org>,
Florian Westphal <fw@...len.de>,
Pravin B Shelar <pshelar@....org>
Cc: netdev@...r.kernel.org, bpf@...r.kernel.org,
William Tu <u9012063@...il.com>,
Stanislav Fomichev <sdf@...ichev.me>
Subject: Re: [RFC PATCH v2 bpf-next 00/15] xdp_flow: Flow offload to XDP
On 10/27/19 9:21 AM, Toke Høiland-Jørgensen wrote:
> Rather, what we should be doing is exposing the functionality through
> helpers so XDP can hook into the data structures already present in the
> kernel and make decisions based on what is contained there. We already
> have that for routing; L2 bridging, and some kind of connection
> tracking, are obvious contenders for similar additions.
The way OVS is coded and expected to flow (ovs_vport_receive ->
ovs_dp_process_packet -> ovs_execute_actions -> do_execute_actions) I do
not see any way to refactor it to expose a hook to XDP. But, if the use
case is not doing anything big with OVS (e.g., just ACLs and forwarding)
that is easy to replicate in XDP - but then that means duplicate data
and code.
Linux bridge on the other hand seems fairly straightforward to refactor.
One helper is needed to convert ingress <port,mac,vlan> to an L2 device
(and needs to consider stacked devices) and then a second one to access
the fdb for that device.
Either way, bypassing the bridge has mixed results: latency improves but
throughput takes a hit (no GRO).
Powered by blists - more mailing lists