DPDK patches and discussions
 help / color / Atom feed
From: Ophir Munk <ophirmu@nvidia.com>
To: Ferruh Yigit <ferruh.yigit@intel.com>,
	oulijun <oulijun@huawei.com>,
	"wenzhuo.lu@intel.com" <wenzhuo.lu@intel.com>,
	"beilei.xing@intel.com" <beilei.xing@intel.com>,
	NBU-Contact-Adrien Mazarguil <adrien.mazarguil@6wind.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	"linuxarm@huawei.com" <linuxarm@huawei.com>,
	Ori Kam <orika@nvidia.com>
Subject: Re: [dpdk-dev] [PATCH v5] app/testpmd: fix the default RSS key configuration
Date: Fri, 16 Oct 2020 14:59:58 +0000
Message-ID: <DM5PR12MB11618D20FA63EAA60A9E02F0DC030@DM5PR12MB1161.namprd12.prod.outlook.com> (raw)
In-Reply-To: <8d592d3e-bace-eb50-a3af-4a0bb87ddae8@intel.com>



Ferruh Yigit <ferruh.yigit@intel.com> wrote:
> Sent: Friday, October 16, 2020 1:57 PM
> >> Lijun's idea can work. There was a problem in implementation related
> >> to the key size assumption, which can be fixed.
> >>
> >> Even it is fixed, when user gives a rss rule without a key, we are
> >> getting key from device and feeding same key back to device, this is
> unnecessary I think.
> >> When user didn't provide a key, rss rule shouldn't touch the key at all.
> >>
> > Do you mean that the driver should not configure the key to the
> > hardware when the RSS key is not specified?
> 

I would consider 2 user types:
1. A user who knows the HW capabilities and wish to get a distribution by specifying an explicit key.
2. A clueless user that is not familiar with the NIC HW. For example, a switching application which runs on any NIC. In that case the switching application will not configure a key. The HW driver can decide to configure the default key if not configured.
On the rte flow level we should communicate to the PMD that no key was specified.
Inside the PMD any decision can be taken (e.g. configuring the default key).
All of this is supported by PMD call backs to rte calls such as flow_validate(), flow_translate().

> We are talking about 'key' in RSS rte flow rule, not generally configuring the
> device for RSS.
> 
> If a specific rss rte flow rule, lets say to filter some defined packets to some
> specific queues, don't have 'key' as a part of rule, I am suggesting not touch
> 'key' configuration of the device.
> 
> > If so, we cannot identify when the user does not specify the RSS key
> > to determine whether to configure the key.
> 
> I think we can. If the rule has 'key' attribute, driver can use that key to
> program the device, if 'key' attribute is missing, don't do anything related to
> the rss key.

The driver is free to take any decision when a key is missing.
 
> > In hardware design, most vendors do not configure keys for hardware
> > independently, which may be associated with other RSS config parameters.
> > I think it would be reasonable for us to reconfigure the RSS key with
> > the default value configured and valid in the hardware as the default
> > value if the user does not specify the RSS key.
> 
> There are already APIs to update the RSS configuration, like RSS key, hash
> functions etc.. They are independent from the rte flow RSS rule.
> Application should configure RSS according needs using those APIs.
> 
> The question here is about each RSS rte flow rule that can update the key.
> Am I missing something?
> 
> >> Complication was when user provides key_len without a key, I think
> >> both ignoring or returning error in this case is OK.
> > I agree. However, I think it is meaningless to expose the RSS key
> > length to users. Do you consider deleting the RSS key length directly?
> 
> Isn't both 'key' and 'key_len' needed to program the RSS key? Can the driver
> know the size of the 'key' without 'key_len'?
> And driver should verify these provided values.

The key_len must be explicit. Key itself is just a pointer to an array of bytes. 


  reply index

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-10  1:51 [dpdk-dev] [PATCH v3] " Lijun Ou
2020-09-22  9:51 ` Phil Yang
2020-09-22 13:50   ` oulijun
2020-09-22 15:44     ` Phil Yang
2020-09-24 13:45 ` [dpdk-dev] [PATCH v4] RSS key use with testpmd Lijun Ou
2020-09-24 13:45   ` [dpdk-dev] [PATCH v4] app/testpmd: fix the default RSS key configuration Lijun Ou
2020-09-29 15:35     ` Phil Yang
2020-09-30 12:57     ` Ferruh Yigit
2020-10-09 11:55       ` oulijun
2020-10-09 18:27         ` Ferruh Yigit
2020-10-09 18:54           ` Ferruh Yigit
2020-09-30 13:36     ` Ferruh Yigit
2020-10-09 11:59       ` oulijun
2020-10-09 18:36         ` Ferruh Yigit
2020-10-15 12:41     ` [dpdk-dev] [PATCH v5] " Lijun Ou
2020-10-15 13:52       ` Ferruh Yigit
2020-10-15 14:04         ` oulijun
2020-10-15 14:43           ` Ferruh Yigit
2020-10-15 16:05             ` Ferruh Yigit
2020-10-15 23:21               ` Ophir Munk
2020-10-15 23:53                 ` Ferruh Yigit
2020-10-16  0:14                   ` Ajit Khaparde
2020-10-16  6:46                   ` Ophir Munk
2020-10-16 10:05                     ` oulijun
2020-10-16 15:13                       ` Ophir Munk
2020-10-16 10:04                   ` oulijun
2020-10-16 10:57                     ` Ferruh Yigit
2020-10-16 14:59                       ` Ophir Munk [this message]
2020-10-20  9:00                       ` oulijun
2020-10-20 10:02                         ` Ferruh Yigit
2020-10-20 13:35                           ` oulijun
2020-10-20 14:34                             ` Ferruh Yigit
2020-10-21  8:19                               ` oulijun
2020-10-21  9:38                                 ` Ferruh Yigit
2020-10-21 10:07                                   ` oulijun
     [not found]       ` <20201015195637.26476-1-robot@bytheb.org>
2020-10-16  9:39         ` [dpdk-dev] |WARNING| pw80899 " oulijun
2020-10-16  9:41           ` David Marchand
2020-09-30 13:17   ` [dpdk-dev] [PATCH v4] RSS key use with testpmd Ferruh Yigit
2020-10-09 12:09     ` oulijun
2020-10-09 18:52       ` Ferruh Yigit
2020-10-10  3:07         ` Phil Yang
2020-10-14  6:15         ` oulijun
2020-10-14  8:41           ` Ferruh Yigit
2020-10-15 12:30 [dpdk-dev] [PATCH v5] app/testpmd: fix the default RSS key configuration Lijun Ou

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DM5PR12MB11618D20FA63EAA60A9E02F0DC030@DM5PR12MB1161.namprd12.prod.outlook.com \
    --to=ophirmu@nvidia.com \
    --cc=adrien.mazarguil@6wind.com \
    --cc=beilei.xing@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=linuxarm@huawei.com \
    --cc=orika@nvidia.com \
    --cc=oulijun@huawei.com \
    --cc=wenzhuo.lu@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

DPDK patches and discussions

Archives are clonable:
	git clone --mirror http://inbox.dpdk.org/dev/0 dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dev dev/ http://inbox.dpdk.org/dev \
		dev@dpdk.org
	public-inbox-index dev


Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.dev


AGPL code for this site: git clone https://public-inbox.org/ public-inbox