From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by dpdk.org (Postfix) with ESMTP id D87DE5323 for ; Wed, 14 Nov 2018 10:41:00 +0100 (CET) Received: by mail-wr1-f68.google.com with SMTP id u5-v6so11202233wrn.9 for ; Wed, 14 Nov 2018 01:41:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=fiMoxf//XgB7aIeBbZ92v03XYNRq7B48bfIeJ8NIl24=; b=JRWU/laiBXLZdnFsRnrbrG56b6FIzOi5442xW+IcFYBZZS7zJjnMkjX5Rjq7VRZarU Vl+9SbOjT883xgBUFjl1AikwAulrodsybcffzJ6hO1nHJY93SdbyxfkVvi0PahLyknIA AgVddkruQwXjCQj3LWeENYNhdxRloTcB7RWhXw32QQzfzK0Vb8JSpCVNIYlwIKTLrAbi rujchNbK8W+2/oqdRS7EmMc9uWK+mGN7TsnrUxYdZQJockRvbqH3o2FkV8syuWJbq6Cs KK9TpKeDqHaf0RrH7iCd2w2rpFZoBuFIxtozydxYNZ6kN2EuvANv7t3yfDiFm6kQaxRV wdsg== 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=fiMoxf//XgB7aIeBbZ92v03XYNRq7B48bfIeJ8NIl24=; b=LA0bOykIsuyi21RyUjSrZpo81if2jCTqSYyjwHgGKVW3Vr7WX8/ZJJXV0V73/JgPIg BxjL2ubV8ja+qIeOXjaf12k1Wz3q0l2twyY4mpTIhCOnD5IgTPtZL1xW4tTA+rwfzIdJ xFoNDwvTiR8tuM+vfQkhGaWgQxqANXPltpMVNgn14Odu0fpipe7libFBht/lkHdhd+OM qjQfZvu8aaGSCVrMFTWXh2xMLwoU5Lk4fKw9oN+AwIhW+0UVhLPun1JwcKDAVVw+yB/l 4wejTKotzVqkYctVGl/YNrl8ly8g0Jz/lEapWIEibIe9wNJAE0fGQ7VHqTjCcwI1bjPd a34w== X-Gm-Message-State: AGRZ1gLkzlm4abWnR8aUnNu6LUrBEU96QFCh5Dj18ZxzGY0OksHrqAAy Gi52X+PFjmpOHIbkZ6hhhRXlpw== X-Google-Smtp-Source: AJdET5cV1AM5HSKHWBABjFqC0r+N0BEBg+cCWA71Prfdd+0NGOOjq62FmK1/3RlksF/0k3OSp3rjLQ== X-Received: by 2002:adf:e406:: with SMTP id g6-v6mr1144268wrm.277.1542188460551; Wed, 14 Nov 2018 01:41:00 -0800 (PST) Received: from 6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id g5-v6sm27759523wrw.97.2018.11.14.01.40.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Nov 2018 01:40:59 -0800 (PST) Date: Wed, 14 Nov 2018 10:40:40 +0100 From: Adrien Mazarguil To: Shahaf Shuler Cc: Ori Kam , Ophir Munk , Yongseok Koh , Andrew Rybchenko , Ferruh Yigit , "dev@dpdk.org" , Thomas Monjalon , Asaf Penso , Olga Shern Message-ID: <20181114094040.GG17131@6wind.com> References: <20181107140604.GL4638@6wind.com> <20181107164118.GM4638@6wind.com> <20181113171519.GF17131@6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dpdk-dev] [PATCH v2] ethdev: document RSS default key and 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: , X-List-Received-Date: Wed, 14 Nov 2018 09:41:01 -0000 Hi Shahaf, On Tue, Nov 13, 2018 at 06:39:04PM +0000, Shahaf Shuler wrote: > Hi Adrien, > > Tuesday, November 13, 2018 7:15 PM, Adrien Mazarguil: > > Subject: Re: [dpdk-dev] [PATCH v2] ethdev: document RSS default key and > > types > > > > Again a bit late to the party, please see below. > > > > On Sun, Nov 11, 2018 at 09:35:22AM +0000, Ori Kam wrote: > > [...] > > > > > The setfault is the result of commit a4391f8bae ("app/testpmd: set > > > > default RSS key as null"). > > > > Reverting this commit should fix the segfault but it also means > > > > there is no way to set default key (key=NULL) with testpmd. > > > > Need to check if this is only a testpmd limitation and not all > > > > applications limitation. > > > > > > > > We should decide how an application can set default RSS without > > > > knowing anything about keys. > > > > > > > > > > I agree with Adrian that the main criteria should be the length. > > > Maybe the set default RSS in testpmd should get new parameter. > > > > Since [1] was reverted and we seem to agree that a zero key_len should > > trigger a PMD-specific default key, this can already be requested with > > testpmd by overriding key_len, e.g.: > > > > flow create 1 pattern eth / end actions rss key_len 0 / end > > > > Using an empty string as the key would yield the same result but cannot be > > expressed on the command line yet. Note that specifying a key automatically > > overrides key_len, so key_len must be forced to 0 last to get PMD defaults: > > > > flow create 1 pattern eth / end actions rss key foo key_len 0 / end > > I don't understand why we are backing up API claims with "how testpmd is implemented". The APIs should be correct, regardless of how testpmd is using them. This wasn't the intent, I mean, currently one cannot input something like that to get a zero key length: flow create 1 pattern eth / end actions rss key "" / end Because "" is interpreted literally. So the only way to request a zero key length is by explicitly setting it through "key_len 0". The API remains clear: a zero key length requests default behavior from the PMD regardless of the key pointer, which doesn't *have* to be NULL, merely undefined. Testpmd does exactly that. > To this doc issue, > I don't understand on what cases it makes sense for application to have rss_key_len = 0 while rss_key != NULL. This is obviously in-consist input, and of course all PMD will just ignore the key. > I think enforcing rss_key and rss_key_len to be NULL is a fair requirement from application, and it makes no confusion in the API inputs. Then you need to define what happens when key_len != 0 and key == NULL, also when key_len == 0 and key != NULL, none of which make sense currently. There's no reason for the PMD to even look at the key pointer if key_len is 0. Only if nonzero, it *can* check for its validity however there's no reason to, it's a programming error in the application if not the case. assert() is more appropriate for such situations. I agree there's a lack of documentation which must be addressed, my point is that key_len is the only guarantee a PMD needs from the application. > > Here key_len is set to testpmd's default size when parsing "rss", updated to > > 3 when parsing "key foo" and updated once again when parsing "key_len 0". > > > > Lastly, while it would make sense for testpmd to use 0 as the default value, > > doing so yields inconsistent balancing results between vendors/devices as > > they all come with a different key. Same reason as initializing the RSS types > > field to the global rss_hf instead of 0. > > > > > > > [1] "app/testpmd: revert setting default RSS" > > > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma > > ils.dpdk.org%2Farchives%2Fdev%2F2018- > > November%2F118786.html&data=02%7C01%7Cshahafs%40mellanox.co > > m%7C0eecf3e9af4b4b6bc53108d6498ba2a8%7Ca652971c7d2e4d9ba6a4d1492 > > 56f461b%7C0%7C0%7C636777261425388073&sdata=Hu0iGr2xS%2FI%2FI > > s5PtzCylMMft5w5TBmtd3GYppEKKcA%3D&reserved=0 -- Adrien Mazarguil 6WIND