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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0D547C6FA8B for ; Tue, 20 Sep 2022 10:44:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230380AbiITKot (ORCPT ); Tue, 20 Sep 2022 06:44:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42862 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230267AbiITKo3 (ORCPT ); Tue, 20 Sep 2022 06:44:29 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 28D166594 for ; Tue, 20 Sep 2022 03:44:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1663670640; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Bryd/YqvBscp2y8ehsVjCoNVOvUucCenOquY6lmdqLE=; b=UPlzEJJf4gFrlhTDrmO3sq2WxICbnWc9HtDAZN0pnND6VuujN4IAQwDRCOlcgwRDLsfOwj 3TJeHDupKS0DM1/BIwbSNCL0Fkwaa9j5nNfDS4/iGQM2VwLtLaLp3h0tkaiUNk7BOTPWOt lj/cqftEqv5Ada1SMskX8IU/T9VOKkU= Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-426-UNFMpZ2bMz6lY0DBAj2SJg-1; Tue, 20 Sep 2022 06:43:59 -0400 X-MC-Unique: UNFMpZ2bMz6lY0DBAj2SJg-1 Received: by mail-qv1-f72.google.com with SMTP id n15-20020ad444af000000b004a2a341ad71so1691469qvt.15 for ; Tue, 20 Sep 2022 03:43:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:user-agent:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date; bh=Bryd/YqvBscp2y8ehsVjCoNVOvUucCenOquY6lmdqLE=; b=cUUhE93Xu2hZrUbOt4Sml+N7umMwrF4QuFRTPawjFbjeRurQMqshpv8W8EY5PypB4p gJdKu8VGVnkyyhUp+un/Vt0kt+WT1sQ/A8GmNVjjoghtyljhypPZ6be+7511ZiEsa4mN HhtVS+3pwKwa+LgtM4CQ8lT8DhNx4k8wdZjkCRGJYEiMGoBSw8aMsDJjb7SMd4MM4MW9 hu+7XdaGbr+hmv50sS8jN4PqMLhqPA6bHL0dV2qAQ23+EabPOYF2BST7qMJ82cu7VGsd aoScQvejnAJl94/wAmjqvqkdlzsTg8M/Hos7EC8jFhjK5biLb3RaemGY+yJOnDz2dHvt TXnA== X-Gm-Message-State: ACrzQf08yE1Qa67zf8QeueW1LjAAex+jhB6XT0X+VhvOnAXipW0DIEs1 6wS3Cr/YfHBHsTqUvsjv9CXlEMDbs/6m0xm+EUvklc8vzHcBvo6SpPeQWyLMYqzg5z5pJyfWTUL Dud90nIQBgcNTX8vjk4FR8ea+m9EI X-Received: by 2002:ad4:5ca2:0:b0:4aa:9d05:2424 with SMTP id q2-20020ad45ca2000000b004aa9d052424mr17937148qvh.71.1663670638672; Tue, 20 Sep 2022 03:43:58 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6Ksp+8em66xjCysoFTBRD+jUUAtxdjlfisN2fuwcZNehJY+I7UeG3BcQTd8r72XLhFC4WzSQ== X-Received: by 2002:ad4:5ca2:0:b0:4aa:9d05:2424 with SMTP id q2-20020ad45ca2000000b004aa9d052424mr17937131qvh.71.1663670638406; Tue, 20 Sep 2022 03:43:58 -0700 (PDT) Received: from gerbillo.redhat.com (146-241-114-90.dyn.eolo.it. [146.241.114.90]) by smtp.gmail.com with ESMTPSA id y8-20020a05620a44c800b006ce16588056sm805177qkp.89.2022.09.20.03.43.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Sep 2022 03:43:57 -0700 (PDT) Message-ID: Subject: Re: [net-next v2 2/3] seg6: add NEXT-C-SID support for SRv6 End behavior From: Paolo Abeni To: Andrea Mayer , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Hideaki YOSHIFUJI , David Ahern , Shuah Khan , linux-kernel@vger.kernel.org, netdev@vger.kernel.org, linux-kselftest@vger.kernel.org, bpf@vger.kernel.org Cc: Stefano Salsano , Paolo Lungaroni , Ahmed Abdelsalam Date: Tue, 20 Sep 2022 12:43:53 +0200 In-Reply-To: <20220912171619.16943-3-andrea.mayer@uniroma2.it> References: <20220912171619.16943-1-andrea.mayer@uniroma2.it> <20220912171619.16943-3-andrea.mayer@uniroma2.it> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.4 (3.42.4-2.fc35) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kselftest@vger.kernel.org On Mon, 2022-09-12 at 19:16 +0200, Andrea Mayer wrote: > The NEXT-C-SID mechanism described in [1] offers the possibility of > encoding several SRv6 segments within a single 128 bit SID address. Such > a SID address is called a Compressed SID (C-SID) container. In this way, > the length of the SID List can be drastically reduced. > > A SID instantiated with the NEXT-C-SID flavor considers an IPv6 address > logically structured in three main blocks: i) Locator-Block; ii) > Locator-Node Function; iii) Argument. > > C-SID container > +------------------------------------------------------------------+ > > Locator-Block |Loc-Node| Argument | > > |Function| | > +------------------------------------------------------------------+ > <--------- B -----------> <- NF -> <------------- A ---------------> > > (i) The Locator-Block can be any IPv6 prefix available to the provider; > > (ii) The Locator-Node Function represents the node and the function to > be triggered when a packet is received on the node; > > (iii) The Argument carries the remaining C-SIDs in the current C-SID > container. > > The NEXT-C-SID mechanism relies on the "flavors" framework defined in > [2]. The flavors represent additional operations that can modify or > extend a subset of the existing behaviors. > > This patch introduces the support for flavors in SRv6 End behavior > implementing the NEXT-C-SID one. An SRv6 End behavior with NEXT-C-SID > flavor works as an End behavior but it is capable of processing the > compressed SID List encoded in C-SID containers. > > An SRv6 End behavior with NEXT-C-SID flavor can be configured to support > user-provided Locator-Block and Locator-Node Function lengths. In this > implementation, such lengths must be evenly divisible by 8 (i.e. must be > byte-aligned), otherwise the kernel informs the user about invalid > values with a meaningful error code and message through netlink_ext_ack. > > If Locator-Block and/or Locator-Node Function lengths are not provided > by the user during configuration of an SRv6 End behavior instance with > NEXT-C-SID flavor, the kernel will choose their default values i.e., > 32-bit Locator-Block and 16-bit Locator-Node Function. > > [1] - https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-srh-compression > [2] - https://datatracker.ietf.org/doc/html/rfc8986 > > Signed-off-by: Andrea Mayer > --- > include/uapi/linux/seg6_local.h | 24 +++ > net/ipv6/seg6_local.c | 335 +++++++++++++++++++++++++++++++- > 2 files changed, 356 insertions(+), 3 deletions(-) > > diff --git a/include/uapi/linux/seg6_local.h b/include/uapi/linux/seg6_local.h > index 332b18f318f8..4fdc424c9cb3 100644 > --- a/include/uapi/linux/seg6_local.h > +++ b/include/uapi/linux/seg6_local.h > @@ -28,6 +28,7 @@ enum { > SEG6_LOCAL_BPF, > SEG6_LOCAL_VRFTABLE, > SEG6_LOCAL_COUNTERS, > + SEG6_LOCAL_FLAVORS, > __SEG6_LOCAL_MAX, > }; > #define SEG6_LOCAL_MAX (__SEG6_LOCAL_MAX - 1) > @@ -110,4 +111,27 @@ enum { > > #define SEG6_LOCAL_CNT_MAX (__SEG6_LOCAL_CNT_MAX - 1) > > +/* SRv6 End* Flavor attributes */ > +enum { > + SEG6_LOCAL_FLV_UNSPEC, > + SEG6_LOCAL_FLV_OPERATION, > + SEG6_LOCAL_FLV_LCBLOCK_BITS, > + SEG6_LOCAL_FLV_LCNODE_FN_BITS, > + __SEG6_LOCAL_FLV_MAX, > +}; > + > +#define SEG6_LOCAL_FLV_MAX (__SEG6_LOCAL_FLV_MAX - 1) > + > +/* Designed flavor operations for SRv6 End* Behavior */ > +enum { > + SEG6_LOCAL_FLV_OP_UNSPEC, > + SEG6_LOCAL_FLV_OP_PSP, > + SEG6_LOCAL_FLV_OP_USP, > + SEG6_LOCAL_FLV_OP_USD, > + SEG6_LOCAL_FLV_OP_NEXT_CSID, > + __SEG6_LOCAL_FLV_OP_MAX > +}; > + > +#define SEG6_LOCAL_FLV_OP_MAX (__SEG6_LOCAL_FLV_OP_MAX - 1) > + > #endif > diff --git a/net/ipv6/seg6_local.c b/net/ipv6/seg6_local.c > index f43e6f0baac1..8370726ae7bf 100644 > --- a/net/ipv6/seg6_local.c > +++ b/net/ipv6/seg6_local.c > @@ -73,6 +73,55 @@ struct bpf_lwt_prog { > char *name; > }; > > +/* default length values (expressed in bits) for both Locator-Block and > + * Locator-Node Function. > + * > + * Both SEG6_LOCAL_LCBLOCK_DBITS and SEG6_LOCAL_LCNODE_FN_DBITS *must* be: > + * i) greater than 0; > + * ii) evenly divisible by 8. In other terms, the lengths of the > + * Locator-Block and Locator-Node Function must be byte-aligned (we can > + * relax this constraint in the future if really needed). > + * > + * Moreover, a third condition must hold: > + * iii) SEG6_LOCAL_LCBLOCK_DBITS + SEG6_LOCAL_LCNODE_FN_DBITS <= 128. > + * > + * The correctness of SEG6_LOCAL_LCBLOCK_DBITS and SEG6_LOCAL_LCNODE_FN_DBITS > + * values are checked during the kernel compilation. If the compilation stops, > + * check the value of these parameters to see if they meet conditions (i), (ii) > + * and (iii). > + */ > +#define SEG6_LOCAL_LCBLOCK_DBITS 32 > +#define SEG6_LOCAL_LCNODE_FN_DBITS 16 > + > +/* The following next_csid_chk_{cntr,lcblock,lcblock_fn}_bits macros can be > + * used directly to check whether the lengths (in bits) of Locator-Block and > + * Locator-Node Function are valid according to (i), (ii), (iii). > + */ > +#define next_csid_chk_cntr_bits(blen, flen) \ > + ((blen) + (flen) > 128) > + > +#define next_csid_chk_lcblock_bits(blen) \ > +({ \ > + typeof(blen) __tmp = blen; \ > + (!__tmp || __tmp > 120 || (__tmp & 0x07)); \ Just a note to mention that in theory a caller could pass a signed argument, so the above check does not ensure that __tmp is acutally >= 8. All the current callers use unsigned arguements, so it still looks safe. Cheers, Paolo