Re: [dpdk-dev] [PATCH 0/2] net/virtio: support to turn on/off the traffic flow

["Yang, Zhiyong" <zhiyong.yang@intel.com>]

Hi，yuanhan:
	
> -----Original Message-----
> From: Yuanhan Liu [mailto:yuanhan.liu@linux.intel.com]
> Sent: Wednesday, April 19, 2017 10:03 AM
> To: Yang, Zhiyong <zhiyong.yang@intel.com>
> Cc: dev@dpdk.org; maxime.coquelin@redhat.com
> Subject: Re: [PATCH 0/2] net/virtio: support to turn on/off the traffic flow
> 
> On Mon, Apr 17, 2017 at 08:50:52AM +0000, Yang, Zhiyong wrote:
> > Hi, yuanhan:
> > 	Sorry for the delay reply due to my annual leave.
> >
> > > -----Original Message-----
> > > From: Yuanhan Liu [mailto:yuanhan.liu@linux.intel.com]
> > > Sent: Thursday, April 6, 2017 12:00 PM
> > > To: Yang, Zhiyong <zhiyong.yang@intel.com>
> > > Cc: dev@dpdk.org; maxime.coquelin@redhat.com
> > > Subject: Re: [PATCH 0/2] net/virtio: support to turn on/off the
> > > traffic flow
> > >
> > > On Fri, Mar 31, 2017 at 07:40:17PM +0800, Zhiyong Yang wrote:
> > > > Current dpdk code virtio_dev_stop only disables interrupt and
> > > > marks link down, When it is invoked, tx/rx traffic flows still
> > > > work. This is a strange
> > > behavior.
> > > > The patchset supports the switch of flow by calling virtio_dev_start/stop.
> > > >
> > > > The implementation refers to vhost pmd.
> > >
> > > That's a difference story. Vhost pmd uses 2 vars to track the
> > > status, whereas you are using only one here. So why not
> > > setting/clearing "started" at dev_start/stop, respectively?
> > > Then we can check "started" at Rx/Tx functions.
> >
> > Yes, I use only one var since I think vhost pmd using two is too complex and it
> is unnecessary.
> 
> No, it's needed. For vhost-user pmd, we can only do Rx when both below items
> are met:
> 
> - port is started
> - new_device() is invoked, aka, the device is connected
> 
> For that reason, two vars is used to track it.
> 

Got it. Thanks for your explanation.

> > I'm setting/clearing started at virtio_dev_start/stop,
> > update_queuing_status is added to avoid duplicate code.
> 
> It's not about duplicate code. While we could make the var per-device, you
> make it per-queue. That's complex and unnecessary.
> 

Agree with you.  The var per-device is good.  This can make code simplified.

> > I don't understand your question.
> >
> > >
> > > BTW, why does it have to be atomic?
> > >
> >
> > Consider again. It is not necessary to use atomic here. But It seems that it
> doesn't  have an negative effect.
> 
> Hmm... that's a good reason to keep it, just because it has no negative effect?
> Talking about the negative effect, badly, it really has. The atomic is more
> expensive.

Haha, you are right. 
I will rework it and send V2.

Thanks
Zhiyong
> 
> 	--yliu