The current test_pci is just a single test case that tests the blacklisting
of devices. Rename it to test_pci_blacklist and call it from the test_pci.
The setup and cleanup are moved out of the test_pci_blacklist entirely
to cover all other tests.
Signed-off-by: Jan Viktorin
---
v3:
* improved
Scan the PCI bus by providing a fake sysfs with a PCI device. The fake sysfs
is a packed file hierarchy linked into the test.
Signed-off-by: Jan Viktorin
---
app/test/Makefile | 1 +
app/test/test_pci.c| 58
now possible
to create a fake sysfs hierarchy for testing.
Signed-off-by: Jan Viktorin
---
v3:
* changed subject
* test_pci_sysfs has been slightly modified to be more understandable
* fixed whitespace in *version.map files
---
app/test/test_pci.c | 28
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 | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/app/test/test_pci.c b/app/test/test_pci.c
es checked
will do for v4.
Jan
On Tue, 17 May 2016 20:34:51 +0200
Jan Viktorin wrote:
> Certain internal mechanisms of DPDK access different file system structures
> (e.g. /sys/bus/pci/devices). It is difficult to test those cases automatically
> by a unit test when such path is not hard-co
On Tue, 17 May 2016 20:34:59 +0200
Jan Viktorin wrote:
> The SYSFS_PCI_DEVICES is a constant that makes the PCI testing difficult as
> it points to an absolute path. We remove using this constant and introducing
> a function pci_get_sysfs_path that gives the same value. However, the
devinitfn_ ##d(void)\
> {\
> - rte_eal_driver_register(&d);\
> -}
> +rte_eal_driver_register(&d);\
> +}\
> +DRIVER_EXPORT_NAME(n, __COUNTER__)
> +
> +#define DRIVER_REGISTER_PCI_TABLE(n, t) \
> +static const char n##_pci_tbl_export[] __attribute__((used))
elong at the end of the first
> > 64 byte
> > cache line as currently "port" is defined as uint8_t, IMO, that is less.
> > We may need to increase that uint16_t. The reason why I think that
> > because, Currently in ThunderX HW, we do have 128VFs per socket for
> > built-in NIC, So, the two node configuration and one external PCIe NW card
> > configuration can easily go beyond 256 ports.
> >
> Ok, good point. If you think it's needed, and if we are changing the mbuf
> structure, it might be a good time to extend that field while you are at it,
> save
> a second ABI break later on.
>
> /Bruce
>
> > >
> > > Regards,
> > > /Bruce
> > >
> > > Ref: http://dpdk.org/ml/archives/dev/2014-December/009432.html
> > >
--
Jan Viktorin E-mail: Viktorin at RehiveTech.com
System Architect Web:www.RehiveTech.com
RehiveTech
Brno, Czech Republic
Hello David,
please, see my comments inline.
I didn't see the previous versions of the mempool (well, only very roughly) so
I am
probably missing some points... My point of view is as a user of the handler
API.
I need to understand the API to implement a custom handler for my purposes.
On Thu,
.
> + rte_pktmbuf_pool_init(mp, &mbp_priv);
> +
> + if (rte_mempool_populate_default(mp) < 0) {
> + rte_mempool_free(mp);
> + return NULL;
> + }
> +
> + rte_mempool_obj_iter(mp, rte_pktmbuf_init, NULL);
> +
> + return
On Thu, 19 May 2016 14:45:00 +0100
David Hunt wrote:
> Use a minimal custom mempool external handler and check that it also
> passes basic mempool autotests.
>
> Signed-off-by: Olivier Matz
> Signed-off-by: David Hunt
>
> ---
> app/test/test_mempool.c | 113 +++
.
> >
> > How can I pass an opaque pointer here? The only way I see is through the
> > rte_mempool.pool.
>
> I think have addressed this in a later patch, in the discussions with
> Jerin on the list. But
> rather than passing data at register time, I pa
On Tue, 31 May 2016 10:17:41 +0100
"Hunt, David" wrote:
> Hi Jan,
>
> On 5/23/2016 1:45 PM, Jan Viktorin wrote:
> > On Thu, 19 May 2016 14:45:00 +0100
> > David Hunt wrote:
>
> --snip--
>
[...]
> >> +
> > The test becomes quite co
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 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
gt; > > > > /projects/dpdk_latest/lib/librte_vhost/vhost_user/virtio-
> > > > > net-user.c:250:23:
> > > > > > error: array subscript is above array bounds [-Werror=array-bounds]
> > > > > >rvq = dev->virtqueue[i * VIRTIO_QNUM +
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 ethdev: introduce sample action for rte flow
Jan
>
> Thanks.
> B.R.
>
> Jonny
>
> > -Original Message-
> > From: Jan Viktorin
> > Se
was no support on mlx5
for passthru...
flow isolate 0 true
flow create 0 ingress pattern end actions passthru / rss end / end
Is there any other possibility or PMD+NIC that is known to solve such
issue?
Thanks
Jan Viktorin
[1]
https://doc.dpdk.org/guides/prog_guide/rte_flow.html#table-rte
failed: drivers/net/mlx5/mlx5_flow_dv.c:80
error: drivers/net/mlx5/mlx5_flow_dv.c: patch does not apply
error: patch failed: drivers/net/mlx5/mlx5_flow_dv.c:9007
error: drivers/net/mlx5/mlx5_flow_dv.c: patch does not apply
Jan
>
> Regards,
> Asaf Penso
>
> >-Original Message-----
>
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
> > > > [jblu
; Probably 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
> > +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
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
Hello Vipin and others,
please, will there be any progress or update on this series?
I successfully tested those changes on our Intel and AMD machines and
would like to use it in production soon.
The API is a little bit unintuitive, at least for me, but I
successfully integrated into our softwar
601 - 624 of 624 matches
Mail list logo
