From: Jakub Kicinski <kuba@kernel.org>
To: Nick Child <nnac123@linux.ibm.com>
Cc: netdev@vger.kernel.org, nick.child@ibm.com, dave.taht@gmail.com
Subject: Re: [RFC PATCH net-next 0/1] ibmveth: Implement BQL
Date: Tue, 25 Oct 2022 11:41:48 -0700 [thread overview]
Message-ID: <20221025114148.1bcf194b@kernel.org> (raw)
In-Reply-To: <20221024213828.320219-1-nnac123@linux.ibm.com>
On Mon, 24 Oct 2022 16:38:27 -0500 Nick Child wrote:
> Labeled as RFC because I am unsure if adding Byte Queue Limits (BQL) is
> positively effecting the ibmveth driver. BQL is common among network
> drivers so I would like to incorporate it into the virtual ethernet
> driver, ibmveth. But I am having trouble measuring its effects.
>
> From my understanding (and please correct me if I am wrong), BQL will
> use the number of packets sent to the NIC to approximate the minimum
> number of packets to enqueue to a netdev_queue without starving the NIC.
> As a result, bufferbloat in the networking queues are minimized which
> may allow for smaller latencies.
>
> After performing various netperf tests under differing loads and
> priorities, I do not see any performance effect when comparing the
> driver with and without BQL. The ibmveth driver is a virtual driver
> which has an abstracted view of the NIC so I am comfortable without
> seeing any performance deltas. That being said, I would like to know if
> BQL is actually being enforced in some way. In other words, I would
> like to observe a change in the number of queued bytes during BQL
> implementations. Does anyone know of a mechanism to measure the length
> of a netdev_queue?
>
> I tried creating a BPF script[1] to track the bytes in a netdev_queue
> but again am not seeing any difference with and without BQL. I do not
> believe anything is wrong with BQL (it is more likely that my tracing
> is bad) but I would like to have some evidence of BQL having a
> positive effect on the device. Any recommendations or advice would be
> greatly appreciated.
What qdisc are you using and what "netperf tests" are you running?
next prev parent reply other threads:[~2022-10-25 18:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-24 21:38 [RFC PATCH net-next 0/1] ibmveth: Implement BQL Nick Child
2022-10-24 21:38 ` [RFC PATCH net-next 1/1] " Nick Child
2022-10-25 18:41 ` Jakub Kicinski [this message]
2022-10-25 20:03 ` [RFC PATCH net-next 0/1] " Nick Child
2022-10-25 22:10 ` Jakub Kicinski
2022-10-26 0:08 ` Dave Taht
2022-10-26 21:10 ` Nick Child
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=20221025114148.1bcf194b@kernel.org \
--to=kuba@kernel.org \
--cc=dave.taht@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=nick.child@ibm.com \
--cc=nnac123@linux.ibm.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.