From: Neil Horman <nhorman@tuxdriver.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
Cc: Matan Azrad <matan@mellanox.com>,
Thomas Monjalon <thomas@monjalon.net>,
Gaetan Rivet <gaetan.rivet@6wind.com>,
"Wu, Jingjing" <jingjing.wu@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>,
"Richardson, Bruce" <bruce.richardson@intel.com>
Subject: Re: [dpdk-dev] [PATCH v2 2/6] ethdev: add port ownership
Date: Thu, 18 Jan 2018 11:27:44 -0500 [thread overview]
Message-ID: <20180118162744.GC1622@hmswarspite.think-freely.org> (raw)
In-Reply-To: <2601191342CEEE43887BDE71AB9772588627F0E9@irsmsx105.ger.corp.intel.com>
On Wed, Jan 17, 2018 at 05:01:10PM +0000, Ananyev, Konstantin wrote:
>
>
> > -----Original Message-----
> > From: Neil Horman [mailto:nhorman@tuxdriver.com]
> > Sent: Wednesday, January 17, 2018 2:00 PM
> > To: Matan Azrad <matan@mellanox.com>
> > Cc: Ananyev, Konstantin <konstantin.ananyev@intel.com>; Thomas Monjalon <thomas@monjalon.net>; Gaetan Rivet
> > <gaetan.rivet@6wind.com>; Wu, Jingjing <jingjing.wu@intel.com>; dev@dpdk.org; Richardson, Bruce <bruce.richardson@intel.com>
> > Subject: Re: [PATCH v2 2/6] ethdev: add port ownership
> >
> > On Wed, Jan 17, 2018 at 12:05:42PM +0000, Matan Azrad wrote:
> > >
> > > Hi Konstantin
> > > From: Ananyev, Konstantin, Sent: Wednesday, January 17, 2018 1:24 PM
> > > > Hi Matan,
> > > >
> > > > > Hi Konstantin
> > > > >
> > > > > From: Ananyev, Konstantin, Tuesday, January 16, 2018 9:11 PM
> > > > > > Hi Matan,
> > > > > >
> > > > > > >
> > > > > > > Hi Konstantin
> > > > > > > From: Ananyev, Konstantin, Monday, January 15, 2018 8:44 PM
> > > > > > > > Hi Matan,
> > > > > > > > > Hi Konstantin
> > > > > > > > > From: Ananyev, Konstantin, Monday, January 15, 2018 1:45 PM
> > > > > > > > > > Hi Matan,
> > > > > > > > > > > Hi Konstantin
> > > > > > > > > > > From: Ananyev, Konstantin, Friday, January 12, 2018 2:02
> > > > > > > > > > > AM
> > > > > > > > > > > > Hi Matan,
> > > > > > > > > > > > > Hi Konstantin
> > > > > > > > > > > > > From: Ananyev, Konstantin, Thursday, January 11, 2018
> > > > > > > > > > > > > 2:40 PM
> > > > > > > > > > > > > > Hi Matan,
> > > > > > > > > > > > > > > Hi Konstantin
> > > > > > > > > > > > > > > From: Ananyev, Konstantin, Wednesday, January 10,
> > > > > > > > > > > > > > > 2018
> > > > > > > > > > > > > > > 3:36 PM
> > > > > > > > > > > > > > > > Hi Matan,
> > > > > > > <snip>
> > > > > > > > > > > > > > > > It is good to see that now scanning/updating
> > > > > > > > > > > > > > > > rte_eth_dev_data[] is lock protected, but it
> > > > > > > > > > > > > > > > might be not very plausible to protect both
> > > > > > > > > > > > > > > > data[] and next_owner_id using the
> > > > > > > > > > same lock.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I guess you mean to the owner structure in
> > > > > > > > > > rte_eth_dev_data[port_id].
> > > > > > > > > > > > > > > The next_owner_id is read by ownership APIs(for
> > > > > > > > > > > > > > > owner validation), so it
> > > > > > > > > > > > > > makes sense to use the same lock.
> > > > > > > > > > > > > > > Actually, why not?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Well to me next_owner_id and rte_eth_dev_data[] are
> > > > > > > > > > > > > > not directly
> > > > > > > > > > > > related.
> > > > > > > > > > > > > > You may create new owner_id but it doesn't mean you
> > > > > > > > > > > > > > would update rte_eth_dev_data[] immediately.
> > > > > > > > > > > > > > And visa-versa - you might just want to update
> > > > > > > > > > > > > > rte_eth_dev_data[].name or .owner_id.
> > > > > > > > > > > > > > It is not very good coding practice to use same lock
> > > > > > > > > > > > > > for non-related data structures.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > I see the relation like next:
> > > > > > > > > > > > > Since the ownership mechanism synchronization is in
> > > > > > > > > > > > > ethdev responsibility, we must protect against user
> > > > > > > > > > > > > mistakes as much as we can by
> > > > > > > > > > > > using the same lock.
> > > > > > > > > > > > > So, if user try to set by invalid owner (exactly the
> > > > > > > > > > > > > ID which currently is
> > > > > > > > > > > > allocated) we can protect on it.
> > > > > > > > > > > >
> > > > > > > > > > > > Hmm, not sure why you can't do same checking with
> > > > > > > > > > > > different lock or atomic variable?
> > > > > > > > > > > >
> > > > > > > > > > > The set ownership API is protected by ownership lock and
> > > > > > > > > > > checks the owner ID validity By reading the next owner ID.
> > > > > > > > > > > So, the owner ID allocation and set API should use the
> > > > > > > > > > > same atomic
> > > > > > > > > > mechanism.
> > > > > > > > > >
> > > > > > > > > > Sure but all you are doing for checking validity, is check
> > > > > > > > > > that owner_id > 0 &&& owner_id < next_ownwe_id, right?
> > > > > > > > > > As you don't allow owner_id overlap (16/3248 bits) you can
> > > > > > > > > > safely do same check with just atomic_get(&next_owner_id).
> > > > > > > > > >
> > > > > > > > > It will not protect it, scenario:
> > > > > > > > > - current next_id is X.
> > > > > > > > > - call set ownership of port A with owner id X by thread 0(by
> > > > > > > > > user
> > > > > > mistake).
> > > > > > > > > - context switch
> > > > > > > > > - allocate new id by thread 1 and get X and change next_id to
> > > > > > > > > X+1
> > > > > > > > atomically.
> > > > > > > > > - context switch
> > > > > > > > > - Thread 0 validate X by atomic_read and succeed to take
> > > > ownership.
> > > > > > > > > - The system loosed the port(or will be managed by two
> > > > > > > > > entities) -
> > > > > > crash.
> > > > > > > >
> > > > > > > >
> > > > > > > > Ok, and how using lock will protect you with such scenario?
> > > > > > >
> > > > > > > The owner set API validation by thread 0 should fail because the
> > > > > > > owner
> > > > > > validation is included in the protected section.
> > > > > >
> > > > > > Then your validation function would fail even if you'll use atomic
> > > > > > ops instead of lock.
> > > > > No.
> > > > > With atomic this specific scenario will cause the validation to pass.
> > > >
> > > > Can you explain to me how?
> > > >
> > > > rte_eth_is_valid_owner_id(uint16_t owner_id) {
> > > > int32_t cur_owner_id = RTE_MIN(rte_atomic32_get(next_owner_id),
> > > > UINT16_MAX);
> > > >
> > > > if (owner_id == RTE_ETH_DEV_NO_OWNER || owner >
> > > > cur_owner_id) {
> > > > RTE_LOG(ERR, EAL, "Invalid owner_id=%d.\n", owner_id);
> > > > return 0;
> > > > }
> > > > return 1;
> > > > }
> > > >
> > > > Let say your next_owne_id==X, and you invoke
> > > > rte_eth_is_valid_owner_id(owner_id=X+1) - it would fail.
> > >
> > > Explanation:
> > > The scenario with locks:
> > > next_owner_id = X.
> > > Thread 0 call to set API(with invalid owner Y=X) and take lock.
> > > Context switch.
> > > Thread 1 call to owner_new and stuck in the lock.
> > > Context switch.
> > > Thread 0 does owner id validation and failed(Y>=X) - unlock the lock and return failure to the user.
> > > Context switch.
> > > Thread 1 take the lock and update X to X+1, then, unlock the lock.
> > > Everything is OK!
> > >
> > > The same scenario with atomics:
> > > next_owner_id = X.
> > > Thread 0 call to set API(with invalid owner Y=X) and take lock.
> > > Context switch.
> > > Thread 1 call to owner_new and change X to X+1(atomically).
> > > Context switch.
> > > Thread 0 does owner id validation and success(Y<(atomic)X+1) - unlock the lock and return success to the user.
> > > Problem!
> > >
> >
> >
> > Matan is correct here, there is no way to preform parallel set operations using
> > just and atomic variable here, because multiple reads of next_owner_id need to
> > be preformed while it is stable. That is to say rte_eth_next_owner_id must be
> > compared to RTE_ETH_DEV_NO_OWNER and owner_id in rte_eth_is_valid_owner_id. If
> > you were to only use an atomic_read on such a variable, it could be incremented
> > by the owner_new function between the checks and an invalid owner value could
> > become valid because a third thread incremented the next value. The state of
> > next_owner_id must be kept stable during any validity checks
>
> It could still be incremented between the checks - if let say different thread will
> invoke new_onwer_id, grab the lock update counter, release the lock - all that
> before the check.
Yes, as I mentioned previously, thats an artifact of this implementation, and
arguably ok, because the state of next is still kept steady during the check
process. Theres no guarantee that, once you call new, you will be able to take
ownership. The result of the set operation determines that. If you want to
ensure that you claim ownership on set, then you need to make the allocation of
an owner object atomic with its aquisition of the port, the way my proposed api
below does.
> But ok, there is probably no point to argue on that one any longer -
> let's keep the lock here, nothing will be broken with it for sure.
>
Agree.
> >
> > That said, I really have to wonder why ownership ids are really needed here at
> > all. It seems this design could be much simpler with the addition of a per-port
> > lock (and optional ownership record). The API could consist of three
> > operations:
> >
> > ownership_set
> > ownership_tryset
> > ownership_release
> > ownership_get
> >
>
> Ok, but how to distinguish who is the current owner of the port?
> To make sure that only owner is allowed to perform control ops?
> Konstantin
>
As I said above, if you want to have an ownership record, theres no reason you
can't (thats what ownership_get is intended to return to you). Perhaps a better
api would be an is_owner(owner_record) call, which can atomically compare a
passed in owner record with the current ownership and return true/false if they
match
Neil
> >
> > The first call simply tries to take the per-port lock (blocking if its already
> > locked)
> >
> > The second call is a non-blocking version of the first
> >
> > The third unlocks the port, allowing others to take ownership
> >
> > The fourth returns whatever ownership record you want to encode with the lock.
> >
> > The addition of all this id checking seems a bit overcomplicated
> >
> > Neil
>
>
next prev parent reply other threads:[~2018-01-18 16:28 UTC|newest]
Thread overview: 212+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-28 11:57 [dpdk-dev] [PATCH 0/5] ethdev: Port ownership Matan Azrad
2017-11-28 11:57 ` [dpdk-dev] [PATCH 1/5] ethdev: free a port by a dedicated API Matan Azrad
2017-11-28 11:57 ` [dpdk-dev] [PATCH 2/5] ethdev: add port ownership Matan Azrad
2017-11-30 12:36 ` Neil Horman
2017-11-30 13:24 ` Gaëtan Rivet
2017-11-30 14:30 ` Matan Azrad
2017-11-30 15:09 ` Gaëtan Rivet
2017-11-30 15:43 ` Matan Azrad
2017-12-01 12:09 ` Neil Horman
2017-12-03 8:04 ` Matan Azrad
2017-12-03 11:10 ` Ananyev, Konstantin
2017-12-03 13:46 ` Matan Azrad
2017-12-04 16:01 ` Neil Horman
2017-12-04 18:10 ` Matan Azrad
2017-12-04 22:30 ` Neil Horman
2017-12-05 6:08 ` Matan Azrad
2017-12-05 10:05 ` Bruce Richardson
2017-12-08 11:35 ` Thomas Monjalon
2017-12-08 12:31 ` Neil Horman
2017-12-21 17:06 ` Thomas Monjalon
2017-12-21 17:43 ` Neil Horman
2017-12-21 19:37 ` Matan Azrad
2017-12-21 20:14 ` Neil Horman
2017-12-21 21:57 ` Matan Azrad
2017-12-22 14:26 ` Neil Horman
2017-12-23 22:36 ` Matan Azrad
2017-12-29 16:56 ` Neil Horman
2017-12-05 19:26 ` Neil Horman
2017-12-08 11:06 ` Thomas Monjalon
2017-12-05 11:12 ` Ananyev, Konstantin
2017-12-05 11:44 ` Ananyev, Konstantin
2017-12-05 11:53 ` Thomas Monjalon
2017-12-05 14:56 ` Bruce Richardson
2017-12-05 14:57 ` Ananyev, Konstantin
2017-12-05 11:47 ` Thomas Monjalon
2017-12-05 15:13 ` Ananyev, Konstantin
2017-12-05 15:49 ` Thomas Monjalon
2017-11-28 11:57 ` [dpdk-dev] [PATCH 3/5] net/failsafe: free an eth port by a dedicated API Matan Azrad
2017-11-28 11:58 ` [dpdk-dev] [PATCH 4/5] net/failsafe: use ownership mechanism to own ports Matan Azrad
2017-11-28 11:58 ` [dpdk-dev] [PATCH 5/5] app/testpmd: adjust ethdev port ownership Matan Azrad
2018-01-07 9:45 ` [dpdk-dev] [PATCH v2 0/6] ethdev: " Matan Azrad
2018-01-07 9:45 ` [dpdk-dev] [PATCH v2 1/6] ethdev: fix port data reset timing Matan Azrad
2018-01-07 9:45 ` [dpdk-dev] [PATCH v2 2/6] ethdev: add port ownership Matan Azrad
2018-01-10 13:36 ` Ananyev, Konstantin
2018-01-10 16:58 ` Matan Azrad
2018-01-11 12:40 ` Ananyev, Konstantin
2018-01-11 14:51 ` Matan Azrad
2018-01-12 0:02 ` Ananyev, Konstantin
2018-01-12 7:24 ` Matan Azrad
2018-01-15 11:45 ` Ananyev, Konstantin
2018-01-15 13:09 ` Matan Azrad
2018-01-15 18:43 ` Ananyev, Konstantin
2018-01-16 8:04 ` Matan Azrad
2018-01-16 19:11 ` Ananyev, Konstantin
2018-01-16 20:32 ` Matan Azrad
2018-01-17 11:24 ` Ananyev, Konstantin
2018-01-17 12:05 ` Matan Azrad
2018-01-17 12:54 ` Ananyev, Konstantin
2018-01-17 13:10 ` Matan Azrad
2018-01-17 16:52 ` Ananyev, Konstantin
2018-01-17 18:02 ` Matan Azrad
2018-01-17 20:34 ` Matan Azrad
2018-01-18 14:17 ` Ananyev, Konstantin
2018-01-18 14:26 ` Matan Azrad
2018-01-18 14:41 ` Ananyev, Konstantin
2018-01-18 14:45 ` Matan Azrad
2018-01-18 14:51 ` Ananyev, Konstantin
2018-01-18 15:00 ` Matan Azrad
2018-01-17 14:00 ` Neil Horman
2018-01-17 17:01 ` Ananyev, Konstantin
2018-01-18 13:10 ` Neil Horman
2018-01-18 14:00 ` Matan Azrad
2018-01-18 16:54 ` Neil Horman
2018-01-18 17:20 ` Matan Azrad
2018-01-18 18:41 ` Neil Horman
2018-01-18 20:21 ` Matan Azrad
2018-01-19 1:41 ` Neil Horman
2018-01-19 7:14 ` Matan Azrad
2018-01-19 9:30 ` Bruce Richardson
2018-01-19 10:44 ` Matan Azrad
2018-01-19 13:30 ` Neil Horman
2018-01-19 13:57 ` Matan Azrad
2018-01-19 14:13 ` Thomas Monjalon
2018-01-19 15:27 ` Neil Horman
2018-01-19 17:17 ` Thomas Monjalon
2018-01-19 17:43 ` Neil Horman
2018-01-19 18:12 ` Thomas Monjalon
2018-01-19 19:47 ` Neil Horman
2018-01-19 20:19 ` Thomas Monjalon
2018-01-19 22:52 ` Neil Horman
2018-01-20 3:38 ` Tuxdriver
2018-01-20 12:54 ` Ananyev, Konstantin
2018-01-20 14:02 ` Thomas Monjalon
2018-01-19 12:55 ` Neil Horman
2018-01-19 13:52 ` Neil Horman
2018-01-18 16:27 ` Neil Horman [this message]
2018-01-17 17:58 ` Matan Azrad
2018-01-18 13:20 ` Neil Horman
2018-01-18 14:52 ` Matan Azrad
2018-01-19 13:57 ` Neil Horman
2018-01-19 14:07 ` Thomas Monjalon
2018-01-19 14:32 ` Neil Horman
2018-01-19 17:09 ` Thomas Monjalon
2018-01-19 17:37 ` Neil Horman
2018-01-19 18:10 ` Thomas Monjalon
2018-01-21 22:12 ` Ferruh Yigit
2018-01-07 9:45 ` [dpdk-dev] [PATCH v2 3/6] ethdev: synchronize port allocation Matan Azrad
2018-01-07 9:58 ` Matan Azrad
2018-01-07 9:45 ` [dpdk-dev] [PATCH v2 4/6] net/failsafe: free an eth port by a dedicated API Matan Azrad
2018-01-07 9:45 ` [dpdk-dev] [PATCH v2 5/6] net/failsafe: use ownership mechanism to own ports Matan Azrad
2018-01-08 10:32 ` Gaëtan Rivet
2018-01-08 11:16 ` Matan Azrad
2018-01-08 11:35 ` Gaëtan Rivet
2018-01-07 9:45 ` [dpdk-dev] [PATCH v2 6/6] app/testpmd: adjust ethdev port ownership Matan Azrad
2018-01-08 11:39 ` Gaëtan Rivet
2018-01-08 12:30 ` Matan Azrad
2018-01-08 13:30 ` Gaëtan Rivet
2018-01-08 13:55 ` Matan Azrad
2018-01-08 14:21 ` Gaëtan Rivet
2018-01-08 14:42 ` Matan Azrad
2018-01-16 5:53 ` Lu, Wenzhuo
2018-01-16 8:15 ` Matan Azrad
2018-01-17 0:46 ` Lu, Wenzhuo
2018-01-17 8:51 ` Matan Azrad
2018-01-18 0:53 ` Lu, Wenzhuo
2018-01-18 16:35 ` [dpdk-dev] [PATCH v3 0/7] Port ownership and syncronization Matan Azrad
2018-01-18 16:35 ` [dpdk-dev] [PATCH v3 1/7] ethdev: fix port data reset timing Matan Azrad
2018-01-18 17:00 ` Thomas Monjalon
2018-01-19 12:38 ` Ananyev, Konstantin
2018-03-05 11:24 ` [dpdk-dev] [dpdk-stable] " Ferruh Yigit
2018-03-05 14:52 ` Matan Azrad
2018-03-05 15:06 ` Ferruh Yigit
2018-03-05 15:12 ` Matan Azrad
2018-03-27 22:37 ` Ferruh Yigit
2018-03-28 12:07 ` Matan Azrad
2018-03-30 10:39 ` Ferruh Yigit
2018-04-19 11:07 ` Ferruh Yigit
2018-04-25 12:16 ` Matan Azrad
2018-04-25 12:30 ` Ori Kam
2018-04-25 12:54 ` Ferruh Yigit
2018-04-25 14:01 ` Matan Azrad
2018-01-18 16:35 ` [dpdk-dev] [PATCH v3 2/7] ethdev: fix used portid allocation Matan Azrad
2018-01-18 17:00 ` Thomas Monjalon
2018-01-19 12:40 ` Ananyev, Konstantin
2018-01-20 16:48 ` Matan Azrad
2018-01-20 17:26 ` Ananyev, Konstantin
2018-01-18 16:35 ` [dpdk-dev] [PATCH v3 3/7] ethdev: add port ownership Matan Azrad
2018-01-18 21:11 ` Thomas Monjalon
2018-01-19 12:41 ` Ananyev, Konstantin
2018-01-18 16:35 ` [dpdk-dev] [PATCH v3 4/7] ethdev: synchronize port allocation Matan Azrad
2018-01-18 20:43 ` Thomas Monjalon
2018-01-18 20:52 ` Matan Azrad
2018-01-18 21:17 ` Thomas Monjalon
2018-01-19 12:47 ` Ananyev, Konstantin
2018-01-18 16:35 ` [dpdk-dev] [PATCH v3 5/7] net/failsafe: free an eth port by a dedicated API Matan Azrad
2018-01-18 16:35 ` [dpdk-dev] [PATCH v3 6/7] net/failsafe: use ownership mechanism to own ports Matan Azrad
2018-01-18 16:35 ` [dpdk-dev] [PATCH v3 7/7] app/testpmd: adjust ethdev port ownership Matan Azrad
2018-01-19 12:37 ` Ananyev, Konstantin
2018-01-19 12:51 ` Matan Azrad
2018-01-19 13:08 ` Ananyev, Konstantin
2018-01-19 13:35 ` Matan Azrad
2018-01-19 15:00 ` Gaëtan Rivet
2018-01-20 18:14 ` Matan Azrad
2018-01-22 10:17 ` Gaëtan Rivet
2018-01-22 11:22 ` Matan Azrad
2018-01-22 12:28 ` Ananyev, Konstantin
2018-01-22 13:22 ` Matan Azrad
2018-01-22 20:48 ` Ananyev, Konstantin
2018-01-23 8:54 ` Matan Azrad
2018-01-23 12:56 ` Gaëtan Rivet
2018-01-23 14:30 ` Matan Azrad
2018-01-25 9:36 ` Matan Azrad
2018-01-25 10:05 ` Thomas Monjalon
2018-01-25 11:15 ` Ananyev, Konstantin
2018-01-25 11:33 ` Thomas Monjalon
2018-01-25 11:55 ` Ananyev, Konstantin
2018-01-23 13:34 ` Ananyev, Konstantin
2018-01-23 14:18 ` Thomas Monjalon
2018-01-23 15:12 ` Ananyev, Konstantin
2018-01-23 15:18 ` Ananyev, Konstantin
2018-01-23 17:33 ` Thomas Monjalon
2018-01-23 21:18 ` Ananyev, Konstantin
2018-01-24 8:10 ` Thomas Monjalon
2018-01-24 18:30 ` Ananyev, Konstantin
2018-01-25 10:55 ` Thomas Monjalon
2018-01-25 11:09 ` Ananyev, Konstantin
2018-01-25 11:27 ` Thomas Monjalon
2018-01-23 14:43 ` Matan Azrad
2018-01-20 21:24 ` [dpdk-dev] [PATCH v4 0/7] Port ownership and syncronization Matan Azrad
2018-01-20 21:24 ` [dpdk-dev] [PATCH v4 1/7] ethdev: fix port data reset timing Matan Azrad
2018-01-20 21:24 ` [dpdk-dev] [PATCH v4 2/7] ethdev: fix used portid allocation Matan Azrad
2018-01-20 21:24 ` [dpdk-dev] [PATCH v4 3/7] ethdev: add port ownership Matan Azrad
2018-01-21 20:43 ` Ferruh Yigit
2018-01-21 20:46 ` Ferruh Yigit
2018-01-20 21:24 ` [dpdk-dev] [PATCH v4 4/7] ethdev: synchronize port allocation Matan Azrad
2018-01-20 21:24 ` [dpdk-dev] [PATCH v4 5/7] net/failsafe: free an eth port by a dedicated API Matan Azrad
2018-01-20 21:24 ` [dpdk-dev] [PATCH v4 6/7] net/failsafe: use ownership mechanism to own ports Matan Azrad
2018-01-20 21:24 ` [dpdk-dev] [PATCH v4 7/7] app/testpmd: adjust ethdev port ownership Matan Azrad
2018-01-22 16:38 ` [dpdk-dev] [PATCH v5 0/7] Port ownership and synchronization Matan Azrad
2018-01-22 16:38 ` [dpdk-dev] [PATCH v5 1/7] ethdev: fix port data reset timing Matan Azrad
2018-01-22 16:38 ` [dpdk-dev] [PATCH v5 2/7] ethdev: fix used portid allocation Matan Azrad
2018-01-22 16:38 ` [dpdk-dev] [PATCH v5 3/7] ethdev: add port ownership Matan Azrad
2018-01-22 16:38 ` [dpdk-dev] [PATCH v5 4/7] ethdev: synchronize port allocation Matan Azrad
2018-01-22 16:38 ` [dpdk-dev] [PATCH v5 5/7] net/failsafe: free an eth port by a dedicated API Matan Azrad
2018-01-22 16:38 ` [dpdk-dev] [PATCH v5 6/7] net/failsafe: use ownership mechanism to own ports Matan Azrad
2018-01-22 16:38 ` [dpdk-dev] [PATCH v5 7/7] app/testpmd: adjust ethdev port ownership Matan Azrad
2018-01-25 1:47 ` Lu, Wenzhuo
2018-01-25 8:30 ` Matan Azrad
2018-01-26 0:50 ` Lu, Wenzhuo
2018-01-29 11:21 ` [dpdk-dev] [PATCH v5 0/7] Port ownership and synchronization Matan Azrad
2018-01-31 19:53 ` Thomas Monjalon
2018-01-25 14:35 ` [dpdk-dev] [PATCH v3 0/7] Port ownership and syncronization Ferruh Yigit
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180118162744.GC1622@hmswarspite.think-freely.org \
--to=nhorman@tuxdriver.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=gaetan.rivet@6wind.com \
--cc=jingjing.wu@intel.com \
--cc=konstantin.ananyev@intel.com \
--cc=matan@mellanox.com \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).