On 2019/11/13 1:53, Toke Høiland-Jørgensen wrote:

Toshiaki Makita [off-list ref] writes:

quoted

Hi Toke,

Sorry for the delay.

On 2019/10/31 21:12, Toke Høiland-Jørgensen wrote:

quoted

Toshiaki Makita [off-list ref] writes:

quoted

On 2019/10/28 0:21, Toke Høiland-Jørgensen wrote:

quoted

Toshiaki Makita [off-list ref] writes:

quoted

quoted

Yeah, you are right that it's something we're thinking about. I'm not
sure we'll actually have the bandwidth to implement a complete solution
ourselves, but we are very much interested in helping others do this,
including smoothing out any rough edges (or adding missing features) in
the core XDP feature set that is needed to achieve this :)

I'm very interested in general usability solutions.
I'd appreciate if you could join the discussion.

Here the basic idea of my approach is to reuse HW-offload infrastructure
in kernel.
Typical networking features in kernel have offload mechanism (TC flower,
nftables, bridge, routing, and so on).
In general these are what users want to accelerate, so easy XDP use also
should support these features IMO. With this idea, reusing existing
HW-offload mechanism is a natural way to me. OVS uses TC to offload
flows, then use TC for XDP as well...

I agree that XDP should be able to accelerate existing kernel
functionality. However, this does not necessarily mean that the kernel
has to generate an XDP program and install it, like your patch does.
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.

Thanks, adding helpers itself should be good, but how does this let users
start using XDP without having them write their own BPF code?

It wouldn't in itself. But it would make it possible to write XDP
programs that could provide the same functionality; people would then
need to run those programs to actually opt-in to this.

For some cases this would be a simple "on/off switch", e.g.,
"xdp-route-accel --load <dev>", which would install an XDP program that
uses the regular kernel routing table (and the same with bridging). We
are planning to collect such utilities in the xdp-tools repo - I am
currently working on a simple packet filter:
https://github.com/xdp-project/xdp-tools/tree/xdp-filter

Let me confirm how this tool adds filter rules.
Is this adding another commandline tool for firewall?

If so, that is different from my goal.
Introducing another commandline tool will require people to learn
more.

My proposal is to reuse kernel interface to minimize such need for
learning.

I wasn't proposing that this particular tool should be a replacement for
the kernel packet filter; it's deliberately fairly limited in
functionality. My point was that we could create other such tools for
specific use cases which could be more or less drop-in (similar to how
nftables has a command line tool that is compatible with the iptables
syntax).

I'm all for exposing more of the existing kernel capabilities to XDP.
However, I think it's the wrong approach to do this by reimplementing
the functionality in eBPF program and replicating the state in maps;
instead, it's better to refactor the existing kernel functionality to it
can be called directly from an eBPF helper function. And then ship a
tool as part of xdp-tools that installs an XDP program to make use of
these helpers to accelerate the functionality.

Take your example of TC rules: You were proposing a flow like this:

Userspace TC rule -> kernel rule table -> eBPF map -> generated XDP
program

Whereas what I mean is that we could do this instead:

Userspace TC rule -> kernel rule table

and separately

XDP program -> bpf helper -> lookup in kernel rule table

Thanks, now I see what you mean.
You expect an XDP program like this, right?

int xdp_tc(struct xdp_md *ctx)
{
	int act = bpf_xdp_tc_filter(ctx);
	return act;
}

But doesn't this way lose a chance to reduce/minimize the program
to only use necessary features for this device?

Toshiaki Makita