Ferruh Yigit <ferruh.yi...@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.
