From: "Michael S. Tsirkin" <mst@redhat.com>
To: Jiri Pirko <jiri@resnulli.us>
Cc: netdev@vger.kernel.org, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, jasowang@redhat.com,
xuanzhuo@linux.alibaba.com, virtualization@lists.linux.dev,
ast@kernel.org, daniel@iogearbox.net, hawk@kernel.org,
john.fastabend@gmail.com, dave.taht@gmail.com,
kerneljasonxing@gmail.com, hengqi@linux.alibaba.com
Subject: Re: [PATCH net-next v3] virtio_net: add support for Byte Queue Limits
Date: Wed, 19 Jun 2024 03:26:22 -0400 [thread overview]
Message-ID: <20240619014938-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <ZnJwbKmy923yye0t@nanopsycho.orion>
On Wed, Jun 19, 2024 at 07:45:16AM +0200, Jiri Pirko wrote:
> Tue, Jun 18, 2024 at 08:18:12PM CEST, mst@redhat.com wrote:
> >This looks like a sensible way to do this.
> >Yet something to improve:
> >
> >
> >On Tue, Jun 18, 2024 at 04:44:56PM +0200, Jiri Pirko wrote:
> >> From: Jiri Pirko <jiri@nvidia.com>
> >>
>
> [...]
>
>
> >> +static void __free_old_xmit(struct send_queue *sq, struct netdev_queue *txq,
> >> + bool in_napi, struct virtnet_sq_free_stats *stats)
> >> {
> >> unsigned int len;
> >> void *ptr;
> >>
> >> while ((ptr = virtqueue_get_buf(sq->vq, &len)) != NULL) {
> >> - ++stats->packets;
> >> -
> >> if (!is_xdp_frame(ptr)) {
> >> - struct sk_buff *skb = ptr;
> >> + struct sk_buff *skb = ptr_to_skb(ptr);
> >>
> >> pr_debug("Sent skb %p\n", skb);
> >>
> >> - stats->bytes += skb->len;
> >> + if (is_orphan_skb(ptr)) {
> >> + stats->packets++;
> >> + stats->bytes += skb->len;
> >> + } else {
> >> + stats->napi_packets++;
> >> + stats->napi_bytes += skb->len;
> >> + }
> >> napi_consume_skb(skb, in_napi);
> >> } else {
> >> struct xdp_frame *frame = ptr_to_xdp(ptr);
> >>
> >> + stats->packets++;
> >> stats->bytes += xdp_get_frame_len(frame);
> >> xdp_return_frame(frame);
> >> }
> >> }
> >> + netdev_tx_completed_queue(txq, stats->napi_packets, stats->napi_bytes);
> >
> >Are you sure it's right? You are completing larger and larger
> >number of bytes and packets each time.
>
> Not sure I get you. __free_old_xmit() is always called with stats
> zeroed. So this is just sum-up of one queue completion run.
> I don't see how this could become "larger and larger number" as you
> describe.
Oh. Right of course. Worth a comment maybe? Just to make sure
we remember not to call __free_old_xmit twice in a row
without reinitializing stats.
Or move the initialization into __free_old_xmit to make it
self-contained ..
WDYT?
>
> >
> >For example as won't this eventually trigger this inside dql_completed:
> >
> > BUG_ON(count > num_queued - dql->num_completed);
>
> Nope, I don't see how we can hit it. Do not complete anything else
> in addition to what was started in xmit(). Am I missing something?
>
>
> >
> >?
> >
> >
> >If I am right the perf testing has to be redone with this fixed ...
> >
> >
> >> }
> >>
>
> [...]
next prev parent reply other threads:[~2024-06-19 7:26 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20240812145727eucas1p22360b410908e41aeafa7c9f09d52ca14@eucas1p2.samsung.com>
2024-06-18 14:44 ` [PATCH net-next v3] virtio_net: add support for Byte Queue Limits Jiri Pirko
2024-06-18 18:18 ` Michael S. Tsirkin
2024-06-19 5:45 ` Jiri Pirko
2024-06-19 7:26 ` Michael S. Tsirkin [this message]
2024-06-19 8:05 ` Jiri Pirko
2024-06-19 8:17 ` Michael S. Tsirkin
2024-06-19 8:23 ` Michael S. Tsirkin
2024-06-19 10:09 ` Jiri Pirko
2024-06-20 7:43 ` Michael S. Tsirkin
2024-06-20 0:40 ` patchwork-bot+netdevbpf
2024-08-12 14:57 ` Marek Szyprowski
2024-08-12 16:47 ` Jiri Pirko
2024-08-12 16:55 ` Marek Szyprowski
2024-08-14 7:49 ` Jiri Pirko
2024-08-14 8:17 ` Jiri Pirko
2024-08-14 9:43 ` Michael S. Tsirkin
2024-08-14 12:16 ` Jiri Pirko
2024-08-14 9:17 ` Marek Szyprowski
2024-08-14 12:16 ` Jiri Pirko
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=20240619014938-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=ast@kernel.org \
--cc=daniel@iogearbox.net \
--cc=dave.taht@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hawk@kernel.org \
--cc=hengqi@linux.alibaba.com \
--cc=jasowang@redhat.com \
--cc=jiri@resnulli.us \
--cc=john.fastabend@gmail.com \
--cc=kerneljasonxing@gmail.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=virtualization@lists.linux.dev \
--cc=xuanzhuo@linux.alibaba.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.