From: Shahaf Shuler <shahafs@mellanox.com>
To: Ferruh Yigit <ferruh.yigit@intel.com>,
Mordechay Haimovsky <motih@mellanox.com>,
"pascal.mazon@6wind.com" <pascal.mazon@6wind.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH V5 2/2] net/tap: use new Rx offloads API
Date: Mon, 12 Mar 2018 17:58:30 +0000 [thread overview]
Message-ID: <DB7PR05MB4426AED925119EE307CFECAEC3D30@DB7PR05MB4426.eurprd05.prod.outlook.com> (raw)
In-Reply-To: <8973efd1-ec77-2e51-0516-634ab878bb1c@intel.com>
Monday, March 12, 2018 7:00 PM, Ferruh Yigit:
> There are some devices supports queue level offloads and there are some
> devices supports port level offloads.
>
> Values queue offload = 0x0 and port offload = 0x1000, for the device that
> support queue level offloads may mean disabling all offloads for that specific
> queue and this is valid value. For the device that support port level offloads
> this is an error.
device which don't support port level offloads should not be configured with port offloads.
Well implemented PMDs will fail the configuration with port offload = 0x1000.
>
> What about using "rx/tx_queue_offload_capa" field to help application to
> detect if device supports queue level or port level offloads?
Yes. this is their purpose.
>
> If device reports 0x0 "rx_queue_offload_capa", application will know device
> doesn't support queue level offloads and PMD just ignore all provided queue
> offloads.
>
> If device reports a "rx_queue_offload_capa" other than 0x0, app will know
> that device _supports_ queue offloads and will set offloads according and
> PMD will verify and apply queue specific offloads according.
>
> For above tap specific case, is tap PMD supports queue specific offloads?
Am not sure. Moty?
>
> And there should be some restrictions on offloading values:
> 1- requested port offloads should be subset of supported port offloads
> 2- supported queue offloads should be subset of supported port offloads
> 3- requested queue offloads should be subset of supported queue offloads
This is correct.
>
> And since these information is part of dev_info, these can be managed in the
> ethdev layer, instead of checked in each PMD (as done in tap).
>
>
> According above, would you mind walk-trough how application can set
> offloads:
>
> A) New application that implements new offloading APIs:
> - Get dev_info
> - Configure Rx/Tx offloads based on rx_offload_capa / tx_offload_capa
> - If rx_queue_offload_capa / tx_queue_offload_capa is other than 0, setup
> RxQ / TxQ offloads based on these values.
> - If rx_queue_offload_capa / tx_queue_offload_capa is 0, queue level
> offlaods are not supported by this device, ignore offloads during RxQ / TxQ
> setup.
With the current API it is not correct. queue offloads should be at least the port offloads. If the application wants to enable more queue specific offloads it can as long as those are supported.
The following pseudo code demonstrate above:
Dev_configure(port, port_offloads)
Rx_queue_offloads = port_offloads
If (rx_queue_offload_capa != 0)
Rx_queue_offloads |= rx_queue_offload_capa
>
> All look OK here.
>
>
> B) Old application with old offloading API
> - Get dev_info, which provides only rx_offload_capa, tx_offload_capa and
> txq_flags
> - set rte_eth_rxmode->bitfield_values ==> ethdev will convert them to port
> level Rx offloads.
> - port level offloads are empty!!
> - ethdev will set queue level Rx offloads to be same as port level Rx offloads.
> - ethdev will set txq_flags values for Tx offloads to queue level Tx offloads.
>
> Things should work well for PMDs with old offloading API.
>
> For the PMDs that support new offloading API, port level Tx offload values
> are missing and Queue level and Port level Tx offloads mismatch. Am I
> missing something here, if not how can we solve this issue in PMDs?
Those PMDs (new PMD for old application) can use the ETH_TXQ_FLAGS_IGNORE which must be set for application which uses the new API..
see snipped code from mlx5 PMD:
[1]
/*
* Don't verify port offloads for application which
* use the old API.
*/
if (!!(conf->txq_flags & ETH_TXQ_FLAGS_IGNORE) &&
!priv_is_tx_queue_offloads_allowed(priv, conf->offloads)) {
ret = ENOTSUP;
ERROR("%p: Tx queue offloads 0x%" PRIx64 " don't match port "
"offloads 0x%" PRIx64 " or supported offloads 0x%" PRIx64,
(void *)dev, conf->offloads,
dev->data->dev_conf.txmode.offloads,
mlx5_priv_get_tx_port_offloads(priv));
goto out;
}
>
>
> >
> >>
> >> I believe other way around makes sense, to be able to set queue offload
> param, device should announce that offloading as supported. Queue is
> subset of the device, why you ignore device offload param to set queue
> offload param?
> >>
> >> What makes sense to me:
> >> "queue offload" is subset of "device offload" is subset of "device
> supported offload"
> >
> >
> >
> >
> > [1]
> >
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdpd
> k
> >
> .org%2Fdoc%2Fguides%2Fprog_guide%2Fpoll_mode_drv.html&data=02%7C
> 01%7Cs
> >
> hahafs%40mellanox.com%7C2fc3763767f041846bdd08d5883aa76a%7Ca65297
> 1c7d2
> >
> e4d9ba6a4d149256f461b%7C0%7C0%7C636564707857610335&sdata=Uavzne
> YAsXf2M
> > SdJWSp6i1fvRmCRyx6pWwLuzUCqOLA%3D&reserved=0
> >
> >
> >>
> >> <...>
next prev parent reply other threads:[~2018-03-12 17:58 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-04 19:18 [dpdk-dev] [PATCH V3 0/2] net/tap: convert to new ethdev " Moti Haimovsky
2018-01-04 19:18 ` [dpdk-dev] [PATCH V3 1/2] net/tap: convert to new Tx " Moti Haimovsky
2018-01-05 8:18 ` Pascal Mazon
2018-01-04 19:18 ` [dpdk-dev] [PATCH V3 2/2] net/tap: convert to new Rx " Moti Haimovsky
2018-01-05 8:26 ` Pascal Mazon
2018-01-10 16:20 ` [dpdk-dev] [PATCH V4 1/2] net/tap: convert to new Tx " Moti Haimovsky
2018-01-10 16:20 ` [dpdk-dev] [PATCH V4 2/2] net/tap: convert to new Rx " Moti Haimovsky
2018-01-10 16:42 ` Pascal Mazon
2018-01-17 14:04 ` [dpdk-dev] [PATCH V5 1/2] net/tap: use new Tx " Moti Haimovsky
2018-01-17 14:04 ` [dpdk-dev] [PATCH V5 2/2] net/tap: use new Rx " Moti Haimovsky
2018-03-02 21:44 ` Ferruh Yigit
2018-03-12 14:20 ` Shahaf Shuler
2018-03-12 16:59 ` Ferruh Yigit
2018-03-12 17:58 ` Shahaf Shuler [this message]
2018-03-12 19:05 ` Ferruh Yigit
2018-03-13 7:08 ` Shahaf Shuler
2018-03-13 11:56 ` Ferruh Yigit
2018-03-14 5:49 ` Shahaf Shuler
2018-03-14 22:40 ` Ferruh Yigit
2018-03-15 6:16 ` Shahaf Shuler
2018-03-15 14:34 ` Ferruh Yigit
2018-01-18 14:02 ` [dpdk-dev] [PATCH V5 1/2] net/tap: use new Tx " Pascal Mazon
2018-01-18 15:19 ` Ferruh Yigit
Reply instructions:
You may reply publicly 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=DB7PR05MB4426AED925119EE307CFECAEC3D30@DB7PR05MB4426.eurprd05.prod.outlook.com \
--to=shahafs@mellanox.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=motih@mellanox.com \
--cc=pascal.mazon@6wind.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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).