macro is based on Jan Viktorin's original patch but also checks the
> > > > type of the passed pointer against the type of the member.
> > > >
> > > > Signed-off-by: Jan Viktorin
> > > > Signed-off-by: Shreyansh Jain
> > > > [jblunck a
On Fri, 4 Nov 2016 15:16:42 +0530
Jianbo Liu wrote:
> close the file descriptor after finish using it.
s/close/Close/
>
> Fixes: b94e5c94 (eal/arm: add CPU flags for ARMv7)
> Fixes: 97523f82 (eal/arm: add CPU flags for ARMv8)
>
> Signed-off-by: Jianbo Liu
Acked-by: Jan Viktorin
On Fri, 4 Nov 2016 15:16:43 +0530
Jianbo Liu wrote:
> close the file descriptor after finish using it.
s/close/Close/
Please include my ack (below).
Jan
>
> Fixes: 9ae15538 (eal/ppc: cpu flag checks for IBM Power)
>
> Signed-off-by: Jianbo Liu
Acked-by: Jan Viktorin
On Mon, 24 Oct 2016 17:29:25 +0530
Shreyansh Jain wrote:
> From: Jan Viktorin
>
> Define initial structures and functions for the SoC infrastructure.
> This patch supports only a very minimal functions for now.
> More features will be added in the following commits.
>
>
On Mon, 24 Oct 2016 17:29:20 +0530
Shreyansh Jain wrote:
> From: Jan Viktorin
>
> Signed-off-by: Jan Viktorin
> Signed-off-by: Shreyansh Jain
I think, there is no reason to prevent merging this. Feel free to add:
Acked-by: Jan Viktorin
_INSERT_TAIL(_driver_list, driver, next);
> >> }
> >
> > I am not in favor of a forced default. What if user never intended it - it
> > would lead to wrong scan being used and only intimation which can provided
> > to user is a log.
> > Selecting such funct
On Sat, 15 Oct 2016 19:15:02 +0530
Shreyansh Jain wrote:
> From: Jan Viktorin
>
> Default implementation which scans the sysfs platform devices hierarchy.
> For each device, extract the ueven and convert into rte_soc_device.
>
> The information populated can then be used
> +This method can not be used in production systems as this may alter PMU
> > +state used by standard Linux user space tool like perf.
>
> More details please?
>
--
Jan Viktorin E-mail: Viktorin at RehiveTech.com
System Architect Web:www.RehiveTech.com
RehiveTech
Brno, Czech Republic
bly you are talking about (Patch 3/4 and 4/4).
> Is my understanding correct?
>
> So, movement to just Linux area is not enough?
> I am not well versed with BSD way of doing something similar so if
> someone can point it out, I can integrate that. (I will investigate it
> at my end as
On Sun, 18 Sep 2016 09:41:55 +
Hemant Agrawal wrote:
> > -Original Message-
> > From: Jan Viktorin [mailto:viktorin at rehivetech.com]
>
[...]
> > > And for each platform/product
> > >
> > > > I agree, that this can
On Sun, 18 Sep 2016 16:56:54 +0800
Jianbo Liu wrote:
> On 18 September 2016 at 15:22, Jan Viktorin
> wrote:
> > On Sun, 18 Sep 2016 13:58:50 +0800
> > Jianbo Liu wrote:
> >
> >> On 9 September 2016 at 16:43, Shreyansh Jain
erwise, such system would introduce security
issues.
>
> I think it can be done in devinit, not in scan function. devinit can
> be different for each driver.
+1
>
> >= PCI based PMDs rely on EAL's capability to detect devices. This
> >proposal puts the on
al_soc_probe().
>
> Patch also adds test case for scan and probe.
>
> Signed-off-by: Jan Viktorin
> Signed-off-by: Shreyansh Jain
> Signed-off-by: Hemant Agrawal
> ---
> app/test/test_soc.c | 138 ++-
> lib/librte_eal/bsdapp/e
On Fri, 16 Sep 2016 09:59:40 +0530
Shreyansh Jain wrote:
> From: David Marchand
>
> This information is not used and just adds noise.
>
> Signed-off-by: David Marchand
> Signed-off-by: Shreyansh Jain
Reviewed-by: Jan Viktorin
5177 ("eal: make vdev init path generic for both virtual and
> pci devices")
>
> Signed-off-by: David Marchand
> Signed-off-by: Shreyansh Jain
Reviewed-by: Jan Viktorin
2016 14:13:48 +0530
Shreyansh Jain wrote:
> This option has the same meaning for the SoC infra as the --no-pci
> for the PCI infra.
>
> Signed-off-by: Jan Viktorin
> Signed-off-by: Shreyansh Jain
> Signed-off-by: Hemant Agrawal
> ---
> lib/librte_eal/common/
On Thu, 15 Sep 2016 14:00:25 +0100
"Hunt, David" wrote:
> > new file mode 100644
> > index 000..56135ed
> > --- /dev/null
> > +++ b/lib/librte_eal/common/eal_common_soc.c
> > @@ -0,0 +1,56 @@
> > +/*-
> > + * BSD LICENSE
> > + *
> > + * Copyright(c) 2016 RehiveTech. All rights reserved.
ff2)
>
> Background:
> ===
>
> It includes two different patch-sets floated on ML earlier:
> * Original patch series is from David Marchand [1], [2].
> `- This focused mainly on PCI (PDEV) part
> `- v7 of this was posted by me [8] in August/2016
> * Patc
he cycle count register is not
> > disabled (PMCNTENCLR_EL0). It shall be better to disable the cycle count
> > register too at module exit.
>
> OK
+1
I've got a private kernel driver enabling and disabling (hopefully) properly
this for ARMv7. If we'd like to merge it, I'd like to have a single module
or at least single module with 2 implementations...
I can post it if it would be helpful.
Regards
Jan
>
> >
> > > + *
> > > + */
> > > +static inline uint64_t
> > > +rte_rdtsc(void)
> > > +{
> > > + uint64_t tsc;
> > > +
> > > + asm volatile("mrs %0, pmccntr_el0" : "=r"(tsc));
> > > + return tsc;
> > > +}
> > > +#endif
> > >
> > > static inline uint64_t
> > > rte_rdtsc_precise(void)
> > > --
> > > 2.5.5
> >
> > Do you also plan to support performance monitor event counters?
>
> No. This patch was inspired by armv7 PMU scheme and its part of DPDK.
> The sole reason to add this support to catch any performance regression
> through app/test application.Other than that, I think cntvct_el0 based
> existing scheme is good enough for all the use cases.
>
> >
> > Regards,
> > Nipun
> >
--
Jan Viktorin E-mail: Viktorin at RehiveTech.com
System Architect Web:www.RehiveTech.com
RehiveTech
Brno, Czech Republic
me support which will help a lot for my
> > development .
>
> Please check the work of Jan Viktorin:
> http://dpdk.org/dev/patchwork/project/dpdk/list/?submitter=292=*
> Some review would be welcome :) Thanks
The patchset has very low number of reviews. If you
ure to understand the use case.
> > This is a fake sysfs, we cannot change the names.
>
> In other words, Windows is not supported, neither for runtime
> nor for development.
> For information, which filesystem do not support ':'?
>
> If someone wants to add this supp
Thank you. Hope to find some time this week to do my part.
Jan
On Mon, 1 Aug 2016 16:15:15 +0530
Shreyansh Jain wrote:
> * Original patch series is from David Marchand [1], [2].
> * Link with patch series [4] from Jan Viktorin for a more complete picture
> of proposed EAL device
On Thu, 28 Jul 2016 15:06:10 +0530
Shreyansh Jain wrote:
> Hi Jan,
>
> On Friday 15 July 2016 04:18 PM, Shreyansh jain wrote:
> > On Thursday 14 July 2016 09:27 PM, Jan Viktorin wrote:
[...]
> >>>>> (drv).name = RTE_STR(nm);
> >>&g
K objects (ring/mempool) allocated by EAL
>
> As nobody seems interested, it is time to remove this code which
> makes EAL improvements harder.
>
> Signed-off-by: Thomas Monjalon
> Acked-by: David Marchand
> Acked-by: Maxime Coquelin
Acked-by: Jan Viktorin
will be
> removed in the next release (v16.11).
>
> Signed-off-by: Yuanhan Liu
> Acked-by: Ciara Loftus
> Acked-by: Thomas Monjalon
> Acked-by: Rich Lane
Acked-by: Jan Viktorin
ibrary filename as every other libraries.
>
> Signed-off-by: Thomas Monjalon
>
Acked-by: Jan Viktorin
On Fri, 15 Jul 2016 15:19:14 +0200
Thomas Monjalon wrote:
> 2016-07-08 21:09, Jan Viktorin:
> > Hello,
> >
> > based on the discussions with Shreyansh, I propose a patchset with
> > the important EAL changes. It is incomplete and I suppose to extend
&g
On Fri, 15 Jul 2016 11:56:38 +0200
Thomas Monjalon wrote:
> 2016-07-15 15:09, Shreyansh jain:
> > On Thursday 14 July 2016 10:25 PM, Jan Viktorin wrote:
> > > What is meant by "resources" here?
> >
> > This has historic context (from earlier version
On Fri, 15 Jul 2016 16:06:25 +0530
Shreyansh jain wrote:
> On Thursday 14 July 2016 10:21 PM, Jan Viktorin wrote:
> > On Tue, 12 Jul 2016 11:31:21 +0530
> > Shreyansh Jain wrote:
> >
> >> Remove bus logic from ethdev hotplug by using eal for this.
>
On Fri, 15 Jul 2016 15:09:58 +0530
Shreyansh jain wrote:
> On Thursday 14 July 2016 10:25 PM, Jan Viktorin wrote:
> > On Tue, 12 Jul 2016 11:31:17 +0530
> > Shreyansh Jain wrote:
> >
> >> eal is a better place than crypto / ethdev for naming resources.
Hello Damjan,
thank you for the patch. It makes sense to me.
Next time, please CC the appropriate maintainers.
(See the MAINTAINERS file in the root of the DPDK source tree.)
In the subject after "spinlock:" you should start with a lower case
letter, so "move constructor..."
On Thu, 14 Jul
@ -417,6 +417,19 @@ pci_scan_one(const char *dirname, uint16_t domain,
> uint8_t bus,
> return 0;
> }
>
> +int
> +pci_update_device(const struct rte_pci_addr *addr)
> +{
> + char filename[PATH_MAX];
> +
> + snprintf(filename, sizeof(filename), "%s/" PCI_PRI_FMT,
> + SYSFS_PCI_DEVICES, addr->domain, addr->bus, addr->devid,
Use pci_get_sysfs_path here.
> + addr->function);
> +
> + return pci_scan_one(filename, addr->domain, addr->bus, addr->devid,
> + addr->function);
> +}
> +
> /*
> * split up a pci address into its constituent parts.
> */
--
Jan ViktorinE-mail: Viktorin at RehiveTech.com
System ArchitectWeb:www.RehiveTech.com
RehiveTech
Brno, Czech Republic
On Tue, 12 Jul 2016 11:31:17 +0530
Shreyansh Jain wrote:
> eal is a better place than crypto / ethdev for naming resources.
s/for naming/to name/
What is meant by "resources" here?
> Add a helper in eal and make use of it in crypto / ethdev.
>
> Signed-off-by: David Marchand
>
On Tue, 12 Jul 2016 11:31:21 +0530
Shreyansh Jain wrote:
> Remove bus logic from ethdev hotplug by using eal for this.
>
> Current api is preserved:
> - the last port that has been created is tracked to return it to the
> application when attaching,
> - the internal device name is reused when
On Tue, 12 Jul 2016 11:31:20 +0530
Shreyansh Jain wrote:
> Hotplug which deals with resources should come from the layer that already
> handles them, i.e. EAL.
>
> For both attach and detach operations, 'name' is used to select the bus
> that will handle the request.
>
> Signed-off-by: David
On Tue, 12 Jul 2016 11:31:22 +0530
Shreyansh Jain wrote:
> Now that hotplug has been moved to eal, there is no reason to keep the device
> type in this layer.
>
> Signed-off-by: David Marchand
> Signed-off-by: Shreyansh Jain
> ---
> app/test/virtual_pmd.c| 2 +-
>
On Thu, 14 Jul 2016 10:57:55 +0530
Shreyansh jain wrote:
> Hi Jan,
>
> On Wednesday 13 July 2016 11:04 PM, Jan Viktorin wrote:
> > On Wed, 13 Jul 2016 11:20:43 +0200
> > Jan Viktorin wrote:
> >
> >> Hello Shreyansh,
> >>
> >> On Tue,
On Wed, 13 Jul 2016 11:27:18 +0200
Maxime Coquelin wrote:
> Hi Jan,
>
> On 07/13/2016 11:24 AM, Jan Viktorin wrote:
> > GCC 6 is complaining and seems to be correct here.
> >
> > virtio_user_ethdev.c:345:2: error:
> > this ?if? clause does not guard..
On Wed, 13 Jul 2016 11:27:18 +0200
Maxime Coquelin wrote:
> Hi Jan,
>
> On 07/13/2016 11:24 AM, Jan Viktorin wrote:
> > GCC 6 is complaining and seems to be correct here.
> >
> > virtio_user_ethdev.c:345:2: error:
> > this ?if? clause does not guard..
On Wed, 13 Jul 2016 11:20:43 +0200
Jan Viktorin wrote:
> Hello Shreyansh,
>
> On Tue, 12 Jul 2016 11:31:10 +0530
> Shreyansh Jain wrote:
>
> > Introduce a RTE_INIT macro used to mark an init function as a constructor.
> > Current eal macros have been converted
, but the latter is misleadingly indented
as if it is guarded by the ?if?
if (ret < 0) {
Fixes: 404bd6bfe360 ("net/virtio-user: fix return value not checked")
Signed-off-by: Jan Viktorin
---
drivers/net/virtio/virtio_user_ethdev.c | 4 ++--
1 file changed, 2 insertions(+), 2 delet
i drivers.
>
> Suggested-by: Jan Viktorin
> Signed-off-by: David Marchand
> Signed-off-by: Shreyansh Jain
> ---
[...]
> +#define RTE_INIT(func) \
> +static void __attribute__((constructor, used)) func(void)
> +
> #ifdef __cplusplus
> }
> #endif
> diff --git a/lib
On Tue, 12 Jul 2016 14:15:17 +0530
Shreyansh jain wrote:
> Hi Jan,
>
> On Monday 04 July 2016 08:06 PM, Jan Viktorin wrote:
> > On Mon, 4 Jul 2016 19:57:18 +0530
> > Shreyansh jain wrote:
> >
> > [...]
> >
> >>>>> @@ -1431,
On Mon, 11 Jul 2016 18:59:48 +0530
Shreyansh jain wrote:
> Hi Jan,
>
> Some comments.
>
> On Saturday 09 July 2016 12:39 AM, Jan Viktorin wrote:
> > Move all PMD_VDEV-specific code into a separate module and header
> > file to not polute the generic code a
Signed-off-by: Jan Viktorin
---
lib/librte_eal/linuxapp/eal/eal_pci.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci.c
b/lib/librte_eal/linuxapp/eal/eal_pci.c
index 6f1a28a..ab08a16 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci.c
+++ b/lib
Signed-off-by: Jan Viktorin
---
app/test/virtual_pmd.c | 4 ++--
drivers/net/fm10k/fm10k_ethdev.c| 6 +++---
drivers/net/virtio/virtio_pci.c | 2 +-
lib/librte_cryptodev/rte_cryptodev.c| 2 +-
lib/librte_eal/common/eal_common_pci.c | 14
Signed-off-by: Jan Viktorin
---
lib/librte_eal/common/eal_common_dev.c | 13 +
lib/librte_eal/common/include/rte_dev.h | 31 +++
2 files changed, 44 insertions(+)
diff --git a/lib/librte_eal/common/eal_common_dev.c
b/lib/librte_eal/common
To register both vdev and pci drivers into the list of all rte_driver,
we have to call rte_eal_driver_register explicitly.
Signed-off-by: Jan Viktorin
---
lib/librte_eal/common/eal_common_pci.c | 2 ++
lib/librte_eal/common/eal_common_vdev.c | 2 ++
2 files changed, 4 insertions(+)
diff --git
Signed-off-by: Jan Viktorin
---
app/test/test_pci.c | 10 +++---
app/test/virtual_pmd.c | 2 +-
drivers/crypto/qat/rte_qat_cryptodev.c | 4 +++-
drivers/net/bnx2x/bnx2x_ethdev.c| 8 ++--
drivers/net/cxgbe/cxgbe_ethdev.c| 4
There is no need to have a custom memory resource representation for
each infrastructure (PCI, ...) as it would always have the same members.
Signed-off-by: Jan Viktorin
---
drivers/net/szedata2/rte_eth_szedata2.c | 4 ++--
lib/librte_eal/common/include/rte_dev.h | 9 +
lib
Signed-off-by: Jan Viktorin
---
lib/librte_eal/common/include/rte_common.h | 16
1 file changed, 16 insertions(+)
diff --git a/lib/librte_eal/common/include/rte_common.h
b/lib/librte_eal/common/include/rte_common.h
index 332f2a4..a9b6792 100644
--- a/lib/librte_eal/common
There is no need to determine a PMD type any more. The PMD_VDEV devices
has its own list of drivers. And all PMD_PDEV are PCI devices using
a different way of registering themselfs.
Signed-off-by: Jan Viktorin
---
drivers/crypto/aesni_gcm/aesni_gcm_pmd.c | 1 -
drivers/crypto/aesni_mb
All PMD_VDEV drivers can now use rte_vdev_driver instead of the
rte_driver (which is embedded in the rte_vdev_driver).
Signed-off-by: Jan Viktorin
---
drivers/crypto/aesni_gcm/aesni_gcm_pmd.c | 16 +---
drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 16 +---
drivers
There is no way how to call an init on a PMD_PDEV driver as those
drivers are all PCI drivers and they do not register any rte_driver
with EAL. We can drop the loop over PMD_PDEV drivers entirely.
Signed-off-by: Jan Viktorin
---
lib/librte_eal/common/eal_common_dev.c | 8
1 file
All devices in the rte_eal_vdev_init/uninit are always virtual devices.
Signed-off-by: Jan Viktorin
---
lib/librte_eal/common/eal_common_vdev.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/lib/librte_eal/common/eal_common_vdev.c
b/lib/librte_eal/common/eal_common_vdev.c
index
00/17] Prepare for rte_device / rte_driver
Thanks anybody for some quick review and notes.
Regards
Jan
--
Jan Viktorin (15):
eal: extract vdev infra
eal: no need to test for PMD_VDEV anymore
eal: do not call init for PMD_PDEV drivers
drivers: convert PMD_VDEV drivers to use
Hi Adrien,
I am the only one in CC and only in the 00/11 patch. Is it a mistake? Or what
is the purpose?
Regards?
Jan?Viktorin
RehiveTech
Sent?from?a?mobile?device
? P?vodn? zpr?va ?
Od: Adrien Mazarguil
Odesl?no: ?ter?, 5. ?ervence 2016 12:45
Komu: dev at dpdk.org
Kopie: Jan Viktorin
P?edm?t
Hello Shreyansh,
?
> On Monday 04 July 2016 08:06 PM, Jan Viktorin wrote:
>> On Mon, 4 Jul 2016 19:57:18 +0530
>> Shreyansh jain wrote:
>>
>> [...]
>>
>>>>>> @@ -1431,7 +1524,7 @@ >rte_eth_dev_info_get(uint8
We can now just OR the vfio_enabled sequentially and so adding new VFIO
subsystems (vfio_platform) is possible.
Signed-off-by: Jan Viktorin
---
lib/librte_eal/linuxapp/eal/eal.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal.c
b
The VFIO does not depend on the PCI anymore so it can be initialized out of
the PCI subsystem.
Signed-off-by: Jan Viktorin
---
lib/librte_eal/linuxapp/eal/eal.c | 31 ++
lib/librte_eal/linuxapp/eal/eal_pci.c | 17 +---
lib/librte_eal
The module eal_pci_vfio_mp_sync is quite generic so it shouldn't contain the
"pci" string in its name. The internal functions don't need the pci_* prefix.
Signed-off-by: Jan Viktorin
---
lib/librte_eal/linuxapp/eal/Makefile | 4 ++--
lib/librte_eal/li
There is no more reason to expose those definitions as nobody uses them.
Signed-off-by: Jan Viktorin
---
lib/librte_eal/linuxapp/eal/eal_vfio.c | 15 +--
lib/librte_eal/linuxapp/eal/eal_vfio.h | 11 ---
2 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/lib
Signed-off-by: Jan Viktorin
Suggested-by: Anatoly Burakov
Acked-by: John McNamara
---
lib/librte_eal/linuxapp/eal/eal_vfio.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal_vfio.h
b/lib/librte_eal/linuxapp/eal/eal_vfio.h
index d4532a5
- pci_* specialization preserved as a wrapper
* clear_current_group
- private function, just moved
To stop GCC complaining about "defined but not used", the private
function pci_vfio_get_group_no has been removed entirely.
Signed-off-by: Jan Viktorin
---
lib/librte_eal/linuxapp/eal/eal_
The setup logic access the global vfio_cfg variable that will be moved in the
following commits. We need to separate all accesses to this variable to a
general code.
Signed-off-by: Jan Viktorin
---
lib/librte_eal/linuxapp/eal/eal_pci_vfio.c | 85 +-
1 file changed
.
Signed-off-by: Jan Viktorin
---
lib/librte_eal/linuxapp/eal/eal_pci_vfio.c | 38 +-
lib/librte_eal/linuxapp/eal/eal_vfio.c | 43 ++
lib/librte_eal/linuxapp/eal/eal_vfio.h | 7 +
3 files changed, 51 insertions(+), 37 deletions(-)
diff
The pci_vfio_get_container_fd is not PCI-specific. Move the implementation to
the eal_vfio.c as vfio_get_container_fd. No other code seems to call this
function.
Signed-off-by: Jan Viktorin
---
lib/librte_eal/linuxapp/eal/eal_pci_init.h | 1 -
lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
The constants are not PCI-specific. Move them into the eal_vfio.h.
Signed-off-by: Jan Viktorin
---
lib/librte_eal/linuxapp/eal/eal_pci_init.h | 7 ---
lib/librte_eal/linuxapp/eal/eal_vfio.h | 6 ++
2 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/lib/librte_eal
The pci_vfio_has_supported_extensions is not PCI-specific and it is a private
function of the eal_pci_vfio.c. We just rename the function and make it
available even for non-PCI devices.
Signed-off-by: Jan Viktorin
---
lib/librte_eal/linuxapp/eal/eal_pci_vfio.c | 36
The pci_vfio_set_iommu_type is not PCI-specific and it is a private function
of the eal_pci_vfio.c. We just rename the function and make it available even
for non-PCI devices.
Signed-off-by: Jan Viktorin
---
lib/librte_eal/linuxapp/eal/eal_pci_vfio.c | 25 +
lib
We make the iommu_types public temporarily here until the depending stuff is
refactored. The iommu_types and dma_map functions will be changed to be private
inside the eal_vfio module later.
Signed-off-by: Jan Viktorin
---
lib/librte_eal/linuxapp/eal/Makefile | 1 +
lib/librte_eal
Signed-off-by: Jan Viktorin
---
lib/librte_eal/linuxapp/eal/eal_pci_vfio.c | 7 ---
lib/librte_eal/linuxapp/eal/eal_vfio.h | 7 +++
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
The common VFIO definitions should be separated from the PCI-specific parts.
Signed-off-by: Jan Viktorin
---
lib/librte_eal/linuxapp/eal/eal_pci_init.h | 28
lib/librte_eal/linuxapp/eal/eal_vfio.h | 28
2 files changed, 28 insertions
Signed-off-by: Jan Viktorin
---
lib/librte_eal/linuxapp/eal/eal_pci_vfio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
index f91b924..8b7d53f 100644
--- a/lib/librte_eal/linuxapp/eal
Hello,
I've rebased the v2 of this patch set on top of the current master.
It builds well for my setup (both VFIO enabled and disabled).
Regards
Jan
v3:
* 0012: Acked-by: John McNamara
Jan Viktorin (16):
vfio: fix include of eal_private.h to be local
vfio: move VFIO-specific stuff
On Mon, 4 Jul 2016 10:22:08 +
"Burakov, Anatoly" wrote:
[...]
> There's no patch cover letter so I'll reply to the first patch. I've done
> some cursory testing with a NIC, nothing seems to be broken and the code
> looks OK to me. So, once this patchset is rebased on latest master
On Mon, 4 Jul 2016 19:57:18 +0530
Shreyansh jain wrote:
[...]
> >>> @@ -1431,7 +1524,7 @@ rte_eth_dev_info_get(uint8_t port_id, struct
> >>> rte_eth_dev_info *dev_info)
> >>>
> >>> RTE_FUNC_PTR_OR_RET(*dev->dev_ops->dev_infos_get);
> >>> (*dev->dev_ops->dev_infos_get)(dev, dev_info);
>
Hello Shreyansh,
On Thu, 16 Jun 2016 11:47:29 +
Shreyansh Jain wrote:
> Sorry, didn't notice this email earlier...
> Comments inline
>
> > -Original Message-----
> > From: Jan Viktorin [mailto:viktorin at rehivetech.com]
> > Sent: Wednesday, June 15, 2016 3:2
On Wed, 29 Jun 2016 15:12:07 +0530
Shreyansh jain wrote:
> Hi Jan,
>
> On Friday 06 May 2016 07:18 PM, Jan Viktorin wrote:
> > Signed-off-by: Jan Viktorin
> > ---
> > lib/librte_ether/rte_ethdev.c | 127
> > +-
> &g
On Mon, 4 Jul 2016 10:22:08 +
"Burakov, Anatoly" wrote:
> > -Original Message-----
> > From: Jan Viktorin [mailto:viktorin at rehivetech.com]
> > Sent: Monday, June 13, 2016 2:02 PM
> > To: dev at dpdk.org
> > Cc: Jan Viktorin ; Burakov, Anatoly
On Fri, 24 Jun 2016 13:24:56 +0200
Thomas Monjalon wrote:
> 2016-06-24 13:20, Jan Viktorin:
> > thanks for the patchset. I am sorry, I didn't have any time for DPDK this
> > week
> > and didn't test it before applying. The current master produces the
> > follow
On Fri, 24 Jun 2016 04:55:39 +
"Wiles, Keith" wrote:
> On 6/23/16, 11:22 PM, "dev on behalf of Thomas Monjalon" dpdk.org on behalf of thomas.monjalon at 6wind.com> wrote:
>
> >> David Hunt (2):
> >> mempool: support mempool handler operations
> >> app/test: test mempool handler
> >>
the default configuration for this architecture
> would contain a different value for RTE_MBUF_DEFAULT_MEMPOOL_OPS.
>
> Signed-off-by: Olivier Matz
> Signed-off-by: David Hunt
> Acked-by: Shreyansh Jain
> Acked-by: Olivier Matz
> ---
Reviewed-by: Jan Viktorin
On Fri, 17 Jun 2016 14:53:37 +0100
David Hunt wrote:
> Create a minimal custom mempool handler and check that it
> passes basic mempool autotests.
>
> Signed-off-by: Olivier Matz
> Signed-off-by: David Hunt
> Acked-by: Shreyansh Jain
> Acked-by: Olivier Matz
> ---
Reviewed-by: Jan Viktorin
Hi David,
still few nits... Do you like the upstreaming process? :) I hope finish this
patchset soon. The major issues seem to be OK.
[...]
> +
> +/**
> + * @internal Get the mempool ops struct from its index.
> + *
> + * @param ops_index
> + * The index of the ops struct in the ops struct
dev/stdin by a temporary file.
Signed-off-by: Jan Viktorin
Reported-by: Thomas Monjalon
---
app/test/Makefile | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/app/test/Makefile b/app/test/Makefile
index 5e3ebdc..36ff089 100644
--- a/app/test/Makefile
+++ b/app/test/Makef
On Thu, 16 Jun 2016 08:42:29 +
Shreyansh Jain wrote:
> Hi,
>
> > -Original Message-
> > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > Sent: Thursday, June 16, 2016 1:04 PM
> > To: Shreyansh Jain
> > Cc: David Marchand ; viktorin at
> > rehivetech.com;
> > dev at
On Thu, 16 Jun 2016 11:19:59 +0200
Thomas Monjalon wrote:
> 2016-06-16 10:23, Jan Viktorin:
> > I think, we should consider to move it to somebody else. I would work on
> > it, however, I don't see all the tasks that are to be done. That's why I
> > was waiting to
patchset).
What more?
Jan?Viktorin
RehiveTech
Sent?from?a?mobile?device
? P?vodn? zpr?va ?
Od: Thomas Monjalon
Odesl?no: ?tvrtek, 16. ?ervna 2016 9:34
Komu: Shreyansh Jain
Kopie: David Marchand; viktorin at rehivetech.com; dev at dpdk.org; Iremonger,
Bernard
P?edm?t: Re: [dpdk-dev] [PATCH v2 00/17
gt;>
> >>>
> >>> On 15/6/2016 1:03 PM, Olivier MATZ wrote:
> >>>> Hi,
> >>>>
> >>>> On 06/15/2016 01:47 PM, Hunt, David wrote:
> >>>>>
> >>>>>
> >>>>> On 15/6/2016 11:13 AM, Ja
On Wed, 15 Jun 2016 11:29:51 +0100
"Hunt, David" wrote:
> On 15/6/2016 11:14 AM, Jan Viktorin wrote:
> > On Wed, 15 Jun 2016 08:47:02 +0100
> > David Hunt wrote:
> >
>
> [...]
>
> >
> >> +
> >> +/** Array of regi
On Wed, 15 Jun 2016 08:47:02 +0100
David Hunt wrote:
> Until now, the objects stored in a mempool were internally stored in a
> ring. This patch introduces the possibility to register external handlers
> replacing the ring.
>
> The default behavior remains unchanged, but calling the new
enqueue,
> .dequeue = common_ring_mc_dequeue,
> .get_count = common_ring_get_count,
> .free = common_ring_free,
> };
>
> And then the following macro will register the ops in the array of ops
> structures
>
> REGISTER_MEMPOOL_OPS(ops_mp_mc);
>
> For an example of API usage, please see app/test/test_mempool.c, which
> implements a rudimentary "custom_handler" mempool manager using simple mallocs
> for each mempool object. This file also contains the callbacks and self
> registration for the new handler.
>
> David Hunt (2):
> mempool: support external mempool operations
> mbuf: make default mempool ops configurable at build
>
> Olivier Matz (1):
> app/test: test external mempool manager
>
>
--
Jan Viktorin E-mail: Viktorin at RehiveTech.com
System Architect Web:www.RehiveTech.com
RehiveTech
Brno, Czech Republic
On Tue, 14 Jun 2016 04:30:57 +
Shreyansh Jain wrote:
> Hi Jan,
>
> > -Original Message-
> > From: Jan Viktorin [mailto:viktorin at rehivetech.com]
> > Sent: Monday, June 13, 2016 7:55 PM
> > To: Shreyansh Jain
> > Cc: dev at dpdk.org; D
On Tue, 14 Jun 2016 16:08:42 +0200
Thomas Monjalon wrote:
> 2016-06-14 15:46, Jan Viktorin:
> > There are 2 new fake devices for testing PCI infra. All the fake devices
s/All the fake/All 3 fake/
> > are now identified by non-existing vendor and device IDs so there is no
On Wed, 15 Jun 2016 05:57:33 +
Shreyansh Jain wrote:
> Hi Jan,
>
> One more comment which I missed in previous reply:
>
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Shreyansh Jain
> > Sent: Monday, June 13, 201
There are 2 new fake devices for testing PCI infra. All the fake devices
are now identified by non-existing vendor and device IDs so there is no
real driver to bind to them. The testing drivers match those IDs.
Signed-off-by: Jan Viktorin
Suggested-by: Thomas Monjalon
---
app/test/test_pci.c
linked_tar_resource if disabled
> ---
Reviewed-by: Jan Viktorin
Acked-by: Jan Viktorin
Hello Thomas,
On Tue, 14 Jun 2016 10:59:49 +0200
Thomas Monjalon wrote:
> The commit 66819e6 has introduced a dependency on libarchive to be able
> to use some tar resources in the unit tests.
> It is now an optional dependency because some systems do not have it
> installed.
I am surprised
Dumping of devices in a unittest is useless. Instead, test whether
the test has been set up well - i.e. there are no devices.
Signed-off-by: Jan Viktorin
---
app/test/test_pci.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/app/test/test_pci.c b/app/test/test_pci.c
index
1 - 100 of 535 matches
Mail list logo
