From: "Danilewicz, MarcinX" <marcinx.danilewicz@intel.com>
To: "Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>,
"Singh, Jasvinder" <jasvinder.singh@intel.com>
Cc: "Ajmera, Megha" <megha.ajmera@intel.com>,
"Thakur, Sham Singh" <sham.singh.thakur@intel.com>,
"Mcnamara, John" <john.mcnamara@intel.com>,
"Devlin, Michelle" <michelle.devlin@intel.com>,
"Zegota, AnnaX" <annax.zegota@intel.com>
Subject: RE: [PATCH v4] sched: enable traffic class oversubscription conditionally
Date: Fri, 27 May 2022 00:09:45 +0000 [thread overview]
Message-ID: <PH0PR11MB5784BCE957AEA4F979FAE0358FD89@PH0PR11MB5784.namprd11.prod.outlook.com> (raw)
In-Reply-To: <PH0PR11MB578494CADF4DD4B7EAC9A03D8FD69@PH0PR11MB5784.namprd11.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 15229 bytes --]
Hi all,
Going trough all notes on http://patches.dpdk.org/project/dpdk/patch/20220427092357.491720-1-marcinx.danilewicz@intel.com/ please find my answers inline here.
First of all please take my apologies, for not checking url as above on regular basis. I was awaiting for mails with me on CC along to comments.
So lets go in to comments:
I don't see any note on the changes made in this version with respect to previous versions. Can you include them in future version? Also, I had some comments on the first version of this patch, I don't see any response.
@Marcin: hopefully all required changes are in new v5 patch
> int
> rte_sched_port_dequeue(struct rte_sched_port *port, struct rte_mbuf **pkts,
> uint32_t n_pkts);
>
> +/**
> + * Hierarchical scheduler subport TC OV enable/disable config.
The name of the feature should be fully stated here: traffic class oversubscription, not the abbreviation, please change.
@Marcin: please check v5 patch
> + * Note that this function is safe to use at runtime
> + * to enable/disable TC OV for subport.
We should actually forbit this rather than encourage it. Calling this function several times does not make sense, and it can create limitations that can come back and byte us in the future, whenever we might need to extend this code, for no reason.
Please actually replace with: "This function should be called at the time of subport initialization."
@Marcin: please check v5 patch
> + *
> + * @param port
> + * Handle to port scheduler instance
> + * @param subport_id
> + * Subport ID
> + * @param tc_ov_enable
> + * Boolean flag to enable/disable TC OV
> + * @return
> + * 0 upon success, error code otherwise
> + */
> +__rte_experimental
> +int
> +rte_sched_subport_tc_ov_config(struct rte_sched_port *port, uint32_t
> subport_id, bool tc_ov_enable);
> +
> #ifdef __cplusplus
> }
> #endif
> diff --git a/lib/sched/version.map b/lib/sched/version.map
> index d22c07fc9f..c6e994d8df 100644
> --- a/lib/sched/version.map
> +++ b/lib/sched/version.map
> @@ -34,4 +34,7 @@ EXPERIMENTAL {
> # added in 21.11
> rte_pie_rt_data_init;
> rte_pie_config_init;
> +
> + # added in 22.03
This is not in 22.03, it will hopefully be in 22.07.
> + rte_sched_subport_tc_ov_config;
> };
> --
> 2.25.1
> > subport->profile;
> >
> > grinder_prefetch_tc_queue_arrays(subport, pos);
> > - grinder_credits_update(port, subport, pos);
> > +
> > + if (unlikely(subport->is_tc_ov_enabled))
>
> Please remove the "unlikely" from here, don't put any likely/unlikely here at all.
@Marcin: as also noted below, I agree and all ours are removed.
> >
> > +/**
> > + * Hierarchical scheduler subport TC OV enable/disable config.
>
> The name of the feature should be fully stated here: traffic class
> oversubscription, not the abbreviation, please change.
>
>
@Marcin: please check changes
> > + * Note that this function is safe to use at runtime
> > + * to enable/disable TC OV for subport.
>
> We should actually forbit this rather than encourage it. Calling this function
> several times does not make sense, and it can create limitations that can come
> back and byte us in the future, whenever we might need to extend this code, for
> no reason.
>
> Please actually replace with: "This function should be called at the time of
> subport initialization."
@Marcin: please check changes
> > @@ -34,4 +34,7 @@ EXPERIMENTAL {
> > # added in 21.11
> > rte_pie_rt_data_init;
> > rte_pie_config_init;
> > +
> > + # added in 22.03
>
> This is not in 22.03, it will hopefully be in 22.07.
>
@Marcin: Well, nice spot!
> > Also the name of the feature should not be abbreviated in the patch title.
> >
> > I suggest you rework the title to:
> > [PATCH] sched: enable traffic class oversubscription conditionally
> >
@Marcin: already done
> > >
> > > Added new API to enable or disable TC over subscription for best
> > > effort traffic class at subport level.
> > > Added changes after review and increased throughput.
> > >
> > > By default TC OV is disabled.
> >
> > It should be the other way around, the TC_OV should be enabled by default.
> The
> > TC oversubscription is a more natural way to use this library, we usually want
> to
> > disable this feature just for better performance in case this functionality is
> not
> > needed. Please initialize the tc_ov flag accordingly.
> >
>
> In original code, this feature has always been disabled as it impacts
> performance.
> So, in my opinion we should keep it disabled by default and let user enable it
> when required.
>
In the original code, yes, it had to be explicitly enabled through a build-time flag. This was not the best option, and this is precisely what we are trying to fix with this patch.
But on the other hand all the users of these library that I know use it with the TC oversubscription turned on. Functionality is more important for them than performance. Hence my vote now is to enable it by default; those users that prefer performance over functionality can easily turn this feature off with no issues.
@Marcin: OK
> > > uint8_t memory[0] __rte_cache_aligned;
> > > +
> > > + /* TC oversubscription activation */
> > > + int is_tc_ov_enabled;
> >
> > How about we simplify the name of this variable to: tc_ov_enabled ?
@Marcin: agree 😊
> > > + s = port->subports[subport_id];
> > > + s->is_tc_ov_enabled = tc_ov_enable ? 1 : 0;
> > > +
> > > + if (s->is_tc_ov_enabled) {
> > > + /* TC oversubscription */
> > > + s->tc_ov_wm_min = port->mtu;
> > > + s->tc_ov_period_id = 0;
> > > + s->tc_ov = 0;
> > > + s->tc_ov_n = 0;
> > > + s->tc_ov_rate = 0;
> > > +
> > > + profile = port->subport_profiles + s->profile;
> > > + s->tc_ov_wm_max = rte_sched_time_ms_to_bytes(profile-
> > > >tc_period,
> > > + s->pipe_tc_be_rate_max);
> > > + s->tc_ov_wm = s->tc_ov_wm_max;
> > > + }
> > > + return 0;
> > > +}
> >
> > This function should not exist, please remove it and keep the initial code that
> > computes the tc_ov related variable regardless of whether tc_ov is enabled
> or
> > not.
> >
> > All the tc_ov related variables have the tc_ov particle in their name, so there
> is
> > no clash. This is initialization code, so no performance overhead. Let's keep
> the
> > code unmodified and compute both the tc_ov and the non-tc_ov varables at
> > initialization, regardless of whether the feature is enabled or not.
> >
> > This comment is applicable to all the initialization code, please adjust all the
> init
> > code accordingly. There should be no diff showing in the patch for any of the
> init
> > code!
> >
> > For this file "rte_sched.c", your patch should contain just two additional run-
> > time functions, i.e. the non-tc-ov version of functions
> grinder_credits_update()
> > and grindler_credits_check(), and the small code required to test when to use
> > the tc-ov vs. the non-tc_ov version, makes sense?
@Marcin: Yes, except setting tc ov enabled initially. Right?
> > > s->n_pipe_profiles = params->n_pipe_profiles;
> > > s->n_max_pipe_profiles = params->n_max_pipe_profiles;
> > >
> > > + /* TC over-subscription is disabled by default */
> > > + s->is_tc_ov_enabled = 0;
> > > +
> >
> > By default, this feature should be enabled:
> > s->is_tc_ov_enabled = 1;
> >
@Marcin: as below and here, ok feature is going to be enabled
> > >
> > > - if (!grinder_credits_check(port, subport, pos))
> > > - return 0;
> > > + switch (subport->is_tc_ov_enabled) {
> > > + case 1:
> > > + if (!grinder_credits_check_with_tc_ov(port, subport, pos))
> > > + return 0;
> > > + break;
> > > + case 0:
> > > + if (!grinder_credits_check(port, subport, pos))
> > > + return 0;
> > > + break;
> > > + }
> >
> > There should be no switch statement here, please replace with an if
> statement. I
> > suggest the following:
> >
> > int status;
> >
> > status = subport->tc_ov_enabled ? grinder_credits_check_with_tc_ov(port,
> > subport, pos) : grinder_credits_check(port, subport, pos); if (!status)
> > return 0;
> >
@Marcin: I disagree on that. Performance is decreased by that. Well any other thing than switch-case statement used there.
With code above I get:
-------+------------+------------+
| received | dropped |
-------+------------+------------+
RX | 5390751 | 0 |
QOS+TX | 5390784 | 0 | pps: 5390784
-------+------------+------------+
With switch case:
pps: 6733376
With TC oversubscription disabled or enabled, to my surprise. What to do with this now? I will be sending v5 patch with switch-case as of now ….
> > > /* Advance port time */
> > > port->time += pkt_len;
> > > @@ -2770,7 +2891,11 @@ grinder_handle(struct rte_sched_port *port,
> > > subport->profile;
> > >
> > > grinder_prefetch_tc_queue_arrays(subport, pos);
> > > - grinder_credits_update(port, subport, pos);
> > > +
> > > + if (unlikely(subport->is_tc_ov_enabled))
> >
> > Please remove the "unlikely" from here, don't put any likely/unlikely here at
> all.
@Marcin: Done. I didn’t not like “unlikely” from a first saw there.
> > > @@ -579,6 +579,24 @@ rte_sched_port_enqueue(struct rte_sched_port
> > > *port, struct rte_mbuf **pkts, uint int
> > > rte_sched_port_dequeue(struct rte_sched_port *port, struct rte_mbuf
> > > **pkts, uint32_t n_pkts);
> > >
> > > +/**
> > > + * Hierarchical scheduler subport TC OV enable/disable config.
> >
> > The name of the feature should be fully stated here: traffic class
> > oversubscription, not the abbreviation, please change.
@Marcin: done
> > > + * Note that this function is safe to use at runtime
> > > + * to enable/disable TC OV for subport.
> >
> > We should actually forbit this rather than encourage it. Calling this function
> > several times does not make sense, and it can create limitations that can
> come
> > back and byte us in the future, whenever we might need to extend this code,
> for no reason.
> >
> > Please actually replace with: "This function should be called at the time of
> > subport initialization."
> >
@Marcin: done
> > > + # added in 22.03
> >
> > This is not in 22.03, it will hopefully be in 22.07.
> >
@Marcin: done
> Yes, I agree this would be the ideal way to drive this change, but the problem is that modifying the existing subport parameter structure would represent an API change. This would require a deprecation notice, and the patch would be blocked until 22.11 release. Are you willing to wait until 22.11? If not, then adding the configuration function for this flag is the next best thing.
Are we making any plans for that?
No, definitely not.
> > Also the name of the feature should not be abbreviated in the patch title.
> > In original code, this feature has always been disabled as it impacts
>> performance.
> > So, in my opinion we should keep it disabled by default and let user enable it
> > when required.
> >
> In the original code, yes, it had to be explicitly enabled through a build-time flag. This was not the best option, and this is precisely what we are trying to fix with this patch.
> But on the other hand all the users of these library that I know use it with the TC oversubscription turned on. Functionality is more important for them than performance. Hence my vote now is to enable it by default; those users that prefer performance over functionality can easily turn this feature off with no issues.
@Marcin: OK, so we enable it by default.
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
Stephen HemmingerMay 24, 2022, 2:52 p.m. UTC | #6
On Tue, 24 May 2022 13:33:31 +0000
Marcin Danilewicz <marcinx.danilewicz@intel.com<mailto:marcinx.danilewicz@intel.com>> wrote:
> /Marcin
> --------------------------------------------------------------
> Intel Research and Development Ireland Limited
> Registered in Ireland
> Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
> Registered Number: 308263
>
>
> This e-mail and any attachments may contain confidential material for the sole
> use of the intended recipient(s). Any review or distribution by others is
> strictly prohibited. If you are not the intended recipient, please contact the
> sender and delete all copies.
>
Please talk to your management/lawyers. This kind of auto-footer violates the
required discussion properties of open source.
@Marcin: I send answer in separate thread. But in a short, that message was added by mail server or something in between. Patch using git email engine was sent as per usual.
BR,
/Marcin
--------------------------------------------------------------
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
[-- Attachment #2: Type: text/html, Size: 41767 bytes --]
next prev parent reply other threads:[~2022-05-27 0:10 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-07 14:51 [dpdk][PATCH 1/2] sched: enable/disable TC OV at runtime Marcin Danilewicz
2022-04-07 14:51 ` [dpdk][PATCH 2/2] sched: fix to manage " Marcin Danilewicz
2022-04-14 9:53 ` Thomas Monjalon
2022-04-27 9:23 ` [PATCH v3] sched: enable/disable " Marcin Danilewicz
2022-04-27 15:48 ` Singh, Jasvinder
2022-05-09 20:05 ` Dumitrescu, Cristian
2022-05-10 6:40 ` Ajmera, Megha
2022-05-10 9:09 ` Dumitrescu, Cristian
2022-05-24 13:33 ` Marcin Danilewicz
2022-05-24 14:52 ` Stephen Hemminger
2022-05-26 23:12 ` Danilewicz, MarcinX
2022-05-24 13:38 ` [PATCH v4] sched: enable traffic class oversubscription conditionally Marcin Danilewicz
2022-05-24 13:43 ` Marcin Danilewicz
2022-05-24 14:30 ` Dumitrescu, Cristian
2022-05-25 14:18 ` Danilewicz, MarcinX
2022-05-27 0:09 ` Danilewicz, MarcinX [this message]
2022-05-27 0:09 ` [PATCH v5] " Marcin Danilewicz
2022-05-30 8:45 ` [PATCH v6] " Marcin Danilewicz
2022-05-30 10:35 ` Dumitrescu, Cristian
2022-05-30 11:59 ` Danilewicz, MarcinX
2022-05-30 10:54 ` Dumitrescu, Cristian
2022-05-30 12:02 ` Danilewicz, MarcinX
2022-05-30 10:58 ` Dumitrescu, Cristian
2022-05-30 12:04 ` Danilewicz, MarcinX
2022-05-30 11:55 ` [PATCH v7] " Marcin Danilewicz
2022-05-30 12:14 ` Dumitrescu, Cristian
2022-05-30 13:34 ` Danilewicz, MarcinX
2022-05-30 13:55 ` Dumitrescu, Cristian
2022-05-30 14:05 ` Danilewicz, MarcinX
2022-05-30 13:38 ` [PATCH v8] " Marcin Danilewicz
2022-05-30 18:47 ` [PATCH v9] " Marcin Danilewicz
2022-05-30 21:13 ` Dumitrescu, Cristian
2022-05-31 9:49 ` [PATCH v10] " Marcin Danilewicz
2022-05-31 13:09 ` Dumitrescu, Cristian
2022-05-31 16:42 ` Thomas Monjalon
2022-05-31 18:45 ` Danilewicz, MarcinX
2022-04-08 12:50 ` [dpdk][PATCH 1/2] sched: enable/disable TC OV at runtime Singh, Jasvinder
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=PH0PR11MB5784BCE957AEA4F979FAE0358FD89@PH0PR11MB5784.namprd11.prod.outlook.com \
--to=marcinx.danilewicz@intel.com \
--cc=annax.zegota@intel.com \
--cc=cristian.dumitrescu@intel.com \
--cc=dev@dpdk.org \
--cc=jasvinder.singh@intel.com \
--cc=john.mcnamara@intel.com \
--cc=megha.ajmera@intel.com \
--cc=michelle.devlin@intel.com \
--cc=sham.singh.thakur@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
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).