From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id E48D1A04AA; Tue, 8 Sep 2020 11:31:03 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 7D1A61BEAC; Tue, 8 Sep 2020 11:31:03 +0200 (CEST) Received: from mail-qk1-f195.google.com (mail-qk1-f195.google.com [209.85.222.195]) by dpdk.org (Postfix) with ESMTP id B1C45255 for ; Tue, 8 Sep 2020 11:31:02 +0200 (CEST) Received: by mail-qk1-f195.google.com with SMTP id q5so12446512qkc.2 for ; Tue, 08 Sep 2020 02:31:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PsBB1r+nT5++oKpMHfuJ5YNPFCjzCMKo0e9wrwcM6bU=; b=Dma1iPYzQojgaHlKKSmEzH13+qgJn0xOSK5YtcgdUP1JsksIIDeyAWdFPKC6ItnOlj z89x+30wxtl/ItBhs6z0shkDkR602XUL7yjIDdhamwe3o49J7PSXwizq2O5bZ/zRDBjf 5b8EtMd1Pmi5aLkPIc7h99cBcsEFn76rKnlJSkEf9SR1AMUTDuHJPrujyjdzmSHz6wt5 Sn5ioq8vl/TlDeuc6xX9FCit8+kyiV02xMB6E+T2TonY+eiUFSwf06Phg2sfK3+uks4V EfOttrfo0uWsjWqfRsC1PCYisM7oNFKHp23cIgW7gVYKiCS9jYn6jKunBcxEfxZ6bl60 ciog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PsBB1r+nT5++oKpMHfuJ5YNPFCjzCMKo0e9wrwcM6bU=; b=KxxFWU2miXpgKEHaGAK6pezqpFv1Sv+Z0QXdaPXxuH8sDmh+ABxfdrQpF0Pv9u1n0l FdXpc27r8A7L70faJ5yNU7vdX06uuH0WnBp6mSJx98iOP0LfKDFAiyqjrxn44esF6bvR 7YD1AUa9VciLKfSiaoXB/pmpbBBLoT3FxHuvOnvlRqD1Vbf0/P1Xl5lN9q84HDwof6Xd L9E8gGybotZo3ochbColqO2bDnr8ne1tseY6tkR+LQ3Ll0z/3RBM7G13M+Y1Ft02uZ/O MQABVOXg1EvPAk6qoiGKa4akxYC1BbB8bm6BATjFxQXPLXun07/amRiRjk9Kcp0yFRoJ OhAw== X-Gm-Message-State: AOAM533dUxLO52R4uii1bWZWyO1dVTo0GK6iya37z1vjk4cQKM/i6w7A 407DCjC26QwgLBF8reXJo5VeXVPhXjbYAlJeuT053w== X-Google-Smtp-Source: ABdhPJyt1OpvByc+a5U1KYdwjn7Jsqs57PIwBLNHgD3nYbomoXGqPpgYYP8Hlt1dM4M6ipmmgcHkASdfBoGWo9ltLfg= X-Received: by 2002:a05:620a:89e:: with SMTP id b30mr23647813qka.231.1599557461983; Tue, 08 Sep 2020 02:31:01 -0700 (PDT) MIME-Version: 1.0 References: <6e8b7c61a92b51749b11ac3bfae5c0201352f9b3.1596550675.git.dekelp@mellanox.com> <078b987cd79226d2e2f491d7b994bc7a421e8d3f.1596710212.git.dekelp@mellanox.com> In-Reply-To: <078b987cd79226d2e2f491d7b994bc7a421e8d3f.1596710212.git.dekelp@mellanox.com> From: Maxime Leroy Date: Tue, 8 Sep 2020 11:30:50 +0200 Message-ID: To: Dekel Peled Cc: ferruh.yigit@intel.com, arybchenko@solarflare.com, Ori Kam , Thomas Monjalon , Asaf Penso , matan@mellanox.com, Eli Britstein , dev@dpdk.org Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [RFC v2] ethdev: add VLAN attributes to ETH and VLAN items X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Dekel, On Thu, Aug 6, 2020 at 12:40 PM Dekel Peled wrote: > > In existing code the match on tagged/untagged packets is not explicit. > Recent documentation update [1] describes the different patterns and > clarifies the intended use of different patterns. > > This patch proposes an update to ETH and VLAN items struct, to clearly > define the required characteristic of a packet, and enable precise > match criteria. > > [1] https://mails.dpdk.org/archives/dev/2020-May/166257.html First, I still don't understand the initial change [1] done on RTE_FLOW API. Before this change, it was possible to match any packets with or without vlan encapsulations. At least, it's not anymore possible the case with the mlx5 pmd since this change. For example, if I want to match any ssh packets whatever if it's encapsulated with no vlan or N vlan headers: testpmd> flow create 0 ingress pattern eth type spec 0 type mask 0 / ipv4 / udp dst is 22 / end actions mark id 2 / queue index 0 / end By setting the ethernet type mask to 0x0, it means that ethernet type should be ignored. It means if ethernet type is 0x800 (i.e. ipv4) or 0x8100 (i.e. vlan) or 0x88A8 (qinq), the packet should be matched. Why is it not anymore supported to create a rule matching any ip packets (with/without vlan header) ? How is RFC handling this issue ? > > Signed-off-by: Dekel Peled > --- > lib/librte_ethdev/rte_flow.h | 16 +++++++++++++--- > 1 file changed, 13 insertions(+), 3 deletions(-) > > diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.h > index cf0eccb..0e0b8d4 100644 > --- a/lib/librte_ethdev/rte_flow.h > +++ b/lib/librte_ethdev/rte_flow.h > @@ -723,14 +723,18 @@ struct rte_flow_item_raw { > * If the @p type field contains a TPID value, then only tagged packets with the > * specified TPID will match the pattern. > * Otherwise, only untagged packets will match the pattern. > - * If the @p ETH item is the only item in the pattern, and the @p type field > - * is not specified, then both tagged and untagged packets will match the > - * pattern. > + * The field @p vlan_exist can be used to match specific packet types, instead > + * of using the @p type field. > + * This can be used to match any type of tagged packets. > + * If the @p type and @p vlan_exist fields are not specified, then both tagged > + * and untagged packets will match the pattern. > */ > struct rte_flow_item_eth { > struct rte_ether_addr dst; /**< Destination MAC. */ > struct rte_ether_addr src; /**< Source MAC. */ > rte_be16_t type; /**< EtherType or TPID. */ > + uint32_t vlan_exist:1; /**< At least one VLAN exist in header. */ > + uint32_t reserved:31; /**< Reserved, must be zero. */ > }; For vlan_exists=1, it can already be achieved with the following follow: testpmd> flow create 0 ingress pattern eth type spec 0x8100 type mask 0xFFFF / vlan inner_type is 0x800 mask is 0xFFFF / end actions mark id 2 / queue index 0 / end For vlan_exists=0, first you can match ipv4 packets without vlan header like that: testpmd> flow create 0 ingress pattern eth type spec 0x800 type mask 0xffff / ipv4 / end actions mark id 2 / queue index 0 / end For matching ethernet packet without any vlan header, it's not possible today with RTE_FLOW API. But instead of adding a new field each structure for next fields, I think we should introduce an attribute 'NOT' in the rte_flow API. For example, we could add this flow in test pmd like that: testpmd> flow create 0 ingress pattern eth / not vlan / end actions mark id 2 / queue index 0 / end > > /** Default mask for RTE_FLOW_ITEM_TYPE_ETH. */ > @@ -752,10 +756,16 @@ struct rte_flow_item_eth { > * the preceding pattern item. > * If a @p VLAN item is present in the pattern, then only tagged packets will > * match the pattern. > + * The field @p more_vlans_exist can be used to match specific packet types, > + * instead of using the @p inner_type field. > + * This can be used to match any type of tagged packets. > */ > struct rte_flow_item_vlan { > rte_be16_t tci; /**< Tag control information. */ > rte_be16_t inner_type; /**< Inner EtherType or TPID. */ > + uint32_t more_vlans_exist:1; > + /**< At least one more VLAN exist in header, following this VLAN. */ > + uint32_t reserved:31; /**< Reserved, must be zero. */ > }; This can already be achieved with the following RTE_FLOW flows: > flow create 0 ingress pattern eth / vlan inner_type spec is 0x0 mask is 0x0 / ipv4 / end actions mark id 2 / queue index 0 / end By setting inner_type mask to 0, it means that we don't care about inner_type, so inner_type can be any value. Thus it can be 0x8100 for vlan or 0x800 for ipv4. At the end, this rule matches any ipv4 packets with at least one vlan header. Having more_vlan_exist in rte_flow_item_vlan is not useful. Regards, Maxime Leroy > > /** Default mask for RTE_FLOW_ITEM_TYPE_VLAN. */ > -- > 1.8.3.1 >