Hi Stephen,
> -----Original Message----- > From: Stephen Hemminger [mailto:stephen at networkplumber.org] > Sent: Saturday, June 11, 2016 2:12 AM > To: Lu, Wenzhuo > Cc: dev at dpdk.org; Tao, Zhe > Subject: Re: [dpdk-dev] [PATCH 2/8] lib/librte_ether: defind RX/TX lock mode > > On Wed, 8 Jun 2016 07:34:43 +0000 > "Lu, Wenzhuo" <wenzhuo.lu at intel.com> wrote: > > > > > > > The fact that it requires lots more locking inside each device > > > driver implies to me this is not correct way to architect this. > > It's a good question. This patch set doesn't follow the regular assumption > > of > DPDK. > > But it's a requirement we've got from some customers. The users want the > driver does as much as it can. The best is the link state change is > transparent to > the users. > > The patch set tries to provide another choice if the users don't want to > > stop > their rx/tx to handle the reset event. > > Then bring those uses to the development world (on users mailing list) and > lets > start the discussion there. The requirements creeping in through the backdoor > also worries me. Got it. Then how about we only provide a reset API and let the APP to stop/start the rx/tx and call the API to reset the port? Thanks.