From: Shahaf Shuler <shahafs@mellanox.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
Thomas Monjalon <thomas@monjalon.net>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH 4/4] ethdev: add helpers to move to the new offloads API
Date: Wed, 6 Sep 2017 06:01:43 +0000 [thread overview]
Message-ID: <VI1PR05MB314976BC67191ABB49283EA9C3970@VI1PR05MB3149.eurprd05.prod.outlook.com> (raw)
In-Reply-To: <2601191342CEEE43887BDE71AB9772584F246B5D@irsmsx105.ger.corp.intel.com>
Tuesday, September 5, 2017 6:31 PM, Ananyev, Konstantin:
> >
> > > > > > > In fact, right now it is possible to query/change these 3
> > > > > > > vlan offload flags on the fly (after dev_start) on port
> > > > > > > basis by
> > > rte_eth_dev_(get|set)_vlan_offload API.
> >
> > Regarding this API from ethdev.
> >
> > So this seems like a hack on ethdev. Currently there are 2 ways for user to
> set Rx vlan offloads.
> > One is through dev_configure which require the ports to be stopped. The
> other is this API which can set even if the port is started.
>
> Yes there is an ability to enable/disable VLAN offloads without
> stop/reconfigure the device.
> Though I wouldn't call it 'a hack'.
> From my perspective - it is a useful feature.
> Same as it is possible in some cases to change MTU without stopping device,
> etc.
>
> >
> > We should have only one place were application set offloads and this
> > is currently on dev_configure,
>
> Hmm, if HW supports the ability to do things at runtime why we have to stop
> users from using that ability?
>
> > And future to be on rx_queue_setup.
> >
> > I would say that this API should be removed as well.
> > Application which wants to change those offloads will stop the ports and
> reconfigure the PMD.
>
> I wouldn't agree - see above.
>
> > Am quite sure that there are PMDs which need to re-create the Rxq
> > based on vlan offloads changing and this cannot be done while the traffic
> flows.
>
> That's an optional API - PMD can choose does it want to support it or not.
>
> >
> >
> > > > > > > So, I think at least these 3 flags need to be remained on a port
> basis.
> > > > > >
> > > > > > I don't understand how it helps to be able to configure the
> > > > > > same thing in 2 places.
> > > > >
> > > > > Because some offloads are per device, another - per queue.
> > > > > Configuring on a device basis would allow most users to conjure
> > > > > all queues in the same manner by default.
> > > > > Those users who would need more fine-grained setup (per queue)
> > > > > will be able to overwrite it by rx_queue_setup().
> > > >
> > > > Those users can set the same config for all queues.
> > > > >
> > > > > > I think you are just describing a limitation of these HW: some
> > > > > > offloads must be the same for all queues.
> > > > >
> > > > > As I said above - on some devices some offloads might also
> > > > > affect queues that belong to VFs (to another ports in DPDK words).
> > > > > You might never invoke rx_queue_setup() for these queues per
> > > > > your
> > > app.
> > > > > But you still want to enable this offload on that device.
> > >
> > > I am ok with having per-port and per-queue offload configuration.
> > > My concern is that after that patch only per-queue offload
> > > configuration will remain.
> > > I think we need both.
> >
> > So looks like we all agree PMDs should report as part of the
> rte_eth_dev_info_get which offloads are per port and which are per queue.
>
> Yep.
>
> >
> > Regarding the offloads configuration by application I see 2 options:
> > 1. have an API to set offloads per port as part of device configure
> > and API to set offloads per queue as part of queue setup 2. set all
> > offloads as part of queue configuration (per port offloads will be set equally
> for all queues). In case of a mixed configuration for port offloads PMD will
> return error.
> > Such error can be reported on device start. The PMD will traverse the
> queues and check for conflicts.
> >
> > I will focus on the cons, since both achieve the goal:
> >
> > Cons of #1:
> > - Two places to configure offloads.
>
> Yes, but why is that a problem?
If we could make the offloads API to set the offloads in a single place it would be much cleaner and less error prune.
There is one flow which change the offloads configuration.
Later on when we want to change/expend it will be much simpler, as all modification can happen in a single place only.
>
> > - Like Thomas mentioned - what about offloads per device? This direction
> leads to more places to configure the offloads.
>
> As you said above - there would be 2 places: per port and per queue.
> Could you explain - what other places you are talking about?
In fact, the vlan filter offload for PF is a *per device* offload and not per port. Since the corresponding VF has it just by the fact the PF set it on dev_configure.
So to be exact, such offload should be set on a new offload section called "per device offloads".
Currently you compromise on setting it in the *per port* offload section, with proper explanation on the VF limitation in intel.
>
> >
> > Cons of #2:
> > - Late error reporting - on device start and not on queue setup.
>
> Consider scenario when PF has a corresponding VFs (PF is controlled by
> DPDK) Right now (at least with Intel HW) it is possible to:
>
> struct rte_eth_conf dev_conf;
> dev_conf. rxmode.hw_vlan_filter = 1;
> ...
> rte_eth_dev_configure(pf_port_id, 0, 0, &dev_conf);
> rte_eth_dev_start(pf_port_id);
>
> In that scenario I don't have any RX/TX queues configured.
> Though I still able to enable vlan filter, and it would work correctly for VFs.
> Same for other per-port offloads.
For the PF - enabling vlan filtering without any queues means nothing. The PF can receive no traffic, what different does it makes the vlan filtering is set?
For the VF - I assume it will have queues, therefore for it vlan filtering has a meaning. However as I said above, the VF has the vlan filter because in intel this is per-device offload, so this is not a good example.
Which other per-port offloads you refer to?
I don't understand what is the meaning of setting per-port offloads without opening any Tx/Rx queues.
> With approach #2 it simply wouldn't work.
Yes for vlan filtering it will not work on intel, and this may be enough to move to suggestion #1.
Thomas?
>
> So my preference is still #1.
>
> Konstantin
>
> >
> > I would go with #2.
> >
> > > Konstantin
> > >
> > > >
> > > > You are advocating for per-port configuration API because some
> > > > settings must be the same on all the ports of your hardware?
> > > > So there is a big trouble. You don't need per-port settings, but
> > > > per-hw-device settings.
> > > > Or would you accept more fine-grained per-port settings?
> > > > If yes, you can accept even finer grained per-queues settings.
> > > > >
> > > > > > It does not prevent from configuring them in the per-queue setup.
> > > > > >
> > > > > > > In fact, why can't we have both per port and per queue RX
> offload:
> > > > > > > - dev_configure() will accept RX_OFFLOAD_* flags and apply
> > > > > > > them on
> > > a port basis.
> > > > > > > - rx_queue_setup() will also accept RX_OFFLOAD_* flags and
> > > > > > > apply
> > > them on a queue basis.
> > > > > > > - if particular RX_OFFLOAD flag for that device couldn't be
> > > > > > > setup on a
> > > queue basis -
> > > > > > > rx_queue_setup() will return an error.
> > > > > >
> > > > > > The queue setup can work while the value is the same for every
> > > queues.
> > > > >
> > > > > Ok, and how people would know that?
> > > > > That for device N offload X has to be the same for all queues,
> > > > > and for device M offload X can be differs for different queues.
> > > >
> > > > We can know the hardware limitations by filling this information
> > > > at PMD init.
> > > >
> > > > > Again, if we don't allow to enable/disable offloads for
> > > > > particular queue, why to bother with updating rx_queue_setup() API
> at all?
> > > >
> > > > I do not understand this question.
> > > >
> > > > > > > - rte_eth_rxq_info can be extended to provide information
> > > > > > > which
> > > RX_OFFLOADs
> > > > > > > can be configured on a per queue basis.
> > > > > >
> > > > > > Yes the PMD should advertise its limitations like being forced
> > > > > > to apply the same configuration to all its queues.
> > > > >
> > > > > Didn't get your last sentence.
> > > >
> > > > I agree that the hardware limitations must be written in an ethdev
> > > structure.
next prev parent reply other threads:[~2017-09-06 6:01 UTC|newest]
Thread overview: 134+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-04 7:12 [dpdk-dev] [PATCH 0/4] ethdev " Shahaf Shuler
2017-09-04 7:12 ` [dpdk-dev] [PATCH 1/4] ethdev: rename Rx and Tx configuration structs Shahaf Shuler
2017-09-04 12:06 ` Ananyev, Konstantin
2017-09-04 12:45 ` Shahaf Shuler
2017-09-04 7:12 ` [dpdk-dev] [PATCH 2/4] ethdev: introduce Rx queue offloads API Shahaf Shuler
2017-09-04 7:12 ` [dpdk-dev] [PATCH 3/4] ethdev: introduce Tx " Shahaf Shuler
2017-09-04 7:12 ` [dpdk-dev] [PATCH 4/4] ethdev: add helpers to move to the new " Shahaf Shuler
2017-09-04 12:13 ` Ananyev, Konstantin
2017-09-04 13:25 ` Ananyev, Konstantin
2017-09-04 13:53 ` Thomas Monjalon
2017-09-04 14:18 ` Ananyev, Konstantin
2017-09-05 7:48 ` Thomas Monjalon
2017-09-05 8:09 ` Ananyev, Konstantin
2017-09-05 10:51 ` Shahaf Shuler
2017-09-05 13:50 ` Thomas Monjalon
2017-09-05 15:31 ` Ananyev, Konstantin
2017-09-06 6:01 ` Shahaf Shuler [this message]
2017-09-06 9:33 ` Ananyev, Konstantin
2017-09-13 9:27 ` Thomas Monjalon
2017-09-13 11:16 ` Shahaf Shuler
2017-09-13 12:41 ` Thomas Monjalon
2017-09-13 12:56 ` Ananyev, Konstantin
2017-09-13 13:20 ` Thomas Monjalon
2017-09-13 21:42 ` Ananyev, Konstantin
2017-09-14 8:02 ` Thomas Monjalon
2017-09-18 10:31 ` Bruce Richardson
2017-09-18 10:57 ` Ananyev, Konstantin
2017-09-18 11:04 ` Bruce Richardson
2017-09-18 11:27 ` Thomas Monjalon
2017-09-18 11:04 ` Bruce Richardson
2017-09-18 11:11 ` Ananyev, Konstantin
2017-09-18 11:32 ` Thomas Monjalon
2017-09-18 11:37 ` Bruce Richardson
2017-09-18 14:27 ` Shahaf Shuler
2017-09-18 14:42 ` Thomas Monjalon
2017-09-18 14:44 ` Bruce Richardson
2017-09-18 18:18 ` Shahaf Shuler
2017-09-18 21:08 ` Thomas Monjalon
2017-09-19 7:33 ` Shahaf Shuler
2017-09-19 7:56 ` Thomas Monjalon
2017-09-13 12:56 ` Shahaf Shuler
2017-09-04 14:02 ` Shahaf Shuler
2017-09-04 15:55 ` Ananyev, Konstantin
2017-09-10 12:07 ` [dpdk-dev] [PATCH v2 0/2] ethdev " Shahaf Shuler
2017-09-10 12:07 ` [dpdk-dev] [PATCH v2 1/2] ethdev: introduce Rx queue " Shahaf Shuler
2017-09-10 12:07 ` [dpdk-dev] [PATCH v2 2/2] ethdev: introduce Tx " Shahaf Shuler
2017-09-10 17:48 ` Stephen Hemminger
2017-09-11 5:52 ` Shahaf Shuler
2017-09-11 6:21 ` Jerin Jacob
2017-09-11 7:56 ` Shahaf Shuler
2017-09-11 8:06 ` Jerin Jacob
2017-09-11 8:46 ` Shahaf Shuler
2017-09-11 9:05 ` Jerin Jacob
2017-09-11 11:02 ` Ananyev, Konstantin
2017-09-12 4:01 ` Jerin Jacob
2017-09-12 5:25 ` Shahaf Shuler
2017-09-12 5:51 ` Jerin Jacob
2017-09-12 6:35 ` Shahaf Shuler
2017-09-12 6:46 ` Andrew Rybchenko
2017-09-12 7:17 ` Jerin Jacob
2017-09-12 8:03 ` Shahaf Shuler
2017-09-12 10:27 ` Andrew Rybchenko
2017-09-12 14:26 ` Ananyev, Konstantin
2017-09-12 14:36 ` Jerin Jacob
2017-09-12 14:43 ` Andrew Rybchenko
2017-09-12 6:43 ` Andrew Rybchenko
2017-09-12 6:59 ` Shahaf Shuler
2017-09-11 8:03 ` Andrew Rybchenko
2017-09-11 12:27 ` Shahaf Shuler
2017-09-11 13:10 ` Andrew Rybchenko
2017-09-13 6:37 ` [dpdk-dev] [PATCH v3 0/2] ethdev new " Shahaf Shuler
2017-09-13 6:37 ` [dpdk-dev] [PATCH v3 1/2] ethdev: introduce Rx queue " Shahaf Shuler
2017-09-13 8:13 ` Andrew Rybchenko
2017-09-13 12:49 ` Shahaf Shuler
2017-09-13 8:49 ` Andrew Rybchenko
2017-09-13 9:13 ` Andrew Rybchenko
2017-09-13 12:33 ` Shahaf Shuler
2017-09-13 12:34 ` Andrew Rybchenko
2017-09-13 6:37 ` [dpdk-dev] [PATCH v3 2/2] ethdev: introduce Tx " Shahaf Shuler
2017-09-13 8:40 ` Andrew Rybchenko
2017-09-13 12:51 ` Shahaf Shuler
2017-09-13 9:10 ` [dpdk-dev] [PATCH v3 0/2] ethdev new " Andrew Rybchenko
2017-09-17 6:54 ` [dpdk-dev] [PATCH v4 0/3] " Shahaf Shuler
2017-09-17 6:54 ` [dpdk-dev] [PATCH v4 1/3] ethdev: introduce Rx queue " Shahaf Shuler
2017-09-17 6:54 ` [dpdk-dev] [PATCH v4 2/3] ethdev: introduce Tx " Shahaf Shuler
2017-09-18 7:50 ` Andrew Rybchenko
2017-09-17 6:54 ` [dpdk-dev] [PATCH v4 3/3] doc: add details on ethdev " Shahaf Shuler
2017-09-18 7:51 ` Andrew Rybchenko
2017-09-18 13:40 ` Mcnamara, John
2017-09-18 7:51 ` [dpdk-dev] [PATCH v4 0/3] ethdev new " Andrew Rybchenko
2017-09-28 18:54 ` [dpdk-dev] [PATCH v5 " Shahaf Shuler
2017-09-28 18:54 ` [dpdk-dev] [PATCH v5 1/3] ethdev: introduce Rx queue " Shahaf Shuler
2017-10-03 0:32 ` Ferruh Yigit
2017-10-03 6:25 ` Shahaf Shuler
2017-10-03 19:46 ` Ferruh Yigit
2017-09-28 18:54 ` [dpdk-dev] [PATCH v5 2/3] ethdev: introduce Tx " Shahaf Shuler
2017-10-03 19:50 ` Ferruh Yigit
2017-10-04 8:06 ` Shahaf Shuler
2017-09-28 18:54 ` [dpdk-dev] [PATCH v5 3/3] doc: add details on ethdev " Shahaf Shuler
2017-10-04 8:17 ` [dpdk-dev] [PATCH v6 0/4] ethdev new " Shahaf Shuler
2017-10-04 8:17 ` [dpdk-dev] [PATCH v6 1/4] ethdev: introduce Rx queue " Shahaf Shuler
2017-10-04 8:17 ` [dpdk-dev] [PATCH v6 2/4] ethdev: introduce Tx " Shahaf Shuler
2017-10-04 8:18 ` [dpdk-dev] [PATCH v6 3/4] ethdev: add mbuf fast free Tx offload Shahaf Shuler
2017-10-04 8:18 ` [dpdk-dev] [PATCH v6 4/4] doc: add details on ethdev offloads API Shahaf Shuler
2017-10-04 13:46 ` Mcnamara, John
2018-03-15 1:58 ` Patil, Harish
2018-03-15 6:05 ` Shahaf Shuler
2018-03-16 15:51 ` [dpdk-dev] [PATCH] doc: update new ethdev offload API description Ferruh Yigit
2018-03-17 0:16 ` Patil, Harish
2018-03-18 5:52 ` Shahaf Shuler
2018-03-21 9:47 ` Andrew Rybchenko
2018-03-21 10:54 ` Ferruh Yigit
2018-03-21 11:08 ` Andrew Rybchenko
2018-03-21 11:10 ` Shahaf Shuler
2018-03-21 11:19 ` Andrew Rybchenko
2018-03-21 11:23 ` Shahaf Shuler
2018-03-21 11:37 ` Andrew Rybchenko
2018-03-21 11:40 ` Shahaf Shuler
2018-03-21 12:52 ` Ferruh Yigit
2018-03-21 13:06 ` Shahaf Shuler
2018-03-21 13:11 ` Ananyev, Konstantin
2018-03-21 12:03 ` Ananyev, Konstantin
2018-03-21 12:29 ` Shahaf Shuler
2018-03-21 12:34 ` Andrew Rybchenko
2018-03-21 12:37 ` Ananyev, Konstantin
2018-03-21 14:08 ` Thomas Monjalon
2018-03-21 14:28 ` Ferruh Yigit
2018-03-21 14:40 ` Thomas Monjalon
2018-03-21 15:26 ` Bruce Richardson
2018-03-21 15:29 ` Shahaf Shuler
2018-03-21 15:44 ` Bruce Richardson
2018-05-08 12:33 ` Ferruh Yigit
2017-10-04 16:12 ` [dpdk-dev] [PATCH v6 0/4] ethdev new offloads API Ananyev, Konstantin
2017-10-05 0:55 ` 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=VI1PR05MB314976BC67191ABB49283EA9C3970@VI1PR05MB3149.eurprd05.prod.outlook.com \
--to=shahafs@mellanox.com \
--cc=dev@dpdk.org \
--cc=konstantin.ananyev@intel.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
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).