[dpdk-dev] [PATCH v3 1/3] net/mlx5: use Netlink to add/remove MAC addresses

Nélio Laranjeiro nelio.laranjeiro at 6wind.com
Thu Mar 22 11:28:30 CET 2018


On Thu, Mar 22, 2018 at 09:45:16AM +0000, Shahaf Shuler wrote:
> Thursday, March 22, 2018 11:05 AM, Nélio Laranjeiro:
> > > What if the DPDK process is terminated ungracefully? I think the MAC
> > > table will remain with all the MACs which were added.
> > > The next run of the process may have un-expected results.
> > >
> > > Should we flush the neighbor mac table also on probe to make sure only
> > > the VF mac exists?
> > 
> > In such situation the sysadmin should make the clean up, the DPDK
> > application cannot consider it is the only one using the device as it is not the
> > case, Linux still owns the device.
> > We have no guarantee the admin did not use another MAC address for a
> > service outside of the DPDK application (even if in such case he should
> > disable this feature to fully control what happens on the neighbor mac table).
> 
> There should be only one owner for the VF mac tables - either the DPDK or the Linux.
>
> If the DPDK is the owner, it should do the cleanup. If the sysadmin
> wants to be the owner then it should set the proper flag when running
> dpdk or alternatively not set the VF in trusted mode. 

It is a little more complex than what you think, according to the Linux
configuration the tables will have entries already present or not e.g.
broadcast v6 is present only if the Linux supports the v6 (by
compilation or configuration).

For such reason the PMD cannot consider it owns the bridge tables when
acting as a VF, otherwise it needs to trigger any Linux configuration
modification and enable the according functionalities.

To answer this:
> There should be only one owner for the VF mac tables - either the DPDK or the Linux.

That's right, DPDK application or Linux should own the device, the PMD
is none of the two.  It is just a driver.

Thanks,

-- 
Nélio Laranjeiro
6WIND


More information about the dev mailing list