[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAM_iQpV=f4DoONwLqbT0=Xo6c+ZWte-V=gjJJYAXPjGREa7cwA@mail.gmail.com>
Date: Sun, 28 Jan 2018 18:33:28 -0800
From: Cong Wang <xiyou.wangcong@...il.com>
To: "Michael S. Tsirkin" <mst@...hat.com>
Cc: Jason Wang <jasowang@...hat.com>,
Linux Kernel Network Developers <netdev@...r.kernel.org>,
John Fastabend <john.fastabend@...il.com>
Subject: Re: [Patch net-next v3 3/3] net_sched: implement ->change_tx_queue_len()
for pfifo_fast
On Fri, Jan 26, 2018 at 6:10 AM, Michael S. Tsirkin <mst@...hat.com> wrote:
>
> This part?
Yes, dev_deactivate() as you quote.
>
> + bool up = dev->flags & IFF_UP;
> + unsigned int i;
> + int ret = 0;
> +
> + if (up)
> + dev_deactivate(dev);
> +
> + for (i = 0; i < dev->num_tx_queues; i++) {
> + ret = qdisc_change_tx_queue_len(dev, &dev->_tx[i]);
> +
> + /* TODO: revert changes on a partial failure */
> + if (ret)
> + break;
> + }
> +
> + if (up)
> + dev_activate(dev);
>
>
> I wonder whether it really is safe to read dev->flags like that
> without any locks.
I really to hate to point it out again we have RTNL here. You
missed my previous response to John. ;)
Please read v1 and v2 when you response to v3.
Powered by blists - more mailing lists