From: Neil Horman <nhorman@tuxdriver.com>
To: Matan Azrad <matan@mellanox.com>
Cc: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
"Gaëtan Rivet" <gaetan.rivet@6wind.com>,
"Thomas Monjalon" <thomas@monjalon.net>,
"Wu, Jingjing" <jingjing.wu@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH 2/5] ethdev: add port ownership
Date: Mon, 4 Dec 2017 17:30:51 -0500 [thread overview]
Message-ID: <20171204223051.GA11618@hmswarspite.think-freely.org> (raw)
In-Reply-To: <HE1PR0502MB36599F82DA6268F5387239E8D23C0@HE1PR0502MB3659.eurprd05.prod.outlook.com>
On Mon, Dec 04, 2017 at 06:10:56PM +0000, Matan Azrad wrote:
> Hi Neil
>
> > -----Original Message-----
> > From: Neil Horman [mailto:nhorman@tuxdriver.com]
> > Sent: Monday, December 4, 2017 6:01 PM
> > To: Matan Azrad <matan@mellanox.com>
> > Cc: Ananyev, Konstantin <konstantin.ananyev@intel.com>; Gaëtan Rivet
> > <gaetan.rivet@6wind.com>; Thomas Monjalon <thomas@monjalon.net>;
> > Wu, Jingjing <jingjing.wu@intel.com>; dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH 2/5] ethdev: add port ownership
> >
> > On Sun, Dec 03, 2017 at 01:46:49PM +0000, Matan Azrad wrote:
> > > Hi Konstantine
> > >
> > > > -----Original Message-----
> > > > From: Ananyev, Konstantin [mailto:konstantin.ananyev@intel.com]
> > > > Sent: Sunday, December 3, 2017 1:10 PM
> > > > To: Matan Azrad <matan@mellanox.com>; Neil Horman
> > > > <nhorman@tuxdriver.com>; Gaëtan Rivet <gaetan.rivet@6wind.com>
> > > > Cc: Thomas Monjalon <thomas@monjalon.net>; Wu, Jingjing
> > > > <jingjing.wu@intel.com>; dev@dpdk.org
> > > > Subject: RE: [dpdk-dev] [PATCH 2/5] ethdev: add port ownership
> > > >
> > > >
> > > >
> > > > Hi Matan,
> > > >
> > > > > -----Original Message-----
> > > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Matan Azrad
> > > > > Sent: Sunday, December 3, 2017 8:05 AM
> > > > > To: Neil Horman <nhorman@tuxdriver.com>; Gaëtan Rivet
> > > > > <gaetan.rivet@6wind.com>
> > > > > Cc: Thomas Monjalon <thomas@monjalon.net>; Wu, Jingjing
> > > > > <jingjing.wu@intel.com>; dev@dpdk.org
> > > > > Subject: Re: [dpdk-dev] [PATCH 2/5] ethdev: add port ownership
> > > > >
> > > > > Hi
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Neil Horman [mailto:nhorman@tuxdriver.com]
> > > > > > Sent: Friday, December 1, 2017 2:10 PM
> > > > > > To: Gaëtan Rivet <gaetan.rivet@6wind.com>
> > > > > > Cc: Matan Azrad <matan@mellanox.com>; Thomas Monjalon
> > > > > > <thomas@monjalon.net>; Jingjing Wu <jingjing.wu@intel.com>;
> > > > > > dev@dpdk.org
> > > > > > Subject: Re: [dpdk-dev] [PATCH 2/5] ethdev: add port ownership
> > > > > >
> > > > > > On Thu, Nov 30, 2017 at 02:24:43PM +0100, Gaëtan Rivet wrote:
> > > > > > > Hello Matan, Neil,
> > > > > > >
> > > > > > > I like the port ownership concept. I think it is needed to
> > > > > > > clarify some operations and should be useful to several subsystems.
> > > > > > >
> > > > > > > This patch could certainly be sub-divided however, and your
> > > > > > > current
> > > > > > > 1/5 should probably come after this one.
> > > > > > >
> > > > > > > Some comments inline.
> > > > > > >
> > > > > > > On Thu, Nov 30, 2017 at 07:36:11AM -0500, Neil Horman wrote:
> > > > > > > > On Tue, Nov 28, 2017 at 11:57:58AM +0000, Matan Azrad wrote:
> > > > > > > > > The ownership of a port is implicit in DPDK.
> > > > > > > > > Making it explicit is better from the next reasons:
> > > > > > > > > 1. It may be convenient for multi-process applications to
> > > > > > > > > know
> > > > which
> > > > > > > > > process is in charge of a port.
> > > > > > > > > 2. A library could work on top of a port.
> > > > > > > > > 3. A port can work on top of another port.
> > > > > > > > >
> > > > > > > > > Also in the fail-safe case, an issue has been met in testpmd.
> > > > > > > > > We need to check that the user is not trying to use a port
> > > > > > > > > which is already managed by fail-safe.
> > > > > > > > >
> > > > > > > > > Add ownership mechanism to DPDK Ethernet devices to avoid
> > > > > > > > > multiple management of a device by different DPDK entities.
> > > > > > > > >
> > > > > > > > > A port owner is built from owner id(number) and owner
> > > > > > > > > name(string) while the owner id must be unique to
> > > > > > > > > distinguish between two identical entity instances and the
> > > > > > > > > owner name can be
> > > > any name.
> > > > > > > > > The name helps to logically recognize the owner by
> > > > > > > > > different DPDK entities and allows easy debug.
> > > > > > > > > Each DPDK entity can allocate an owner unique identifier
> > > > > > > > > and can use it and its preferred name to owns valid ethdev
> > ports.
> > > > > > > > > Each DPDK entity can get any port owner status to decide
> > > > > > > > > if it can manage the port or not.
> > > > > > > > >
> > > > > > > > > The current ethdev internal port management is not
> > > > > > > > > affected by this feature.
> > > > > > > > >
> > > > > > >
> > > > > > > The internal port management is not affected, but the external
> > > > > > > interface is, however. In order to respect port ownership,
> > > > > > > applications are forced to modify their port iterator, as
> > > > > > > shown by your
> > > > > > testpmd patch.
> > > > > > >
> > > > > > > I think it would be better to modify the current
> > > > > > > RTE_ETH_FOREACH_DEV to call RTE_FOREACH_DEV_OWNED_BY,
> > and
> > > > > > > introduce a default owner that would represent the application
> > > > > > > itself (probably with the ID 0 and an owner string ""). Only
> > > > > > > with specific additional configuration should this default
> > > > > > > subset of ethdev be
> > > > divided.
> > > > > > >
> > > > > > > This would make this evolution seamless for applications, at
> > > > > > > no cost to the complexity of the design.
> > > > > > >
> > > > > > > > > Signed-off-by: Matan Azrad <matan@mellanox.com>
> > > > > > > >
> > > > > > > >
> > > > > > > > This seems fairly racy. What if one thread attempts to set
> > > > > > > > ownership on a port, while another is checking it on another
> > > > > > > > cpu in parallel. It doesn't seem like it will protect against that at all.
> > > > > > > > It also doesn't protect against the possibility of multiple
> > > > > > > > threads attempting to poll for rx in parallel, which I think
> > > > > > > > was part of Thomas's origional statement regarding port
> > > > > > > > ownership (he noted that the lockless design implied only a
> > > > > > > > single thread should be allowed to poll
> > > > > > for receive or make configuration changes at a time.
> > > > > > > >
> > > > > > > > Neil
> > > > > > > >
> > > > > > >
> > > > > > > Isn't this race already there for any configuration operation
> > > > > > > / polling function? The DPDK arch is expecting applications to solve
> > it.
> > > > > > > Why should port ownership be designed differently from other
> > > > > > > DPDK
> > > > > > components?
> > > > > > >
> > > > > > Yes, but that doesn't mean it should exist in purpituity, nor
> > > > > > does it mean that your new api should contain it as well.
> > > > > >
> > > > > > > Embedding checks for port ownership within operations will
> > > > > > > force everyone to bear their costs, even those not interested
> > > > > > > in using this API. These checks should be kept outside, within
> > > > > > > the entity claiming ownership of the port, in the form of
> > > > > > > using the proper port iterator IMO.
> > > > > > >
> > > > > > No. At the very least, you need to make the API itself exclusive.
> > > > > > That is to say, you should at least ensure that a port ownership
> > > > > > get call doesn't race with a port ownership set call. It seems
> > > > > > rediculous to just leave that sort of locking as an exercize to the user.
> > > > > >
> > > > > > Neil
> > > > > >
> > > > > Neil,
> > > > > As Thomas mentioned, a DPDK port is designed to be managed by only
> > > > > one thread (or synchronized DPDK entity).
> > > > > So all the port management includes port ownership shouldn't be
> > > > > synchronized, i.e. locks are not needed.
> > > > > If some application want to do dual thread port management, the
> > > > > responsibility to synchronize the port ownership or any other port
> > > > > management is on this application.
> > > > > Port ownership doesn't come to allow synchronized management of
> > > > > the port by two DPDK entities in parallel, it is just nice way to
> > > > > answer next
> > > > questions:
> > > > > 1. Is the port already owned by some DPDK entity(in early control
> > > > path)?
> > > > > 2. If yes, Who is the owner?
> > > > > If the answer to the first question is no, the current entity can
> > > > > take the ownership without any lock(1 thread).
> > > > > If the answer to the first question is yes, you can recognize the
> > > > > owner and take decisions accordingly, sometimes you can decide to
> > > > > use the port because you logically know what the current owner
> > > > > does and you can be logically synchronized with it, sometimes you
> > > > > can just leave this port because you have not any deal with this owner.
> > > >
> > > > If the goal is just to have an ability to recognize is that device
> > > > is managed by another device (failsafe, bonding, etc.), then I
> > > > think all we need is a pointer to rte_eth_dev_data of the owner (NULL
> > would mean no owner).
> > >
> > > I think string is better than a pointer from the next reasons:
> > > 1. It is more human friendly than pointers for debug and printing.
> > > 2. it is flexible and allows to forward logical owner message to other DPDK
> > entities.
> > >
> > > > Also I think if we'd like to introduce that mechanism, then it needs
> > > > to be
> > > > - mandatory (control API just don't allow changes to the device
> > > > configuration if caller is not an owner).
> > >
> > > But what if 2 DPDK entities should manage the same port \ using it and they
> > are synchronized?
> > >
> > > > - transparent to the user (no API changes).
> > >
> > > For now, there is not API change but new suggested API to use for port
> > iteration.
> > >
> > > > - set/get owner ops need to be atomic if we want this mechanism to
> > > > be usable for MP.
> > >
> > > But also without atomic this mechanism is usable in MP.
> > > For example:
> > > PRIMARY application can set its owner with string "primary A".
> > > SECONDARY process (which attach to the ports only after the primary
> > created them )is not allowed to set owner(As you can see in the code) but it
> > can read the owner string and see that the port owner is the primary
> > application.
> > > The "A" can just sign specific port type to the SECONDARY that this port
> > works with logic A which means, for example, primary should send the
> > packets and secondary should receive the packets.
> > >
> > But thats just the point, the operations that you are describing are not atomic
> > at all. If the primary process is interrupted during its setting of a ports owner
> > ship after its read the current owner field, its entirely possible for the
> > secondary proces to set the owner as itself, and then have the primary
> > process set it back. Without locking, its just broken. I know that the dpdk
> > likes to say its lockless, because it has no locks, but here we're just kicking the
> > can down the road, by making the application add the locks for the library.
> >
> > Neil
> >
> As I wrote before and as is in the code you can understand that secondary process should not take ownership of ports.
But you allow for it, and if you do, you should write your api to be safe for
such opperations.
> Any port configuration (for example port creation and release) is not internally synchronized between the primary to secondary processes so I don't see any reason to synchronize port ownership.
Yes, and I've never agreed with that design point either, because the fact of
the matter is that one of two things must be true in relation to port
configuration:
1) Either multiple processes will attempt to read/change port
configuration/ownership
or
2) port ownership is implicitly given to a single task (be it a primary or
secondary task), and said ownership is therefore implicitly known by the
application
Either situation may be true depending on the details of the application being
built, but regardless, if (2) is true, then this api isn't really needed at all,
because the application implicitly has been designed to have a port be owned by
a given task. If (1) is true, then all the locking required to access the data
of port ownership needs to be adhered to.
I understand that you are taking Thomas' words to mean that all paths are
lockless in the DPDK, and that is true as a statement of fact (in that the DPDK
doesn't synchronize access to internal data). What it does do, is leave that
locking as an exercize for the downstream consumer of the library. While I
don't agree with it, I can see that such an argument is valid for hot paths such
as transmission and reception where you may perhaps want to minimize your
locking by assigning a single task to do that work, but port configuration and
ownership isn't a hot path. If you mean to allow potentially multiple tasks to
access configuration (including port ownership), be it frequently or just
occasionaly, why are you making a downstream developer recognize the need for
locking here outside the library? It just seems like very bad general practice
to me.
> If the primary-secondary process want to manage(configure) same port in same time, they must be synchronized by the applications, so this is the case in port ownership too (actually I don't think this synchronization is realistic because many configurations of the port are not in shared memory).
Yes, it is the case, my question is, why? We're not talking about a time
sensitive execution path here. And by avoiding it you're just making work that
has to be repeated by every downstream consumer.
Neil
next prev parent reply other threads:[~2017-12-04 22:32 UTC|newest]
Thread overview: 214+ 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 [this message]
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
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
2017-12-06 0:40 [dpdk-dev] [PATCH 2/5] ethdev: add port ownership Ananyev, Konstantin
2017-12-06 9:22 ` Thomas Monjalon
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=20171204223051.GA11618@hmswarspite.think-freely.org \
--to=nhorman@tuxdriver.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).