On 1/18/2018 4:35 PM, Matan Azrad wrote: > Add ownership mechanism to DPDK Ethernet devices to avoid multiple management > of a device by different DPDK entities. > The port ownership mechanism is a good point to redefine the synchronization > rules in ethdev: > > 1. The port allocation and port release synchronization will be managed > by ethdev. > 2. The port usage synchronization will be managed by the port owner. > 3. The port ownership synchronization will be managed by ethdev. > 4. DPDK entity which want to use a port safely must take ownership > before. > > > V2: > Synchronize ethdev port creation. > Synchronize port ownership mechanism. > Rename owner remove API to rte_eth_dev_owner_unset. > Remove "ethdev: free a port by a dedicated API" patch - passed to another > series. > Add "ethdev: fix port data reset timing" patch. > Cahnge owner get API to return int value and to pass copy of the owner > structure. > Adjust testpmd to the improved owner get API. > Adjust documentations. > > V3: > Change RTE_ETH_FOREACH_DEV iterator to skip owned ports(Gaetan suggestion). > Prevent goto in set\unset APIs by adding internal API - this also adds reuse > of code(Konstantin suggestion). > Group all the shared processes variables in one struct to allow easy > allocation of it(Konstantin suggestion). > Take owner name truncation as warning and not as error(Konstantin suggestion). > Mark the new APIs as EXPERIMENTAL. > Rebase on top of master_net_mlx. > Rebase on top of "[PATCH v6 0/6] Fail-safe\ethdev: fix removal handling lack" > series. > Rebase on top of "[PATCH v5 0/8] Introduce virtual driver for Hyper-V/Azure > platforms" series. > Add "ethdev: fix used portid allocation" patch suggested by Konstantin. > > > > Matan Azrad (7): > ethdev: fix port data reset timing > ethdev: fix used portid allocation > ethdev: add port ownership > ethdev: synchronize port allocation > net/failsafe: free an eth port by a dedicated API > net/failsafe: use ownership mechanism to own ports > app/testpmd: adjust ethdev port ownership
Hi Thomas, Technically this should be in scope of next-net, but this become a long discussion and I am not able to follow it indeed, would you mind dealing this in master tree?
