From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934285AbdKBDvN (ORCPT ); Wed, 1 Nov 2017 23:51:13 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53898 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934073AbdKBDvL (ORCPT ); Wed, 1 Nov 2017 23:51:11 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com BC3D3C04AC4C Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=jasowang@redhat.com Subject: Re: [PATCH net-next V2 1/3] tun: abstract flow steering logic To: "Michael S. Tsirkin" Cc: Willem de Bruijn , Network Development , LKML , Tom Herbert References: <1509445938-4345-1-git-send-email-jasowang@redhat.com> <1509445938-4345-2-git-send-email-jasowang@redhat.com> <48c178d2-f281-c823-949c-21b79ac3ac64@redhat.com> <20171102054429-mutt-send-email-mst@kernel.org> From: Jason Wang Message-ID: <22150764-5ced-981a-4170-defea16aaafe@redhat.com> Date: Thu, 2 Nov 2017 11:51:03 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171102054429-mutt-send-email-mst@kernel.org> 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.31]); Thu, 02 Nov 2017 03:51:11 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2017年11月02日 11:45, Michael S. Tsirkin wrote: > On Thu, Nov 02, 2017 at 11:43:48AM +0800, Jason Wang wrote: >> >> On 2017年11月02日 09:11, Willem de Bruijn wrote: >>> On Tue, Oct 31, 2017 at 7:32 PM, Jason Wang wrote: >>>> tun now use flow caches based automatic queue steering method. This >>>> may not suffice all user cases. To extend it to be able to use more >>>> flow steering policy, this patch abstracts flow steering logic into >>>> tun_steering_ops, then we can declare and use different methods in >>>> the future. >>>> Signed-off-by: Jason Wang >>>> --- >>>> drivers/net/tun.c | 85 +++++++++++++++++++++++++++++++++++++++++-------------- >>>> 1 file changed, 63 insertions(+), 22 deletions(-) >>>> >>>> diff --git a/drivers/net/tun.c b/drivers/net/tun.c >>>> index ea29da9..bff6259 100644 >>> The previous RFC enabled support for multiple pluggable steering >>> policies. But as all can be implemented in BPF and we only plan to >>> support an eBPF policy besides the legacy one, this patch is no longer >>> needed. We can save a few indirect function calls. >> But we should at least support two kinds of steering policy, so this is >> still needed? >> >> And I'm not quite sure we can implement all kinds of policies through BPF >> e.g RSS or we may want to offload the queue selection to underlayer switch >> or nic . >> >> Thanks > I think a simple if condition is preferable for now, too. Let's wait > until we get some 3/4 of these. > That's a solution but we may need if in at least four places. If this is ok, I will do it in next version. Thanks