DPDK-dev Archive on lore.kernel.org
 help / color / Atom feed
From: Shahaf Shuler <shahafs@mellanox.com>
To: Andrew Rybchenko <arybchenko@solarflare.com>,
	"pbhagavatula@marvell.com" <pbhagavatula@marvell.com>,
	"jerinj@marvell.com" <jerinj@marvell.com>,
	"ferruh.yigit@intel.com" <ferruh.yigit@intel.com>,
	John McNamara <john.mcnamara@intel.com>,
	Marko Kovacevic <marko.kovacevic@intel.com>,
	Thomas Monjalon <thomas@monjalon.net>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH 2/7] ethdev: add mbuf RSS update as a offload
Date: Sun, 18 Aug 2019 12:11:51 +0000
Message-ID: <AM0PR0502MB37950E69478E1472E6E70DF6C3A90@AM0PR0502MB3795.eurprd05.prod.outlook.com> (raw)
In-Reply-To: <1a33f43e-6449-dffe-a6c9-c3d5c7118dae@solarflare.com>



> -----Original Message-----
> From: Andrew Rybchenko <arybchenko@solarflare.com>
> Sent: Sunday, August 18, 2019 10:01 AM
> To: Shahaf Shuler <shahafs@mellanox.com>; pbhagavatula@marvell.com;
> jerinj@marvell.com; ferruh.yigit@intel.com; John McNamara
> <john.mcnamara@intel.com>; Marko Kovacevic
> <marko.kovacevic@intel.com>; Thomas Monjalon <thomas@monjalon.net>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 2/7] ethdev: add mbuf RSS update as a
> offload
> 
> On 8/18/19 9:18 AM, Shahaf Shuler wrote:
> > Sunday, August 18, 2019 8:39 AM, Andrew Rybchenko:
> >> <marko.kovacevic@intel.com>; Thomas Monjalon
> <thomas@monjalon.net>
> >> Cc: dev@dpdk.org
> >> Subject: Re: [dpdk-dev] [PATCH 2/7] ethdev: add mbuf RSS update as a
> >> offload
> >>
> >> On 8/18/19 7:52 AM, Shahaf Shuler wrote:
> >>> Friday, August 16, 2019 10:48 AM, Andrew Rybchenko:
> >>>> Subject: Re: [dpdk-dev] [PATCH 2/7] ethdev: add mbuf RSS update as
> >>>> a offload
> >>>>
> >>>> On 8/16/19 8:55 AM, pbhagavatula@marvell.com wrote:
> >>>>> From: Pavan Nikhilesh <pbhagavatula@marvell.com>
> >>>>>
> >>>>> Add new Rx offload flag `DEV_RX_OFFLOAD_RSS_HASH` which can be
> >> used
> >>>> to
> >>>>> enable/disable PMDs write to `rte_mbuf::hash::rss`.
> >>>> It should be highlighted that presence of the RSS hash is indicated
> >>>> by PKT_RX_RSS_HASH flag in mbuf anyway. Now applications have a
> way
> >>>> to check that RSS hash delivery is supported and should enable the
> >>>> offload if RSS hash is used. PMD may still provide the hash even if
> >>>> the offload is not enabled.
> >>> I don't understand how PMDs should act w/ this addition when
> >>> considering
> >> the API breakage to application.
> >>
> >> There is a deprecation notice for it.
> >> I mentioned in my review notes for one of patches in the series that
> >> the change should be highlighted in release notes.
> >> Yes, it is absolutely required if these patches are accepted.
> >>
> >>> Currently application don't set this flag, and expect to get the RSS
> >>> hash
> >> result on mbuf.
> >>> If PMDs will not set the RSS hash result when flag is not present
> >>> then
> >> applications might break.
> >>> If they will always set, then there is no meaning for it.
> >>>
> >>> as I understand the motivation to save few cycles on the PMD receive
> >>> path,
> >> if we want to include it we should treat it as API breakage and
> >> documents it on the release notes.
> >>> My option is that some offload should just be usable (OOB) by the
> >>> fact user
> >> enabled them (e.g. RSS). no need to complicate the user by checking
> >> and set this field.
> >>
> >> What I don't understand is why some offloads should just work but
> >> another requires action to enable it. Just because it is the current
> >> state of things - I don't think it is a good motivation. Sorry.
> > Not because it is the current state of things, because it makes user
> experience much simpler.
> 
> If so, it would be simpler to have no controls at all and always have
> everything possible.
> 
> > You enabled RSS -> you get full RSS behavior
> 
> You enable distribution across many queues here.
> RSS hash availability is a side effect here.

I disagree.

There is at least one RSS spec (Microsoft NDIS) that define it part of the RSS action. [1]
Bottom of page " The NIC always passes on the 32-bit hash value." 

Am not spec pedantic, just to emphasize that natively drivers expects to have the RSS hash on the packet descriptor. 

As for the rest - I think you spread the two different approach correctly.

[1]
https://docs.microsoft.com/en-us/windows-hardware/drivers/network/introduction-to-receive-side-scaling


> 
> > You set a flow rule w/ mark -> you get full flow mark behavior You set
> > checksum -> you get full csum behavior.
> >
> >> I think more applications use checksum offloads than RSS hash, but it
> >> is still required to enable it. It looks like no single DPDK example
> >> uses RSS hash. So, I guess it not widely used by applications as well.
> > Well there is at least one called ovs-dpdk, that use the RSS result as the key
> to access the EMC.
> > I know of few more, not upstream, ones.
> >
> >> Anyway these 2 patches for flow action and RSS hash make all Rx
> >> offloads consistent - if you need something, enable it.
> > But the user enabled it -
> > It enabled RSS by setting ETH_MQ_RX_RSS, why does it need to enable
> another flag?
> 
> Answered above. If you need distribution it does not mean that you need
> RSS hash information. There are really many examples when you don't really
> need it.
> 
> > Same for flow mark.
> >
> >> And the question is not to save few cycles in the PMD receive path.
> >> It makes is possible to not deliver both from NIC to host.
> >> 8 bytes (4 RSS hash and 4 flow mark) are more than 10% for the
> >> smallest packets.
> > There is always the line between how much tight control we want to
> provide to user (to save cycles/ to save PCI BW) and how much it will be
> simple for the user to work on top.
> > My opinion is that we need to have some basics.
> 
> Many thanks, your arguments make sense. I vote for consistency and more
> fine grained control which allows more optimizations and allow to squeeze
> more performance from HW and SW. So, my line is a bit lower.  I don't think
> that these two patches make user control over-complicated.
> 
> >>>>> Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
> >>>> Reviewed-by: Andrew Rybchenko <arybchenko@solarflare.com>
> >>>>
> >>>> with above and one note below fixed.
> >>>>
> >>>>> ---
> >>>>>     doc/guides/nics/features.rst   | 2 ++
> >>>>>     lib/librte_ethdev/rte_ethdev.h | 1 +
> >>>>>     2 files changed, 3 insertions(+)
> >>>>>
> >>>>> diff --git a/doc/guides/nics/features.rst
> >>>>> b/doc/guides/nics/features.rst index d4d55f721..f79b69b38 100644
> >>>>> --- a/doc/guides/nics/features.rst
> >>>>> +++ b/doc/guides/nics/features.rst
> >>>>> @@ -274,6 +274,7 @@ Supports RSS hashing on RX.
> >>>>>
> >>>>>     * **[uses]     user config**: ``dev_conf.rxmode.mq_mode`` =
> >>>> ``ETH_MQ_RX_RSS_FLAG``.
> >>>>>     * **[uses]     user config**: ``dev_conf.rx_adv_conf.rss_conf``.
> >>>>> +* **[uses]     rte_eth_rxconf,rte_eth_rxmode**:
> >>>> ``offloads:DEV_RX_OFFLOAD_RSS_HASH``.
> >>>>>     * **[provides] rte_eth_dev_info**: ``flow_type_rss_offloads``.
> >>>>>     * **[provides] mbuf**: ``mbuf.ol_flags:PKT_RX_RSS_HASH``,
> >> ``mbuf.rss``.
> >>>>> @@ -286,6 +287,7 @@ Inner RSS
> >>>>>     Supports RX RSS hashing on Inner headers.
> >>>>>
> >>>>>     * **[uses]    rte_flow_action_rss**: ``level``.
> >>>>> +* **[uses]    rte_eth_rxconf,rte_eth_rxmode**:
> >>>> ``offloads:DEV_RX_OFFLOAD_RSS_HASH``.
> >>>>>     * **[provides] mbuf**: ``mbuf.ol_flags:PKT_RX_RSS_HASH``,
> >> ``mbuf.rss``.
> >>>>>
> >>>>> diff --git a/lib/librte_ethdev/rte_ethdev.h
> >>>>> b/lib/librte_ethdev/rte_ethdev.h index f97f0a6e5..889486a11 100644
> >>>>> --- a/lib/librte_ethdev/rte_ethdev.h
> >>>>> +++ b/lib/librte_ethdev/rte_ethdev.h
> >>>>> @@ -1013,6 +1013,7 @@ struct rte_eth_conf {
> >>>>>     #define DEV_RX_OFFLOAD_KEEP_CRC		0x00010000
> >>>>>     #define DEV_RX_OFFLOAD_SCTP_CKSUM	0x00020000
> >>>>>     #define DEV_RX_OFFLOAD_OUTER_UDP_CKSUM  0x00040000
> >>>>> +#define DEV_RX_OFFLOAD_RSS_HASH		0x00080000
> >>>> Should be added to rte_rx_offload_names in
> >>>> lib/librte_ethdev/rte_ethdev.c.


  reply index

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-16  5:55 [dpdk-dev] [PATCH 0/7] ethdev: add new Rx offload flags pbhagavatula
2019-08-16  5:55 ` [dpdk-dev] [PATCH 1/7] ethdev: add set ptype function pbhagavatula
2019-08-16  8:22   ` Andrew Rybchenko
2019-08-17 16:27     ` [dpdk-dev] [EXT] " Pavan Nikhilesh Bhagavatula
2019-08-16  5:55 ` [dpdk-dev] [PATCH 2/7] ethdev: add mbuf RSS update as a offload pbhagavatula
2019-08-16  7:48   ` Andrew Rybchenko
2019-08-17 11:47     ` Pavan Nikhilesh Bhagavatula
2019-08-18  4:52     ` Shahaf Shuler
2019-08-18  5:38       ` Andrew Rybchenko
2019-08-18  6:18         ` Shahaf Shuler
2019-08-18  7:00           ` Andrew Rybchenko
2019-08-18 12:11             ` Shahaf Shuler [this message]
2019-08-16  5:55 ` [dpdk-dev] [PATCH 3/7] ethdev: add flow action type update as an offload pbhagavatula
2019-08-16  8:05   ` Andrew Rybchenko
2019-08-17 14:23     ` [dpdk-dev] [EXT] " Pavan Nikhilesh Bhagavatula
2019-08-18  9:46       ` Andrew Rybchenko
2019-08-18  4:59     ` [dpdk-dev] " Shahaf Shuler
2019-08-18  5:57       ` Andrew Rybchenko
2019-08-18  6:20         ` Shahaf Shuler
2019-08-18  7:08           ` Andrew Rybchenko
2019-08-16  5:55 ` [dpdk-dev] [PATCH 4/7] net: update Rx RSS hash offload capabilities pbhagavatula
2019-08-16  7:49   ` Andrew Rybchenko
2019-08-17 12:26     ` Pavan Nikhilesh Bhagavatula
2019-08-16  5:55 ` [dpdk-dev] [PATCH 5/7] net: update Rx flow action " pbhagavatula
2019-08-16  7:50   ` Andrew Rybchenko
2019-08-16  5:55 ` [dpdk-dev] [PATCH 6/7] net: add ptype set default functionality pbhagavatula
2019-08-16  8:30   ` Andrew Rybchenko
2019-08-17 17:24     ` Pavan Nikhilesh Bhagavatula
2019-08-16  5:55 ` [dpdk-dev] [PATCH 7/7] examples/eventdev_pipeline: add new Rx RSS hash offload pbhagavatula
2019-08-16  6:01   ` Jerin Jacob Kollanukkaran
2019-08-16  6:02 ` [dpdk-dev] [PATCH 0/7] ethdev: add new Rx offload flags Jerin Jacob Kollanukkaran

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=AM0PR0502MB37950E69478E1472E6E70DF6C3A90@AM0PR0502MB3795.eurprd05.prod.outlook.com \
    --to=shahafs@mellanox.com \
    --cc=arybchenko@solarflare.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=jerinj@marvell.com \
    --cc=john.mcnamara@intel.com \
    --cc=marko.kovacevic@intel.com \
    --cc=pbhagavatula@marvell.com \
    --cc=thomas@monjalon.net \
    /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-dev Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/dpdk-dev/0 dpdk-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 dpdk-dev dpdk-dev/ https://lore.kernel.org/dpdk-dev \
		dev@dpdk.org dpdk-dev@archiver.kernel.org
	public-inbox-index dpdk-dev


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.dpdk.dev


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