From: Vinicius Costa Gomes <vinicius.gomes@intel.com>
To: Zh-yuan Ye <ye.zh-yuan@socionext.com>, netdev@vger.kernel.org
Cc: okamoto.satoru@socionext.com, kojima.masahisa@socionext.com,
Zh-yuan Ye <ye.zh-yuan@socionext.com>
Subject: Re: [PATCH net] net: cbs: Fix software cbs to consider packet
Date: Thu, 19 Mar 2020 10:10:15 -0700 [thread overview]
Message-ID: <87lfnwfeyw.fsf@intel.com> (raw)
In-Reply-To: <20200319075659.3126-1-ye.zh-yuan@socionext.com>
Hi,
Zh-yuan Ye <ye.zh-yuan@socionext.com> writes:
> Currently the software CBS does not consider the packet sending time
> when depleting the credits. It caused the throughput to be
> Idleslope[kbps] * (Port transmit rate[kbps] / |Sendslope[kbps]|) where
> Idleslope * (Port transmit rate / (Idleslope + |Sendslope|)) is expected.
> In order to fix the issue above, this patch takes the time when the
> packet sending completes into account by moving the anchor time variable
> "last" ahead to the send completion time upon transmission and adding
> wait when the next dequeue request comes before the send completion time
> of the previous packet.
>
> Signed-off-by: Zh-yuan Ye <ye.zh-yuan@socionext.com>
> ---
You raise good points here.
What I am thinking is that perhaps we could replace 'q->last' by this
'send_completed' idea, then we could have a more precise software mode
when we take into account when we dequeue the "last byte" of the packet.
> net/sched/sch_cbs.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/net/sched/sch_cbs.c b/net/sched/sch_cbs.c
> index b2905b03a432..a78b8a750bd9 100644
> --- a/net/sched/sch_cbs.c
> +++ b/net/sched/sch_cbs.c
> @@ -71,6 +71,7 @@ struct cbs_sched_data {
> int queue;
> atomic64_t port_rate; /* in bytes/s */
> s64 last; /* timestamp in ns */
> + s64 send_completed; /* timestamp in ns */
So, my suggestion is to replace 'last' by the 'send_completed' concept.
And as an optional suggestion, I think that changing the 'last' name by
something like 'last_byte' with a comment saying "estimate of the
transmission of the last byte of the packet, in ns" could be worth
thinking about.
Do you see any problems?
Cheers,
--
Vinicius
next prev parent reply other threads:[~2020-03-19 17:10 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-19 7:56 [PATCH net] net: cbs: Fix software cbs to consider packet Zh-yuan Ye
2020-03-19 17:10 ` Vinicius Costa Gomes [this message]
2020-03-23 0:28 ` ye.zh-yuan
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=87lfnwfeyw.fsf@intel.com \
--to=vinicius.gomes@intel.com \
--cc=kojima.masahisa@socionext.com \
--cc=netdev@vger.kernel.org \
--cc=okamoto.satoru@socionext.com \
--cc=ye.zh-yuan@socionext.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.