From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: Jason Wang <jasowang@redhat.com>
Cc: f.fainelli@gmail.com,
Network Development <netdev@vger.kernel.org>,
David Miller <davem@davemloft.net>,
caleb.raitto@gmail.com, "Michael S. Tsirkin" <mst@redhat.com>,
"Jon Olson (Google Drive)" <jonolson@google.com>,
Willem de Bruijn <willemb@google.com>
Subject: Re: [PATCH net-next] virtio_net: ethtool tx napi configuration
Date: Thu, 13 Sep 2018 10:58:15 -0400 [thread overview]
Message-ID: <CAF=yD-L1h=EWF8DgAZsUCbb58tZhh5vDkPTRdwaZ895==OxTxA@mail.gmail.com> (raw)
In-Reply-To: <4a3d69be-8651-e36d-bc14-5a3f1f23d155@redhat.com>
On Thu, Sep 13, 2018 at 5:02 AM Jason Wang <jasowang@redhat.com> wrote:
>
>
>
> On 2018年09月13日 07:27, Willem de Bruijn wrote:
> > On Wed, Sep 12, 2018 at 3:11 PM Willem de Bruijn
> > <willemdebruijn.kernel@gmail.com> wrote:
> >> On Wed, Sep 12, 2018 at 2:16 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
> >>>
> >>>
> >>> On 9/12/2018 11:07 AM, Willem de Bruijn wrote:
> >>>> On Wed, Sep 12, 2018 at 1:42 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
> >>>>>
> >>>>>
> >>>>> On 9/9/2018 3:44 PM, Willem de Bruijn wrote:
> >>>>>> From: Willem de Bruijn <willemb@google.com>
> >>>>>>
> >>>>>> Implement ethtool .set_coalesce (-C) and .get_coalesce (-c) handlers.
> >>>>>> Interrupt moderation is currently not supported, so these accept and
> >>>>>> display the default settings of 0 usec and 1 frame.
> >>>>>>
> >>>>>> Toggle tx napi through a bit in tx-frames. So as to not interfere
> >>>>>> with possible future interrupt moderation, use bit 10, well outside
> >>>>>> the reasonable range of real interrupt moderation values.
> >>>>>>
> >>>>>> Changes are not atomic. The tx IRQ, napi BH and transmit path must
> >>>>>> be quiesced when switching modes. Only allow changing this setting
> >>>>>> when the device is down.
> >>>>> Humm, would not a private ethtool flag to switch TX NAPI on/off be more
> >>>>> appropriate rather than use the coalescing configuration API here?
> >>>> What do you mean by private ethtool flag? A new field in ethtool
> >>>> --features (-k)?
> >>> I meant using ethtool_drvinfo::n_priv_flags, ETH_SS_PRIV_FLAGS and then
> >>> ETHTOOL_GFPFLAGS and ETHTOOL_SPFLAGS to control the toggling of that
> >>> private flag. mlx5 has a number of privates flags for instance.
> >> Interesting, thanks! I was not at all aware of those ethtool flags.
> >> Am having a look. It definitely looks promising.
> > Okay, I made that change. That is indeed much cleaner, thanks.
> > Let me send the patch, initially as RFC.
> >
> > I've observed one issue where if we toggle the flag before bringing
> > up the device, it hits a kernel BUG at include/linux/netdevice.h:515
> >
> > BUG_ON(!test_bit(NAPI_STATE_SCHED, &n->state));
>
> This reminds me that we need to check netif_running() before trying to
> enable and disable tx napi in ethtool_set_coalesce().
The first iteration of my patch checked IFF_UP and effectively
only allowed the change when not running. What do you mean
by need to check?
And to respond to the other follow-up notes at once:
> Consider we may have interrupt moderation in the future, I tend to use
> set_coalesce. Otherwise we may need two steps to enable moderation:
>
> - tx-napi on
> - set_coalesce
FWIW, I don't care strongly whether we do this through coalesce or priv_flags.
>> + if (!napi_weight)
>> + virtqueue_enable_cb(vi->sq[i].vq);
>
> I don't get why we need to disable enable cb here.
To avoid entering no-napi mode with too few descriptors to
make progress and no way to get out of that state. This is a
pretty crude attempt at handling that, admittedly.
next prev parent reply other threads:[~2018-09-13 20:08 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-09 22:44 [PATCH net-next] virtio_net: ethtool tx napi configuration Willem de Bruijn
2018-09-10 6:01 ` Jason Wang
2018-09-10 13:35 ` Willem de Bruijn
2018-09-11 0:45 ` Jason Wang
2018-09-11 1:14 ` Willem de Bruijn
2018-09-12 3:35 ` Jason Wang
2018-09-12 13:43 ` Willem de Bruijn
2018-09-13 9:05 ` Jason Wang
2018-09-12 17:42 ` Florian Fainelli
2018-09-12 18:07 ` Willem de Bruijn
2018-09-12 18:16 ` Florian Fainelli
2018-09-12 19:11 ` Willem de Bruijn
2018-09-12 23:27 ` Willem de Bruijn
2018-09-13 9:02 ` Jason Wang
2018-09-13 14:58 ` Willem de Bruijn [this message]
2018-09-14 3:27 ` Jason Wang
2018-09-14 3:40 ` Willem de Bruijn
2018-09-14 3:53 ` Jason Wang
2018-09-14 4:46 ` Willem de Bruijn
2018-09-14 8:08 ` Jason Wang
2018-09-27 8:50 ` Jason Wang
2018-09-27 13:53 ` Willem de Bruijn
2018-09-27 23:39 ` Jason Wang
2018-09-13 9:04 ` 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='CAF=yD-L1h=EWF8DgAZsUCbb58tZhh5vDkPTRdwaZ895==OxTxA@mail.gmail.com' \
--to=willemdebruijn.kernel@gmail.com \
--cc=caleb.raitto@gmail.com \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=jasowang@redhat.com \
--cc=jonolson@google.com \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=willemb@google.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.