On Thu, Sep 28, 2017 at 3:23 AM, Jason Wang [off-list ref] wrote:

On 2017年09月28日 07:25, Willem de Bruijn wrote:

quoted

quoted

quoted

In the future, both simple and sophisticated policy like RSS or other
guest
driven steering policies could be done on top.

IMHO there should be a more practical example before adding all this
indirection. And it would be nice to understand why this queue selection
needs to be tun specific.

I was thinking the same and this reminds me of the various strategies
implemented in packet fanout. tun_cpu_select_queue is analogous to
fanout_demux_cpu though it is tun-specific in that it requires
tun->numqueues.

Right, the main idea is to introduce a way to change flow steering policy
for tun. I think fanout policy could be implemented through the API
introduced in this series. (Current flow caches based automatic steering
method is tun specific).

quoted

Fanout accrued various strategies until it gained an eBPF variant. Just
supporting BPF is probably sufficient here, too.

Technically yes, but for tun, it also serve for virt. We probably still need
some hard coded policy which could be changed by guest until we can accept
an BPF program from guest I think?

When would a guest choose the policy? As long as this is under control
of a host user, possibly unprivileged, allowing BPF here is moot, as any
user can run socket filter BPF already. Programming from the guest is
indeed different. I don't fully understand that use case.