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 712FEA0487 for ; Tue, 30 Jul 2019 09:42:54 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 6E7961BF19; Tue, 30 Jul 2019 09:42:53 +0200 (CEST) Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) by dpdk.org (Postfix) with ESMTP id 53C3D1BDF1 for ; Tue, 30 Jul 2019 09:42:52 +0200 (CEST) Received: by mail-wm1-f45.google.com with SMTP id a15so56094270wmj.5 for ; Tue, 30 Jul 2019 00:42:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=g4GtksSm92SCc2BuUY4Uaci6HYorygLb+Uk6BQ79iRQ=; b=fhHetbHbVXMOYWuTa99NrXVMOaoCSIS1+mylnFae5jxyL7luaF97zMOU+ViXTUvA6b iGBKuDj9hryvWoz7iCkAqD6vK+kGe63/JFjhdzwlyHCNhHUy8DshuqZZ+QUcQrn0VEn9 iAQgpWzdsjNwXTFryPqYdpzzPZpKwi5LTHkrskDVebYnlM/rranfrlXPBrK3OMQvSTJF taiBWGtAg+cj18GQFrMsD+bWl9f+DHwFn3EcRAzV5cwwmgd+QfexNIpvv4wrQyM8kcdS 8Z57T8+Hee3dKQGzd1/KUjx6OLQqUS01IFT1s75WrKZaKuEkDrpsYF4rpcVmriFU3hWO uI8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=g4GtksSm92SCc2BuUY4Uaci6HYorygLb+Uk6BQ79iRQ=; b=Y/IygWafZ6ocdGKne24cMUnixeE9vrxs4gjGB0tfUszqKPtWepwDTsLA5/SEZCnVNd 1/0H+uijCEhtI8RBarNMrAidjSu9AJZr8oAmsiRkyimD/oSBCa35mEQCYcH5ZLYUMWfM u0jnHFGPsZEeMwTDld4xihsuvmWPFEWYvUWhd6/ggB625+UGo60e9PHuqKbzoJDlkrXt Q+rIhhEEKEnt28DqnMb30VumItgoy2AlEpBDW8qQ4su6euV5L8IdAHvlQDs8WRpK8hLU 6zT7tB0hbJg7EG00zU0xCX7FS/Wucs4fPGA5wFNO7pnJ4pyLGXo1nUA4KDN7/bsbKWWZ 85xg== X-Gm-Message-State: APjAAAVXyM6bUrYa6OqO+iAunkudjUQBFOjLa5ZUIgI7/O5AzkB4jC2p 1vcDRac166W4tLY7/OoZ/zWk7A== X-Google-Smtp-Source: APXvYqw7n+dsOn16BCp3I17Bu7VDMuEtucWVQ/mIoEVenM/KOle/JocJLqMel/gVg/vt/eWARxYFLQ== X-Received: by 2002:a05:600c:224d:: with SMTP id a13mr59363645wmm.62.1564472571915; Tue, 30 Jul 2019 00:42:51 -0700 (PDT) Received: from 6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id g8sm62971894wmf.17.2019.07.30.00.42.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Jul 2019 00:42:51 -0700 (PDT) Date: Tue, 30 Jul 2019 09:42:49 +0200 From: Adrien Mazarguil To: Ori Kam Cc: simei , "qi.z.zhang@intel.com" , "jingjing.wu@intel.com" , "ferruh.yigit@intel.com" , "dev@dpdk.org" Message-ID: <20190730074249.GB4512@6wind.com> References: <1564101350-98092-1-git-send-email-simei.su@intel.com> <1564368251-112891-1-git-send-email-simei.su@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dpdk-dev] [RFC,v3] ethdev: extend RSS offload types 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" On Tue, Jul 30, 2019 at 06:06:56AM +0000, Ori Kam wrote: > Hi Simei, > > > > > -----Original Message----- > > From: dev On Behalf Of simei > > Sent: Monday, July 29, 2019 5:44 AM > > To: qi.z.zhang@intel.com; jingjing.wu@intel.com; ferruh.yigit@intel.com; > > Adrien Mazarguil > > Cc: dev@dpdk.org; simei.su@intel.com > > Subject: [dpdk-dev] [RFC,v3] ethdev: extend RSS offload types > > > > From: Simei Su > > > > Make it easier to represent to define macro values as (1ULL << ###). > > > > This RFC reserves several bits as input set selection from bottom > > of the 64 bits. The flow type is combined with input set to > > represent rss types. > > > > > Why reserve from the bottom? and not from the first available space? I assume the reason is that maintaining the existing model with RTE_ETH_FLOW_* sibling macros doesn't make sense for these, so this approach doesn't impact future ETH_RSS_* definitions... > > for example: > > ETH_RSS_IPV4 | ETH_RSS_INSET_L3_SRC: hash on src ip address only > > ETH_RSS_IPV4_UDP | ETH_RSS_INSET_L4_DST: hash on src/dst IP and > > dst UDP port > > ETH_RSS_L2_PAYLOAD | ETH_RSS_INSET_L2_DST: hash on dst mac address > > > > What happens when the user set ETH_RSS_IPV4? From what I understand from your RFC this will do nothing > since no bits where enabled, am I correct? > If I'm correct this may break applications. Also my thought, again I assume that ETH_RSS_INSET_* flags only act as modifiers to ETH_RSS_IPV4 and friends, if none are provided, then both source and destination are taken into account. If that's the design, it must be properly documented still. Looks like it's time to end the relationship between RTE_ETH_FLOW_* and ETH_RSS_* seeing both serve different purposes, and these new macros only make sense for RSS. I suggest a prior patch that converts all those definitions: #define ETH_RSS_IPV4 (1ULL << RTE_ETH_FLOW_IPV4) [...] To their numerical counterparts directly, in which case we have two options: Without breaking ABI, e.g.: #define ETH_RSS_IPV4 (1ULL << 2) [...] Or going further if we're ready to break ABI a tiny little bit, starting over from zero and use unique flags for IPv4, IPv6, TCP and UDP without distinguishing between NONFRAG, FRAG and IPV6_EX, which never made sense for RSS, and separating L4 from L3 to save even more, that is: #define ETH_RSS_ETH (1ULL << 0) #define ETH_RSS_IPV4 (1ULL << 1) #define ETH_RSS_IPV6 (1ULL << 2) #define ETH_RSS_UDP (1ULL << 3) #define ETH_RSS_TCP (1ULL << 4) #define ETH_RSS_SCTP (1ULL << 5) [...] Then the flags you would like to add would have to be more explicit. I think Qi's original suggestion with "ONLY" was better in this regard than "INSET": #define ETH_RSS_L2_SRC_ONLY (1ULL << 6) #define ETH_RSS_L2_DST_ONLY (1ULL << 7) [...] Otherwise there's still the negative approach: #define ETH_RSS_L2_NO_SRC (1ULL << 6) #define ETH_RSS_L2_NO_DST (1ULL << 7) [...] Not sure which is better. Thoughts? -- Adrien Mazarguil 6WIND