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=-5.5 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, 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 BEE0FC48BDF for ; Fri, 18 Jun 2021 11:40:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 96A8261260 for ; Fri, 18 Jun 2021 11:40:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232616AbhFRLm2 (ORCPT ); Fri, 18 Jun 2021 07:42:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35270 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231969AbhFRLm1 (ORCPT ); Fri, 18 Jun 2021 07:42:27 -0400 Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 47D2CC06175F for ; Fri, 18 Jun 2021 04:40:17 -0700 (PDT) Received: by mail-qk1-x730.google.com with SMTP id q190so7512816qkd.2 for ; Fri, 18 Jun 2021 04:40:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mojatatu-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=hxTpNTjI0kG2nomUBbYf7UdQNAS7vv0AjvB2ZhKjRd4=; b=vUWhZLoZQnftWpUqbkKEAs7oX4Y8HDuqvsdrWjbiMuaNy/IOyEjyRudPJoOyG8ioJB PhxQqeqsH2IvUWd4fYPj/n+V7j/b9UKZSak6jCq7+tDS+lz/BDtuXhlK2BxDWXXE5uM8 kZcUlUdBFkd2HHscrpYQxpwB1PMNbkHdB2qFy5Gk/caH2VWlk8XWmejFP/ub4DteknWu NpFps0LQ9A81ypDUt5R4kFPWKo+6BVtMkec32wSfr2LNnxDebgZiFGFqX7aEPWeXdkQF iDnnrHF+kz1bsVNTWsn9wfWoy1gjIeZeMmN8KMLdj423Ejnh20gp2xVo3Dlc3xszOkhV dlTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=hxTpNTjI0kG2nomUBbYf7UdQNAS7vv0AjvB2ZhKjRd4=; b=kad3ZnLfsG/aebOOEK9kn43M3fsdyJmx+iZebjGvegI6UFVRYiqZQCPUxyvtiQ3bX4 huh8HjJi6XdjPhghjrSyljV/9AQQ5ye/mCN+EtWkB2AOJ2W0U18KmR7EST+8iSIe9jO2 DGaewrE+vEbwJU8fkfMlUQnNHB1w3vKSrsnjJgB+3vovBzZfBJHq6rW2qjQjVAYvWUhJ jOvqkpCO9ym56CNMndFagOk0p5Blk9ovESlE4soLm8X9Zr66jozr0DruH0VqdOcd9d8A siF9hQtzwe4tDAYOcd/XnjRnkJoW/87DJW8UgrUMcnF7y3c4BSaqnAYyPbocesLhlVVy 4wIQ== X-Gm-Message-State: AOAM530+v+MQPexJp2CLFtrwfCppjcxFewB93qadt854++ViA3ZuOSqL yrObN/ZEYnUBZ0eOABg4ZwjLNg== X-Google-Smtp-Source: ABdhPJy03kwyCgBBJW2pNwyMwghGikCC0q7D2VookmGkvCzHvd8zkTJsJqR9pef4zzVKKHyXv62Esw== X-Received: by 2002:a37:b741:: with SMTP id h62mr9117585qkf.78.1624016416403; Fri, 18 Jun 2021 04:40:16 -0700 (PDT) Received: from [192.168.1.171] (bras-base-kntaon1617w-grc-28-184-148-47-211.dsl.bell.ca. [184.148.47.211]) by smtp.googlemail.com with ESMTPSA id g1sm3703243qkd.125.2021.06.18.04.40.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 18 Jun 2021 04:40:15 -0700 (PDT) Subject: Re: [PATCH RFC bpf-next 0/7] Add bpf_link based TC-BPF API To: Daniel Borkmann , Kumar Kartikeya Dwivedi Cc: Cong Wang , bpf , Alexei Starovoitov , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Vlad Buslov , Jiri Pirko , "David S. Miller" , Jakub Kicinski , Joe Stringer , Quentin Monnet , Jesper Dangaard Brouer , =?UTF-8?Q?Toke_H=c3=b8iland-J=c3=b8rgensen?= , Linux Kernel Network Developers , Marcelo Ricardo Leitner References: <20210607060724.4nidap5eywb23l3d@apollo> <20210608071908.sos275adj3gunewo@apollo> <20210613025308.75uia7rnt4ue2k7q@apollo> <30ab29b9-c8b0-3b0f-af5f-78421b27b49c@mojatatu.com> <20210613203438.d376porvf5zycatn@apollo> <4b1046ef-ba16-f8d8-c02e-d69648ab510b@mojatatu.com> <7248dc4e-8c07-a25d-5ac3-c4c106b7a266@mojatatu.com> <20210616153209.pejkgb3iieu6idqq@apollo> <05ec2836-7f0d-0393-e916-fd578d8f14ac@iogearbox.net> From: Jamal Hadi Salim Message-ID: Date: Fri, 18 Jun 2021 07:40:13 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <05ec2836-7f0d-0393-e916-fd578d8f14ac@iogearbox.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On 2021-06-16 12:00 p.m., Daniel Borkmann wrote: > On 6/16/21 5:32 PM, Kumar Kartikeya Dwivedi wrote: >> On Wed, Jun 16, 2021 at 08:10:55PM IST, Jamal Hadi Salim wrote: >>> On 2021-06-15 7:07 p.m., Daniel Borkmann wrote: >>>> On 6/13/21 11:10 PM, Jamal Hadi Salim wrote: [..] >>> >>> In particular, here's a list from Kartikeya's implementation: >>> >>> 1) Direct action mode only > > (More below.) > >>> 2) Protocol ETH_P_ALL only > > The issue I see with this one is that it's not very valuable or useful > from a BPF > point of view. Meaning, this kind of check can and typically is > implemented from > BPF program anyway. For example, when you have direct packet access > initially > parsing the eth header anyway (and from there having logic for the > various eth > protos). In that case make it optional to specify proto and default it to ETH_P_ALL. As far as i can see this flexibility doesnt complicate usability or add code complexity to the interfaces. > > That protocol option is maybe more useful when you have classic tc with > cls+act > style pipeline where you want a quick skip of classifiers to avoid > reparsing the > packet. Given you can do everything inside the BPF program already it > adds more > confusion than value for a simple libbpf [tc/BPF] API. > There's no point in repeating an operation of identifying the protocol type which can/has already be Id-ed by the calling (into ebpf) code. If all i am interested in is IPv4, then my ebpf parser can be simplified if i am sure i can assume it is an IPv4 packet. [..] >>> 1) We use non-DA mode, so i cant live without that (and frankly ebpf >>> has challenges adding complex code blocks). > > Could you elaborate on that or provide code examples? Since introduction > of the > direct action mode I've never used anything else again, and we do have > complex > BPF code blocks that we need to handle as well. Would be good if you > could provide > more details on things you ran into, maybe they can be solved? > Main issue is code complexity in ebpf and not so much instruction count (which is complicated once you have bounded loops). Earlier, I tried to post on the ebpf list but i got no response. I moved on since. I would like to engage you at some point - and you are right there may be some clever tricks to achieve the goals we had. The challenge is in keeping up with the bag of tricks to make the verifier happy. Being able to run non-da mode and for example attach an action such as the policer (and others) has pragmatic uses. It would be quiet complex to implement the policer within an all-in-one-appliance da-mode ebpf code. One approach is to add more helpers to invoke such code directly from ebpf - but we have some restrictions; the deployment is RHEL8.3 based and we have to live with the kernel features supported there. i.e kernel upgrade is a no-no. Given all these TC features have existed (and stable) for 100 years it make a lot of sense to use them. We are going to present some of the challenges we faced in a subset of our work in an approach to replace iptables at netdev 0x15 (hopefully we get accepted). cheers, jamal