Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752577AbdI1HyY (ORCPT ); Thu, 28 Sep 2017 03:54:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56718 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751998AbdI1HyR (ORCPT ); Thu, 28 Sep 2017 03:54:17 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 0D23A29A4E Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=jasowang@redhat.com Subject: Re: [PATCH net-next 0/3] support changing steering policies in tuntap To: Tom Herbert , Willem de Bruijn Cc: "Michael S. Tsirkin" , Network Development , LKML References: <1506500637-13881-1-git-send-email-jasowang@redhat.com> <20170927230042-mutt-send-email-mst@kernel.org> From: Jason Wang Message-ID: <075d507f-9666-f13d-11fa-1d0eb694a3f7@redhat.com> Date: Thu, 28 Sep 2017 15:53:58 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Thu, 28 Sep 2017 07:54:17 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1077 Lines: 24 On 2017年09月28日 13:02, Tom Herbert wrote: > On Wed, Sep 27, 2017 at 4:25 PM, 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. >> >> Fanout accrued various strategies until it gained an eBPF variant. Just >> supporting BPF is probably sufficient here, too. > +1, in addition to packet fanout, we have SO_REUSEPORT with BPF, RPS, > RFS, etc. It would be nice if existing packet steering mechanisms > could be leveraged for tun. This could be done by using the API introduced in this series, I can try this in V2. Thanks