On Wed, Jun 14, 2023, at 21:33, Stephen Hemminger wrote:
> On Thu, 23 Jan 2020 10:58:13 +0100
> Gaetan Rivet wrote:
>
>> Add a new EAL option enabling manual probing in the EAL.
>> This command line option will configure the EAL so that buses
>> will not trigger their probe step on their own.
>>
On Sat, Feb 25, 2023, at 11:16, David Marchand wrote:
> Salut Gaëtan,
>
> On Fri, Feb 24, 2023 at 4:59 PM Gaëtan Rivet wrote:
>> > FreeBSD libc pthread API has lock annotations while Linux glibc has
>> > none.
>> > We could simply disable the check on FreeBS
On Fri, Feb 24, 2023, at 16:11, David Marchand wrote:
> This is a followup of the series that introduced lock annotations.
> I reworked and made annotations work in what seemed the easier cases.
> In most cases, I chose to convert inline wrappers around the EAL lock
> API to simple macro: I did not
On Fri, Feb 24, 2023, at 16:11, David Marchand wrote:
> The pthread mutex API describes cases where locking might fail.
> Check fts_enter wrapper return code.
>
> Signed-off-by: David Marchand
Hello David,
Thanks for the fix,
Acked-by: Gaetan Rivet
--
Gaetan Rivet
On Tue, Feb 15, 2022, at 16:27, David Marchand wrote:
> On Thu, Feb 10, 2022 at 6:01 PM Gaetan Rivet wrote:
>>
>> The function rte_devargs_parse() previously was safe to call with
>> non-initialized devargs structure as parameter.
>>
>> When adding the support for the global device syntax,
>> this
On Tue, Feb 15, 2022, at 13:51, Ferruh Yigit wrote:
> On 2/10/2022 5:01 PM, Gaetan Rivet wrote:
>> The function rte_devargs_parse() previously was safe to call with
>> non-initialized devargs structure as parameter.
>>
>> When adding the support for the global device syntax,
>> this assumption was
On Fri, Feb 11, 2022, at 10:37, Madhuker Mythri wrote:
> Hi Gaetan and Ferruh,
>
>>
>>-Original Message-----
>>From: Gaëtan Rivet
>>Sent: 10 फरवरी 2022 21:39
>>To: Ferruh Yigit ; Madhuker Mythri
>>
>>Cc: dev@dpdk.org
>>Subject: [Extern
On Thu, Feb 10, 2022, at 16:00, Ferruh Yigit wrote:
> On 2/10/2022 7:10 AM, madhuker.myt...@oracle.com wrote:
>> From: Madhuker Mythri
>>
>> Failsafe pmd started crashing with global devargs syntax as devargs is
>> not memset to zero. Access it to in rte_devargs_parse resulted in a
>> crash when
On Thu, Oct 21, 2021, at 23:42, vipul.as...@oracle.com wrote:
> From: Vipul Ashri
>
> failsafe crashed while sending early link_update request during
> boot time initialization.
> Based on debugging we found failsafe device was good but sub-
> devices were progressing towards initialization and SU
On Thu, Nov 11, 2021, at 11:06, Kumara Parameshwaran wrote:
> Remove the vdev args check for secondary process which prevents the
> secondary from attaching
> to the device created by the primary process via the hotplug framework.
> This check was removed
> for other vdevs but was missed for fail
On Wed, Oct 20, 2021, at 17:47, Xueming Li wrote:
> Initial version to test global devargs syntax.
>
> Signed-off-by: Xueming Li
Hi,
Thanks for making the changes.
I have the nagging impression that the runtime checks could have been written
in a lighter way, but maybe that's just it. It seems t
On Wed, Oct 20, 2021, at 15:53, Xueming(Steven) Li wrote:
> On Wed, 2021-10-20 at 13:55 +0200, Gaëtan Rivet wrote:
>> On Wed, Oct 20, 2021, at 13:12, Xueming Li wrote:
>> > Initial version to test global devargs syntax.
>> >
>> > Signed-off-by: Xueming Li
On Wed, Oct 20, 2021, at 13:12, Xueming Li wrote:
> Initial version to test global devargs syntax.
>
> Signed-off-by: Xueming Li
> ---
> app/test/meson.build| 5 ++
> app/test/test_devargs.c | 184
> 2 files changed, 189 insertions(+)
> create mode
On Tue, Oct 5, 2021, at 17:54, Xueming Li wrote:
> Global devargs syntax is used as device iteration filter like
> "class=vdpa", a devargs without bus args is valid from parsing
> perspective.
>
> This patch makes bus args optional.
>
> Fixes: d2a66ad79480 ("bus: add device arguments name parsing")
On Tue, Oct 5, 2021, at 17:54, Xueming Li wrote:
> Initial version to test Global devargs syntax.
>
> Signed-off-by: Xueming Li
Hi,
The test is a very nice addition, absolutely required.
I have however two remarks on the coverage and the implementation, below.
> ---
> app/test/autotest_data.py
Hi Steven,
On Tue, Oct 5, 2021, at 17:54, Xueming Li wrote:
> Slash is used to split global device arguments.
>
> To support path value which contains slash, this patch parses devargs by
> locating both slash and layer name key:
> bus=a,name=/some/path/class=b,k1=v1/driver=c,k2=v2
> "/class=" an
On Wed, Jun 9, 2021, at 12:04, Andrew Rybchenko wrote:
> On 6/8/21 11:48 PM, Stephen Hemminger wrote:
> > On Tue, 8 Jun 2021 18:55:17 +0300
> > Andrew Rybchenko wrote:
> >
> >> On 6/8/21 6:42 PM, Stephen Hemminger wrote:
> >>> On Tue, 8 Jun 2021 11:00:37 +0300
> >>> Andrew Rybchenko wrote:
> >>>
On Fri, Apr 23, 2021, at 13:06, Kinsella, Ray wrote:
>
>
> On 14/04/2021 20:49, Thomas Monjalon wrote:
> > 13/04/2021 05:14, Xueming Li:
> >> Xueming Li (5):
> >> devargs: unify scratch buffer storage
> >> devargs: fix memory leak on parsing error
> >> kvargs: add get by key function
> >>
On Thu, Apr 1, 2021, at 11:05, Anatoly Burakov wrote:
> A common problem on the DPDK mailing list is lack of reviewers for
> patches. This script is intended to help with that problem, by picking
> a random commit author from our git history, and adding a Reviewed-by:
> tag. This can be added to e.
On Tue, Mar 30, 2021, at 14:15, Xueming Li wrote:
> The new Global Device Syntax [1] is used to identify a device with full
> bus, class and driver description, example:
> -a bus=pci,addr=82:00.0/class=eth/driver=mlx5,...
>
> This patchset fixes bugs and enable global device syntax with
> backwar
On Tue, Dec 22, 2020, at 08:51, Andrew Rybchenko wrote:
> Take minimum and maximum MTU values for subdevices and
> report maximum of minimums and minimum of maximums.
>
> Fixes: ad97ceece12c ("ethdev: add min/max MTU to device info")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Andrew Rybchenko
> --
On Fri, Feb 19, 2021, at 08:49, Ferruh Yigit wrote:
> On 12/22/2020 8:00 AM, Andrew Rybchenko wrote:
> > If sub-devices support RSS hash offload, the offload should be
> > reported by the failsafe device since handling is transparent
> > from failsafe point of view.
> >
> > Fixes: 5d308972954c ("e
On 26/11/20 10:24 +0800, Min Hu (Connor) wrote:
> what scenarios may cause bugs in old ways.
> Could you give an example, thanks.
Hello,
For example in the following code:
- RTE_ETH_FOREACH_DEV(i) {
- pci_dev = RTE_ETH_DEV_TO_PCI(&rte_eth_devices[i]);
- eth_pci_
On 09/11/20 12:58 +0100, David Marchand wrote:
> On Mon, Nov 9, 2020 at 12:32 PM Gaetan Rivet wrote:
> > + delta = 0;
> > + if (strncmp(name, "dpaa_bus:", 9) == 0) {
> > + delta = 9;
> > + } else if (strncmp(name, "name=", 5) == 0) {
> > + delta = 5;
>
On 09/11/20 12:31 +0100, Gaetan Rivet wrote:
> Device name parsing is done on all buses during device iterations at
> either EAL or ethdev levels.
>
> When a bus implements device name parsing slowly, all iterations are
> impacted. Efficient implementation is important.
>
> The DPAA bus device na
Hi Thomas,
This issue has already been fixed, see:
http://mails.dpdk.org/archives/dev/2020-October/185921.html
It has been integrated, Long was able to test it and confirm it fixed
this issue.
On 20/10/20 00:36 +0200, Thomas Monjalon wrote:
> Fixing Gaetan's address
>
> 20/10/2020 00:33, Thomas
On 15/10/20 10:49 +, Juraj Linkeš wrote:
> Hi dpdk devs,
>
> Is there a constraint on how low RTE_MAX_LCORE can be? I'm implementing a
> discovery mechanism that sets RTE_MAX_LCORE according to the number of host
> cores, but I'm hitting errors when the values are low:
> https://travis-ci.co
On 14/10/20 19:08 +0100, Ferruh Yigit wrote:
> On 10/14/2020 2:29 PM, Andrew Rybchenko wrote:
> > From: Ivan Ilchenko
> >
> > Change eth_dev_stop_t return value from void to int.
> > Make eth_dev_stop_t implementations across all drivers to return
> > negative errno values if case of error condit
On 02/10/20 17:01 -0700, Long Li wrote:
> From: Long Li
>
> When adding a sub-device, it's possible that the sub-device is configured
> successfully but later fails to start. This error should not be masked.
> The driver needs to check the error status to prevent endless loop of
> trying to start
On 14/10/20 09:25 +0300, Andrew Rybchenko wrote:
> On 10/13/20 7:56 PM, Ferruh Yigit wrote:
> > Prefix static function and variables with 'eth_dev'.
> >
> > For some 'rte_' prefix dropped, and for others 'eth_dev' added.
> > This is useful to differentiate public and static function/variables.
> >
On 09/10/20 20:30 +, Long Li wrote:
> >Subject: Re: [dpdk-dev] [PATCH] net/failsafe: check correct error code while
> >handling sub-device add
> >
> >On 05/10/20 11:42 +0200, Gaëtan Rivet wrote:
> >> Hi,
> >>
> >> On 02/10/20 17:01 -0700, Long
On 09/10/20 11:59 +0100, Ferruh Yigit wrote:
> On 10/9/2020 11:36 AM, Gaëtan Rivet wrote:
> > On 07/10/20 12:45 +0100, Ferruh Yigit wrote:
> > > On 10/7/2020 11:28 AM, Bruce Richardson wrote:
> > > > On Wed, Oct 07, 2020 at 11:26:38AM +0100, Bruce Richardson wrote:
On 05/10/20 11:42 +0200, Gaëtan Rivet wrote:
> Hi,
>
> On 02/10/20 17:01 -0700, Long Li wrote:
> > From: Long Li
> >
> > When adding a sub-device, it's possible that the sub-device is configured
> > successfully but later fails to start. This error sh
Hello,
On 29/09/20 01:15 +, Niu, Yawei wrote:
>
>
> On 2020/9/28, 11:44 PM, "Harris, James R" wrote:
>
> Hi Niu,
>
> I agree, this doesn't look right. Could you file an SPDK issue for this
> to make sure we track it? And then try sending an e-mail to the DPDK mailing
> li
On 07/10/20 12:45 +0100, Ferruh Yigit wrote:
> On 10/7/2020 11:28 AM, Bruce Richardson wrote:
> > On Wed, Oct 07, 2020 at 11:26:38AM +0100, Bruce Richardson wrote:
> > > On Wed, Oct 07, 2020 at 11:51:31AM +0200, Olivier Matz wrote:
> > > > On Wed, Oct 07, 2020 at 10:40:32AM +0100, Ferruh Yigit wrot
Hi Thomas,
On 29/09/20 01:14 +0200, Thomas Monjalon wrote:
> The flag RTE_ETH_DEV_CLOSE_REMOVE is set so all port resources
> can be freed by rte_eth_dev_close().
>
> Freeing of private port resources is moved
> from the ".remove(device)" to the ".dev_close(port)" operation.
>
> Signed-off-by: T
Hi,
On 02/10/20 17:01 -0700, Long Li wrote:
> From: Long Li
>
> When adding a sub-device, it's possible that the sub-device is configured
> successfully but later fails to start. This error should not be masked.
Some of those errors are meant to be masked: -EIO, when the device is
marked as rem
On 08/07/20 17:03 +0500, Muhammad Bilal wrote:
> while using memif with app, the resources are not cleaned on exit,
> So an error occurred on running it second time. The cause of this problem
> is that remove() of memif driver is not called by rte_eal_cleanup() which
> is counterpart of probe() cal
On 14/08/20 22:28 +0200, Gaëtan Rivet wrote:
> On 14/08/20 10:39 -0700, Stephen Hemminger wrote:
> > Already get a newline from WARN() macro call.
> >
> > Fixes: 9dda3e3393c2 ("net/failsafe: add timestamp to stats snapshot")
> > Cc: ma...@mellanox.com
On 14/08/20 10:39 -0700, Stephen Hemminger wrote:
> Already get a newline from WARN() macro call.
>
> Fixes: 9dda3e3393c2 ("net/failsafe: add timestamp to stats snapshot")
> Cc: ma...@mellanox.com
> Signed-off-by: Stephen Hemminger
Acked-by: Gaetan Rivet
>
> ---
> drivers/net/failsafe/failsa
On 11/08/20 15:48 +0300, Ivan Dyukov wrote:
> 11.08.2020 14:02, Gaëtan Rivet пишет:
> > On 11/08/20 11:52 +0300, Ivan Dyukov wrote:
> >> Link status structure keeps complicated values which are hard to
> >> represent to end user. e.g. link_speed has INT_MAX value whi
On 11/08/20 11:52 +0300, Ivan Dyukov wrote:
> Link status structure keeps complicated values which are hard to
> represent to end user. e.g. link_speed has INT_MAX value which
> means that speed is unknown, link_duplex equal to 0 means
> 'half-duplex' etc. To simplify processing of the values
> in
On 07/08/20 19:31 +0530, Jerin Jacob wrote:
> On Fri, Aug 7, 2020 at 7:04 PM Ferruh Yigit wrote:
> >
> > On 8/7/2020 2:23 PM, Bruce Richardson wrote:
> > > On Fri, Aug 07, 2020 at 06:49:47PM +0530, Jerin Jacob wrote:
> > >> On Fri, Aug 7, 2020 at 6:15 PM Bruce Richardson
> > >> wrote:
> > >>>
> >
On 07/08/20 02:15 +0200, Thomas Monjalon wrote:
> 06/08/2020 19:19, Stephen Hemminger:
> > Announce upcoming changes for 20.11.
> >
> > Signed-off-by: Stephen Hemminger
> > Acked-by: Bruce Richardson
>
> Acked-by: Thomas Monjalon
>
>
Good thing to update short options as well, -i and -x see
On 04/08/20 15:29 +0100, Bruce Richardson wrote:
> On Tue, Aug 04, 2020 at 04:07:52PM +0200, David Marchand wrote:
> > rte_kernel_driver is only used by the PCI subsystem and has polluted
> > ethdev for no reason.
> > Hide it in the PCI bus driver.
> >
> > Signed-off-by: David Marchand
> > ---
>
On 04/08/20 14:22 +0530, Jerin Jacob wrote:
> On Tue, Aug 4, 2020 at 2:18 PM David Marchand
> wrote:
> >
> > The PCI resources map API (pci_map_resource/pci_unmap_resource) was
> > imposing use of Unix mmap flags while it does not make sense on Windows.
> > This API was only used to internally se
On 31/07/20 10:26 +0100, Bruce Richardson wrote:
> On Thu, Jun 25, 2020 at 10:04:29AM +0200, Maxime Coquelin wrote:
> > In order to simplify the use of rte_dev_probe() and
> > rte_dev_remove() by applications, rte_dev_probe() will
> > return a reference on the rte_device stating DPDK v20.11.
> >
>
On 28/07/20 10:24 +0200, Morten Brørup wrote:
> + Ray and Neil as ABI Policy maintainers.
>
> > From: Honnappa Nagarahalli [mailto:honnappa.nagaraha...@arm.com]
> > Sent: Tuesday, July 28, 2020 4:19 AM
> >
> >
> > > >
> > > > > Subject: [dpdk-dev] [PATCH v10 01/10] eal: introduce macro for
> > b
On 27/07/20 15:03 -0700, Manish Chopra wrote:
> By adding generic API, this patch removes individual
> functions/defines implemented by drivers to find extended
> PCI capabilities.
>
> Signed-off-by: Manish Chopra
> Signed-off-by: Igor Russkikh
LGTM,
Reviewed-by: Gaetan Rivet
--
Gaëtan
On 27/07/20 05:10 +, Manish Chopra wrote:
> > -Original Message-
> > From: Gaëtan Rivet
> > Sent: Monday, July 27, 2020 4:18 AM
> > To: Manish Chopra
> > Cc: jerinjac...@gmail.com; Jerin Jacob Kollanukkaran ;
> > ferruh.yi...@intel.com; dev@dpdk.
On 26/07/20 19:47 +, Manish Chopra wrote:
[...]
> > > diff --git a/lib/librte_pci/rte_pci.h b/lib/librte_pci/rte_pci.h index
> > > a03235da1..fec51e15a 100644
> > > --- a/lib/librte_pci/rte_pci.h
> > > +++ b/lib/librte_pci/rte_pci.h
> > > @@ -22,6 +22,22 @@ extern "C" {
> > > #include
> > >
Hello Manish,
I have just a few nits below,
On 24/07/20 03:38 -0700, Manish Chopra wrote:
> By adding generic API, this patch removes individual
> functions/defines implemented by drivers to find PCI
> extended capability.
"to find extended PCI capabilities" sounds better.
>
> Signed-off-by: M
On 13/07/20 08:13 -0700, Manish Chopra wrote:
> By adding generic API, this patch removes individual
> functions/defines implemented by drivers to find PCI
> extended capability.
>
> Signed-off-by: Manish Chopra
> Signed-off-by: Igor Russkikh
> ---
> drivers/bus/pci/pci_common.c |
On 19/07/20 14:17 +0530, Jerin Jacob wrote:
> On Sun, Jul 19, 2020 at 1:12 AM Manish Chopra wrote:
> >
> > > -Original Message-
> > > From: dev On Behalf Of Manish Chopra
> > > Sent: Friday, July 17, 2020 2:19 AM
> > > To: Gaëtan Rivet ;
t; > wrote:
> > > > >
> > > > > 16/07/2020 13:55, Jerin Jacob:
> > > > > > On Thu, Jul 16, 2020 at 4:57 PM Thomas Monjalon
> > > > > > wrote:
> > > > > > >
> > > > > > > 16/07/2020 12:27,
On 16/07/20 12:08 +0200, Gaëtan Rivet wrote:
> Re-CCing dev@dpdk.org as it was removed from the reply.
>
> On 13/07/20 08:13 -0700, Manish Chopra wrote:
> > This is merely copy of latest linux/pci_regs.h in
> > order to avoid dependency of dpdk on user headers.
> >
&
Re-CCing dev@dpdk.org as it was removed from the reply.
On 13/07/20 08:13 -0700, Manish Chopra wrote:
> This is merely copy of latest linux/pci_regs.h in
> order to avoid dependency of dpdk on user headers.
>
I guess this dependency is an issue on non-linux systems, when you must
use those defin
On 13/07/20 08:13 -0700, Manish Chopra wrote:
> This is merely copy of latest linux/pci_regs.h in
> order to avoid dependency of dpdk on user headers.
>
I guess this dependency is an issue on non-linux systems, when you must
use those defines in a generic implementation. Can you confirm this is
t
On 21/06/20 19:11 +, Parav Pandit wrote:
> Create a mlx5 bus driver framework for invoking drivers of
> multiple classes who have registered with the mlx5_pci bus
> driver.
>
> Validate user class arguments for supported class combinations.
>
> Signed-off-by: Parav Pandit
> ---
> Changelog:
Hi Parav,
On 21/06/20 19:11 +, Parav Pandit wrote:
> Add mlx5 PCI bus which enables multiple mlx5 drivers to bind to single
> pci device.
>
> Signed-off-by: Parav Pandit
> ---
> Changelog:
> v1->v2:
> - Address comments from Thomas and Gaetan
> - Inheriting ret_pci_driver instead of rte_dr
On 25/06/20 10:04 +0200, Maxime Coquelin wrote:
> This patch makes rte_dev_probe() to return the
> rte_device pointer on success and NULL on error
> instead of returning 0 on success and negative
> value on error.
>
> The goal is to avoid that the calling application
> iterates the devices list af
On 18/06/20 10:06 +, Parav Pandit wrote:
>
>
> > From: Gaëtan Rivet
> > Sent: Tuesday, June 16, 2020 3:26 AM
> >
> > On 10/06/20 17:17 +, Parav Pandit wrote:
> > > Enable class driver to match with the mlx5 pci devices.
> > > Migrate mlx5
On 18/06/20 10:03 +, Parav Pandit wrote:
>
> > From: Gaëtan Rivet
> > Sent: Tuesday, June 16, 2020 3:17 AM
> >
> > On 10/06/20 17:17 +, Parav Pandit wrote:
> > > Create a mlx5 bus driver framework for invoking drivers of multiple
> > > clas
On 10/06/20 17:17 +, Parav Pandit wrote:
> Enable class driver to match with the mlx5 pci devices.
> Migrate mlx5 net PMD and vdpa PMD to start using mlx5 common class
> driver.
>
> Signed-off-by: Parav Pandit
> ---
> drivers/bus/Makefile| 3 ++
> drivers/bus/mlx5_pci/mlx5_p
On 10/06/20 17:17 +, Parav Pandit wrote:
> Create a mlx5 bus driver framework for invoking drivers of
> multiple classes who have registered with the mlx5_pci bus
> driver.
>
> Validate user class arguments for supported class combinations.
>
> Signed-off-by: Parav Pandit
> ---
> drivers/bu
On 10/06/20 17:17 +, Parav Pandit wrote:
> Add mlx5 PCI bus which enables multiple mlx5 drivers to bind to single
> pci device.
>
This is a little quick to explain the architecture here.
First it should be clear that this is not, in fact, a bus.
You only define a PCI driver, that will demux
On 10/06/20 17:17 +, Parav Pandit wrote:
> mlx5 PCI Device supports multiple classes of devices such as net, vdpa,
> and/or regex.
> To support these multiple classes, change mlx5_class to a
> bitmap values so that if users asks to enable multiple of them, all
> supported classes can be returne
On 10/06/20 17:17 +, Parav Pandit wrote:
> Currently mlx5_class_get() returns enabled single valid class.
> To support multiple class and to improve readability of code, change it
> to mlx5_class_enabled().
> With this function, each class enablement can be checked, to load class
> specific dri
Hello Parav,
On 10/06/20 17:17 +, Parav Pandit wrote:
> There are several drivers which duplicate bit generation macro.
> Introduce a generic bit macros so that such drivers avoid redefining
> same in multiple drivers.
>
> Signed-off-by: Parav Pandit
> ---
> lib/librte_eal/include/rte_bits.
On 11/06/20 23:37 +0200, Maxime Coquelin wrote:
> This patch makes the vDPA framework to no more
> support only PCI devices, but any devices by relying
> on the generic device name as identifier.
>
> Signed-off-by: Maxime Coquelin
> ---
> drivers/vdpa/ifc/ifcvf_vdpa.c | 6 +-
> drivers
On 11/06/20 23:37 +0200, Maxime Coquelin wrote:
> This patch introduces vDPA device class. It will enable
> application to iterate over the vDPA devices.
>
> Signed-off-by: Maxime Coquelin
> ---
> lib/librte_vhost/vdpa.c | 116 +---
> 1 file changed, 98 insert
On 11/06/20 23:37 +0200, Maxime Coquelin wrote:
> This patches fixes a null pointer derefencing that happens
> when the device string passed to the iterator is NULL. This
> situation can happen when iterating on a class type.
> For example:
>
> RTE_DEV_FOREACH(dev, "class=eth", &dev_iter) {
>
Hello Maxime,
On 11/06/20 23:37 +0200, Maxime Coquelin wrote:
> This series aims to rework the vDPA framework and
> its API to better fit into the DPDK device model
> and also be more easily consumable by applications.
>
> Main changes are creating a device class for vDPA,
> which enables applica
On 11/06/20 17:20 -0700, Stephen Hemminger wrote:
> Use the new terminolgy BLOCKLIST to describe when devices
> are excluded from being used.
>
> Signed-off-by: Stephen Hemminger
In general: in comments using 'blocklisted' does not flow well,
I think using 'blocked' would be better.
--
Gaëtan
On 11/06/20 17:20 -0700, Stephen Hemminger wrote:
> The terms blacklist and whitelist are often seen as reminders
> of the divisions in society. Instead, use more exact terms for
> handling of which devices are used in DPDK.
>
> This patch renames the enum values in the EAL include files.
> As a b
On 24/02/20 13:01 -0800, Stephen Hemminger wrote:
> Simple script to look for drivers and scripts that
> are missing requires SPDX header.
>
> Update the contribution guidelines to indicate that SPDX license
> identfier is required for this project.
>
> Signed-off-by: Stephen Hemminger
> ---
> v
Hi Thomas, Stephen,
On 11/06/20 23:39 +0200, Thomas Monjalon wrote:
> 24/02/2020 22:01, Stephen Hemminger:
> > +tmpfile=$(mktemp)
>
> Please check how other temp files are created in other scripts
> for consitency.
>
> > +git grep -L SPDX-License-Identifier -- \
> > + ':^.git*' ':^.ci/*' '
On 08/06/20 17:53 +0200, Maxime Coquelin wrote:
> In order to simplify the use of rte_dev_probe() and
> rte_dev_remove() by applications, rte_dev_probe() will
> return a reference on the rte_device stating DPDK v20.11.
>
> Signed-off-by: Maxime Coquelin
> ---
> doc/guides/rel_notes/deprecation.r
On 10/06/20 19:08 +0200, Maxime Coquelin wrote:
> Hi Gaëtan,
>
> On 6/10/20 2:06 PM, Gaëtan Rivet wrote:
> > Hello Maxime,
> >
> > On 08/06/20 17:53 +0200, Maxime Coquelin wrote:
> >> This patch makes rte_dev_probe() to return the
> >> rte_device poin
Hello Maxime,
On 08/06/20 17:53 +0200, Maxime Coquelin wrote:
> This patch makes rte_dev_probe() to return the
> rte_device pointer on success and NULL on error
> instead of returning 0 on success and negative
> value on error.
>
> The goal is to avoid that the calling application
> iterates the
Hi,
On 07/06/20 10:01 -0700, Stephen Hemminger wrote:
> This patch renames the enum values in the EAL include files.
> As a backward compatiable temporary migration tool, define
> a replacement mapping for old values.
>
> The old names relating to blacklist and whitelist are replaced
> by blockli
On 05/06/20 12:28 +0100, Bruce Richardson wrote:
> On Fri, Jun 05, 2020 at 12:43:00PM +0200, Gaëtan Rivet wrote:
> > On 04/06/20 18:04 -0700, Stephen Hemminger wrote:
> > > I have a full patch that replaces the master/slave lcore
> > > naming (widely used in DPDK) with
On 04/06/20 18:04 -0700, Stephen Hemminger wrote:
> I have a full patch that replaces the master/slave lcore
> naming (widely used in DPDK) with a better primary/secondary naming.
>
> For now this is just a trial balloon to see what the impact would
> look like. The change mostly automated so like
On 27/05/20 18:30 +0300, Andrew Rybchenko wrote:
> On 5/27/20 6:07 PM, Gaëtan Rivet wrote:
> > On 27/05/20 15:34 +0100, Andrew Rybchenko wrote:
> >> From: Ian Dolzhansky
> >>
> >> Failsafe driver has been indicating zero for RSS redirection table size
>
On 27/05/20 15:34 +0100, Andrew Rybchenko wrote:
> From: Ian Dolzhansky
>
> Failsafe driver has been indicating zero for RSS redirection table size
> after device info reporting had been reworked. Report proper value.
>
> Fixes: 4586be3743d4 ("net/failsafe: fix reported device info")
> Cc: Steph
On 27/05/20 09:28 +, Jerin Kollanukkaran wrote:
> I think, original discussion[1] on this topic got lost in GitHub vs current
> workflow.
>
>
> I would like to propose GitHub "CODEOWNERS"[2] _LIKE_ scheme for DPDK
> workflow.
>
> Current scheme:
> - When we submit a patch to ml, someone(Tr
On 12/05/20 11:16 -0700, Stephen Hemminger wrote:
>
>
> On Tue, May 12, 2020 at 3:30 pm, Darek Stojaczyk
> wrote:
> > The parsing code was bailing on domains greater than UINT16_MAX,
> > but domain numbers like that are still valid and present on some
> > systems.
> > One example is Intel VMD (V
On 06/05/20 14:43 +0100, Ferruh Yigit wrote:
> On 5/6/2020 1:33 PM, Gaëtan Rivet wrote:
> > On 06/05/20 12:48 +0100, Ferruh Yigit wrote:
> >> On 5/5/2020 8:10 PM, Gaetan Rivet wrote:
> >>> When a net_ring device is allocated, its device pointer i
On 06/05/20 14:43 +0200, David Marchand wrote:
> Internal symbols do not need the rte_ prefix.
> Some symbols do not need to be exposed in the private header and have
> been made static.
>
> Fixes: c752998b5e2e ("pci: introduce library and driver")
>
> Signed-off-by: David Marchand
For this pat
Hello David,
On 06/05/20 14:43 +0200, David Marchand wrote:
> rte_pci_probe() is private to the PCI bus.
> Clean the remaining references in the documentation and comments.
>
> Fixes: c752998b5e2e ("pci: introduce library and driver")
> Cc: sta...@dpdk.org
>
> Signed-off-by: David Marchand
> --
On 06/05/20 12:48 +0100, Ferruh Yigit wrote:
> On 5/5/2020 8:10 PM, Gaetan Rivet wrote:
> > When a net_ring device is allocated, its device pointer is not set
> > before calling rte_eth_dev_probing_finish, which is incorrect.
> >
> > The following:
> > commit: 96cb19521147 ("net/ring: use EAL AP
On 05/05/20 09:14 +, Ali Alnubani wrote:
> > -Original Message-
> > From: Gaëtan Rivet
> > Sent: Monday, May 4, 2020 7:22 PM
> > To: Ali Alnubani
> > Cc: Ferruh Yigit ; wangyunjian
> > ; dev@dpdk.org; jerry.lili...@huawei.com;
> > xu
Hello Jonatan,
On 27/04/20 14:49 +0200, Jonatan Langlet wrote:
> Hi group,
>
> We are building a setup with DPDK bound to VF ports of a Netronome Agilio
> CX 2x40 (NFP4000) SmartNIC.
> Netronome does some P4 processing of packets, and forwards through SR-IOV
> to host where dpdk will continue pro
On 03/05/20 11:33 +, Ali Alnubani wrote:
> Hi,
>
> > -Original Message-
> > From: dev On Behalf Of Ferruh Yigit
> > Sent: Monday, April 27, 2020 7:56 PM
> > To: Gaëtan Rivet ; wangyunjian
> >
> > Cc: dev@dpdk.org; jerry.lili...@huawei.com
On 02/05/20 13:12 +0530, Sunil Kumar Kori wrote:
> rte_bus_scan API scans all the available PCI devices irrespective of white
> or black listing parameters then further devices are probed based on white
> or black listing parameters. So unnecessary CPU cycles are wasted during
> rte_pci_scan.
>
>
Hello Sunil,
It's pretty close, thanks. Unfortunately, I just have a few nits
remaining.
On 01/05/20 17:09 +0530, Sunil Kumar Kori wrote:
> rte_bus_scan API scans all the available PCI devices irrespective of white
> or black listing parameters then further devices are probed based on white
> or
Hello Sunil,
As it seems that this patch does not overly alarm people using the PCI
bus, I have a few comments on this version. Sending those a little
earlier will allow you to change as needed before proceeding with your
tests.
On 20/04/20 12:25 +0530, Sunil Kumar Kori wrote:
> rte_bus_scan API
On 27/04/20 18:44 +0800, wangyunjian wrote:
> From: Yunjian Wang
>
> Zero is a valid fd. The fd won't be closed thus leading fd leak,
> when it is zero.
>
> Fixes: f234e5bd996d ("net/failsafe: register slaves Rx interrupts")
> Fixes: 9e0360aebf23 ("net/failsafe: register as Rx interrupt mode")
>
On 22/04/20 06:17 +, Sunil Kumar Kori wrote:
> >-Original Message-
> >From: Gaëtan Rivet
> >Sent: Tuesday, April 21, 2020 8:48 PM
> >To: Sunil Kumar Kori
> >Cc: step...@networkplumber.org; david.march...@redhat.com; Jerin Jacob
> >Kollanukkaran
On 20/04/20 12:25 +0530, Sunil Kumar Kori wrote:
> rte_bus_scan API scans all the available PCI devices irrespective of white
> or black listing parameters then further devices are probed based on white
> or black listing parameters. So unnecessary CPU cycles are wasted during
> rte_pci_scan.
>
>
1 - 100 of 617 matches
Mail list logo
