On Thu, Sep 28, 2017 at 3:23 AM, Jason Wang <jasow...@redhat.com> wrote: > > > On 2017年09月28日 07:25, Willem de Bruijn wrote: >>>> >>>> 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). > >> >> 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.
