From: "Michael S. Tsirkin" <mst@redhat.com>
To: Caleb Raitto <caleb.raitto@gmail.com>
Cc: jasowang@redhat.com, davem@davemloft.net, netdev@vger.kernel.org,
Caleb Raitto <caraitto@google.com>
Subject: Re: [PATCH net-next] virtio_net: force_napi_tx module param.
Date: Tue, 24 Jul 2018 13:42:49 +0300 [thread overview]
Message-ID: <20180724134138-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20180723231119.142904-1-caleb.raitto@gmail.com>
On Mon, Jul 23, 2018 at 04:11:19PM -0700, Caleb Raitto wrote:
> From: Caleb Raitto <caraitto@google.com>
>
> The driver disables tx napi if it's not certain that completions will
> be processed affine with tx service.
>
> Its heuristic doesn't account for some scenarios where it is, such as
> when the queue pair count matches the core but not hyperthread count.
>
> Allow userspace to override the heuristic. This is an alternative
> solution to that in the linked patch. That added more logic in the
> kernel for these cases, but the agreement was that this was better left
> to user control.
>
> Do not expand the existing napi_tx variable to a ternary value,
> because doing so can break user applications that expect
> boolean ('Y'/'N') instead of integer output. Add a new param instead.
>
> Link: https://patchwork.ozlabs.org/patch/725249/
> Acked-by: Willem de Bruijn <willemb@google.com>
> Acked-by: Jon Olson <jonolson@google.com>
> Signed-off-by: Caleb Raitto <caraitto@google.com>
Is there a reason the same rule should apply to all devices?
If not shouldn't this be an ethtool option?
> ---
> drivers/net/virtio_net.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 2ff08bc103a9..d9aca4e90d6b 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -39,10 +39,11 @@
> static int napi_weight = NAPI_POLL_WEIGHT;
> module_param(napi_weight, int, 0444);
>
> -static bool csum = true, gso = true, napi_tx;
> +static bool csum = true, gso = true, napi_tx, force_napi_tx;
> module_param(csum, bool, 0444);
> module_param(gso, bool, 0444);
> module_param(napi_tx, bool, 0644);
> +module_param(force_napi_tx, bool, 0644);
>
> /* FIXME: MTU in config. */
> #define GOOD_PACKET_LEN (ETH_HLEN + VLAN_HLEN + ETH_DATA_LEN)
> @@ -1201,7 +1202,7 @@ static void virtnet_napi_tx_enable(struct virtnet_info *vi,
> /* Tx napi touches cachelines on the cpu handling tx interrupts. Only
> * enable the feature if this is likely affine with the transmit path.
> */
> - if (!vi->affinity_hint_set) {
> + if (!vi->affinity_hint_set && !force_napi_tx) {
> napi->weight = 0;
> return;
> }
> @@ -2646,7 +2647,7 @@ static int virtnet_alloc_queues(struct virtnet_info *vi)
> netif_napi_add(vi->dev, &vi->rq[i].napi, virtnet_poll,
> napi_weight);
> netif_tx_napi_add(vi->dev, &vi->sq[i].napi, virtnet_poll_tx,
> - napi_tx ? napi_weight : 0);
> + (napi_tx || force_napi_tx) ? napi_weight : 0);
>
> sg_init_table(vi->rq[i].sg, ARRAY_SIZE(vi->rq[i].sg));
> ewma_pkt_len_init(&vi->rq[i].mrg_avg_pkt_len);
> --
> 2.18.0.233.g985f88cf7e-goog
next prev parent reply other threads:[~2018-07-24 11:48 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-23 23:11 [PATCH net-next] virtio_net: force_napi_tx module param Caleb Raitto
2018-07-24 0:53 ` Stephen Hemminger
2018-07-24 1:23 ` Willem de Bruijn
2018-07-24 10:42 ` Michael S. Tsirkin [this message]
2018-07-24 14:01 ` Willem de Bruijn
2018-07-24 18:38 ` Michael S. Tsirkin
2018-07-24 20:52 ` Willem de Bruijn
2018-07-24 22:23 ` Michael S. Tsirkin
2018-07-24 22:31 ` Willem de Bruijn
2018-07-24 22:46 ` Michael S. Tsirkin
2018-07-25 0:02 ` Willem de Bruijn
2018-07-25 0:17 ` Jon Olson
2018-07-30 6:06 ` Jason Wang
2018-08-01 22:27 ` Michael S. Tsirkin
2018-08-28 19:57 ` Willem de Bruijn
2018-08-29 7:56 ` Jason Wang
2018-08-29 13:01 ` Willem de Bruijn
2018-09-09 23:07 ` Willem de Bruijn
2018-09-10 5:59 ` Jason Wang
2018-07-29 16:00 ` David Miller
2018-07-29 20:33 ` Michael S. Tsirkin
2018-07-29 20:36 ` David Miller
2018-07-29 21:09 ` Willem de Bruijn
2018-07-29 21:32 ` Willem de Bruijn
2018-07-31 12:34 ` Michael S. Tsirkin
2018-08-01 15:46 ` Willem de Bruijn
2018-08-01 15:56 ` Willem de Bruijn
2018-08-01 22:25 ` Michael S. Tsirkin
2018-08-01 22:43 ` Willem de Bruijn
2018-08-01 22:48 ` Michael S. Tsirkin
2018-08-01 23:33 ` Willem de Bruijn
2018-07-30 19:51 ` Stephen Hemminger
2018-07-31 1:41 ` Jason Wang
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=20180724134138-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=caleb.raitto@gmail.com \
--cc=caraitto@google.com \
--cc=davem@davemloft.net \
--cc=jasowang@redhat.com \
--cc=netdev@vger.kernel.org \
/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.