From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 94C1CC432C1 for ; Wed, 25 Sep 2019 04:08:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6A9602064A for ; Wed, 25 Sep 2019 04:08:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389835AbfIYEI2 (ORCPT ); Wed, 25 Sep 2019 00:08:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39974 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387842AbfIYEI1 (ORCPT ); Wed, 25 Sep 2019 00:08:27 -0400 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 178DA308A98C; Wed, 25 Sep 2019 04:08:27 +0000 (UTC) Received: from [10.72.12.148] (ovpn-12-148.pek2.redhat.com [10.72.12.148]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8BE1F19C58; Wed, 25 Sep 2019 04:08:13 +0000 (UTC) Subject: Re: [PATCH net-next] tuntap: Fallback to automq on TUNSETSTEERINGEBPF prog negative return To: Matt Cover Cc: "Michael S. Tsirkin" , davem@davemloft.net, ast@kernel.org, daniel@iogearbox.net, kafai@fb.com, songliubraving@fb.com, yhs@fb.com, Eric Dumazet , Stanislav Fomichev , Matthew Cover , mail@timurcelik.de, pabeni@redhat.com, Nicolas Dichtel , wangli39@baidu.com, lifei.shirley@bytedance.com, tglx@linutronix.de, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, bpf@vger.kernel.org References: <20190920185843.4096-1-matthew.cover@stackpath.com> <20190922080326-mutt-send-email-mst@kernel.org> <20190922162546-mutt-send-email-mst@kernel.org> <7d3abb5d-c5a7-9fbd-f82e-88b4bf717a0b@redhat.com> From: Jason Wang Message-ID: <76a19f4a-90de-3904-28e2-653dfb6da495@redhat.com> Date: Wed, 25 Sep 2019 12:08:10 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.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-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.41]); Wed, 25 Sep 2019 04:08:27 +0000 (UTC) Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On 2019/9/24 上午12:31, Matt Cover wrote: >> I think it's better to safe to just drop the packet instead of trying to >> workaround it. >> > This patch aside, dropping the packet here > seems like the wrong choice. Loading a > prog at this hookpoint "configures" > steering. The action of configuring > steering should not result in dropped > packets. > > Suboptimal delivery is generally preferable > to no delivery. Leaving the behavior as-is > (i.e. relying on netdev_cap_txqueue()) or > making any return which doesn't fit in a > u16 simply use queue 0 would be highly > preferable to dropping the packet. > >> Thanks It leaves a choice for steering ebpf program to drop the packet that it can't classify. But consider we have already had socket filter, it probably not a big problem since we can drop packets there. Thanks