Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752036AbdI1QJt (ORCPT ); Thu, 28 Sep 2017 12:09:49 -0400 Received: from mail-oi0-f51.google.com ([209.85.218.51]:43571 "EHLO mail-oi0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750955AbdI1QJr (ORCPT ); Thu, 28 Sep 2017 12:09:47 -0400 X-Google-Smtp-Source: AOwi7QDLWkfNDVXJgXENJbNQOn3E64S6UerOKNurSagVxwyVortPtH2pUx2cuCYKmAR+vXZ5Q1ru3bYHvl9EnrX8HLw= MIME-Version: 1.0 In-Reply-To: <26f01b12-396e-6319-0eed-c987930e0ed9@redhat.com> References: <1506500637-13881-1-git-send-email-jasowang@redhat.com> <20170927230042-mutt-send-email-mst@kernel.org> <26f01b12-396e-6319-0eed-c987930e0ed9@redhat.com> From: Willem de Bruijn Date: Thu, 28 Sep 2017 12:09:05 -0400 Message-ID: Subject: Re: [PATCH net-next 0/3] support changing steering policies in tuntap To: Jason Wang Cc: "Michael S. Tsirkin" , Network Development , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nfs id v8SG9qdP002023 Content-Length: 1543 Lines: 37 On Thu, Sep 28, 2017 at 3:23 AM, Jason Wang 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.