All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Michael Dalton <mwdalton@google.com>,
	netdev@vger.kernel.org,
	lf-virt <virtualization@lists.linux-foundation.org>,
	Eric Dumazet <edumazet@google.com>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH net-next v3 5/5] virtio-net: initial rx sysfs support, export mergeable rx buffer size
Date: Thu, 16 Jan 2014 20:50:51 +0200	[thread overview]
Message-ID: <20140116185051.GB29522@redhat.com> (raw)
In-Reply-To: <1389895481.31367.411.camel@edumazet-glaptop2.roam.corp.google.com>

On Thu, Jan 16, 2014 at 10:04:41AM -0800, Eric Dumazet wrote:
> On Thu, 2014-01-16 at 09:27 -0800, Michael Dalton wrote:
> > Sorry, just realized - I think disabling NAPI is necessary but not
> > sufficient. There is also the issue that refill_work() could be
> > scheduled. If refill_work() executes, it will re-enable NAPI. We'd need
> > to cancel the vi->refill delayed work to prevent this AFAICT, and also
> > ensure that no other function re-schedules vi->refill or re-enables NAPI
> > (virtnet_open/close, virtnet_set_queues, and virtnet_freeze/restore).
> > 
> > How is the following sequence of operations:
> > rtnl_lock();
> > cancel_delayed_work_sync(&vi->refill);
> > napi_disable(&rq->napi);
> > read rq->mrg_avg_pkt_len
> > virtnet_enable_napi();
> > rtnl_unlock();
> > 
> > Additionally, if we disable NAPI when reading this file, perhaps
> > the permissions should be changed to 400 so that an unprivileged
> > user cannot temporarily disable network RX processing by reading these
> > sysfs files. Does that sound reasonable?
> 
> I think all this complexity makes no sense to me.
> 
> Who cares of sysfs reading a value that might be updated ?
> This is purely a debugging utility.
> 
> As soon as you read the value, it might already have changed anyway.
> 
> Its a integer, just read it without special care.

That's fine too as far as I'm concerned.

> 
> atomic_read() has also same 'problem', and we do not care.
> 
> Make sure that a recompute (aka ewma_add()) does not store intermediate
> wrong values, by using ACCESS_ONCE(), and thats enough. No need for the
> seqcount overhead.
> 
> diff --git a/lib/average.c b/lib/average.c
> index 99a67e662b3c..044e0b7f28a8 100644
> --- a/lib/average.c
> +++ b/lib/average.c
> @@ -53,8 +53,10 @@ EXPORT_SYMBOL(ewma_init);
>   */
>  struct ewma *ewma_add(struct ewma *avg, unsigned long val)
>  {
> -	avg->internal = avg->internal  ?
> -		(((avg->internal << avg->weight) - avg->internal) +
> +	unsigned long internal = ACCESS_ONCE(avg->internal);
> +
> +	ACCESS_ONCE(avg->internal) = internal  ?
> +		(((internal << avg->weight) - internal) +
>  			(val << avg->factor)) >> avg->weight :
>  		(val << avg->factor);
>  	return avg;
> 

      reply	other threads:[~2014-01-16 18:50 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-16  9:38 [PATCH net-next v3 1/5] net: allow > 0 order atomic page alloc in skb_page_frag_refill Michael Dalton
2014-01-16  9:38 ` [PATCH net-next v3 2/5] virtio-net: use per-receive queue page frag alloc for mergeable bufs Michael Dalton
2014-01-16  9:38 ` [PATCH net-next v3 3/5] virtio-net: auto-tune mergeable rx buffer size for improved performance Michael Dalton
2014-01-16  9:38 ` [PATCH net-next v3 4/5] net-sysfs: add support for device-specific rx queue sysfs attributes Michael Dalton
2014-01-16 18:57   ` Ben Hutchings
2014-01-16 19:07     ` Michael Dalton
2014-01-16 19:42       ` Ben Hutchings
2014-01-16 19:51         ` Michael Dalton
2014-01-16 20:00           ` Eric Dumazet
2014-01-16  9:38 ` [PATCH net-next v3 5/5] virtio-net: initial rx sysfs support, export mergeable rx buffer size Michael Dalton
2014-01-16 11:53   ` Michael S. Tsirkin
2014-01-16 16:33     ` Michael Dalton
2014-01-16 17:27       ` Michael Dalton
2014-01-16 18:04         ` Eric Dumazet
2014-01-16 18:50           ` Michael S. Tsirkin [this message]

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=20140116185051.GB29522@redhat.com \
    --to=mst@redhat.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=eric.dumazet@gmail.com \
    --cc=mwdalton@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=virtualization@lists.linux-foundation.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.