Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752041AbdI1HXo (ORCPT ); Thu, 28 Sep 2017 03:23:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34090 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751618AbdI1HXn (ORCPT ); Thu, 28 Sep 2017 03:23:43 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 204BD2CA614 Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.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: Willem de Bruijn , "Michael S. Tsirkin" Cc: 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: <26f01b12-396e-6319-0eed-c987930e0ed9@redhat.com> Date: Thu, 28 Sep 2017 15:23:34 +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.38]); Thu, 28 Sep 2017 07:23:43 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1154 Lines: 26 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? Thanks