The struct rte_flow_action was missing from DPDK API documentation.
Signed-off-by: Jan Viktorin
---
lib/ethdev/rte_flow.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index 961a5884fe..70f455d47d 100644
--- a/lib/ethdev
desirable to accidently omit a packet that was received by primary
ingress logic instead of being redirected into the dedicated queue.
Are there any chances that for mlx5 it would be possible to insert flow
rules before calling rte_eth_dev_start? Anyway, the behaviour should be
specified and d
On Sun, 11 Jul 2021 08:49:18 +
Ori Kam wrote:
> Hi Jan,
Hi Ori,
>
>
> > -Original Message-
> > From: dev On Behalf Of Jan Viktorin
> > Sent: Wednesday, July 7, 2021 6:54 PM
> >
> > On Sun, 4 Jul 2021 15:18:01 +
> > Matan A
On Tue, 13 Jul 2021 12:26:35 +0300
Andrew Rybchenko wrote:
> On 7/13/21 11:18 AM, Havlík Martin wrote:
> > Dne 2021-07-12 15:07, Ori Kam napsal:
> >> Hi Jan,
> >>
> >>> -----Original Message-
> >>> From: Jan Viktorin
> >>>
On Tue, 13 Jul 2021 17:17:51 +
Ori Kam wrote:
> Hi Jan,
>
> > -Original Message-
> > From: Jan Viktorin
> > Sent: Tuesday, July 13, 2021 2:06 PM
> >
> > On Tue, 13 Jul 2021 12:26:35 +0300
> > Andrew Rybchenko wrote:
> >
can build a FIB for the data
plane. And when the single RIB is updated (which can take quite a lot
of time) I build a new FIB and locklessly give it to the dataplane.
Such approach is not considered?
Jan
>
>
> On 05/08/2021 15:14, Jan Viktorin wrote:
> > On Thu, 5 Aug 2021 15:08:13
On Thu, 5 Aug 2021 15:57:14 +0200
"Medvedkin, Vladimir" wrote:
> On 05/08/2021 15:32, Jan Viktorin wrote:
> > On Thu, 5 Aug 2021 15:27:15 +0200
> > "Medvedkin, Vladimir" wrote:
> >
> >> Hi Jan,
> >>
> >> The RIB is always
On Thu, 5 Aug 2021 16:29:50 +0200
"Medvedkin, Vladimir" wrote:
> On 05/08/2021 16:07, Jan Viktorin wrote:
> > On Thu, 5 Aug 2021 15:57:14 +0200
> > "Medvedkin, Vladimir" wrote:
> >
> >> On 05/08/2021 15:32, Jan Viktorin wrote:
> &
different traffic.
>
> [1]
> http://patches.dpdk.org/project/dpdk/list/?series=12045
>
> Regards,
> Asaf Penso
>
> >-Original Message-
> >From: dev On Behalf Of Jan Viktorin
> >Sent: Friday, September 18, 2020 3:56 PM
> >To: dev@dpdk.org
> >Subject
Jan
[1] http://mails.dpdk.org/archives/dev/2021-March/200475.html
>
> With best regards, Slava
>
> > -Original Message-
> > From: Jan Viktorin
> > Sent: Monday, March 1, 2021 14:21
> > To: Asaf Penso
> > Cc: dev@dpdk.org; Ori Kam ; Jiawei(J
.vutbr.cz; Xiaoyun Li ;
> >> Ferruh Yigit
> >> ; Andrew Rybchenko
> >> ;
> >> Ajit Khaparde ; Haiyue Wang
> >> ; Ori Kam ; Haifei Luo
> >> ; Slava Ovsiienko ;
> >> Andrey Vesnovaty ; Bing Zhao
> >> ; Jiawei(Jonny) Wang
Hi all,
I'd like to test this feature somehow but this patch just implements the API...
Will there
be some PMD support soon? I could see that mlx5 implements some internal hidden
RTE Flow
item SC already that matches this behaviour... It would be great to make it
available
via this TX_QUEUE fea
On Wed, 31 Aug 2022 22:25:24 +0200
Thomas Monjalon wrote:
> 31/08/2022 21:30, Stephen Hemminger:
> > Going over list of active DPDK developers and MAINTAINERS
> > and noticed that Jan's email was not active. His response was:
> >
> >well, that rehivetech.com address is probably receiving but
On Tue, 24 Aug 2021 14:18:16 +0100
Ferruh Yigit wrote:
> On 7/15/2021 2:58 PM, Thomas Monjalon wrote:
> > 14/07/2021 17:00, Jan Viktorin:
> >>>> On Tue, 13 Jul 2021 12:26:35 +0300
> >>>> Andrew Rybchenko wrote:
> >>>>>&g
ping port 0...
Stopping ports...
Done
Stopping port 1...
Stopping ports...
Done
Shutting down port 0...
Closing ports...
Port 0 is closed
Done
Shutting down port 1...
Closing ports...
Port 1 is closed
Done
Bye...
Jan
>
> Thanks.
> Jonny
>
> > -Original Message
Hello Jiawei,
On Fri, 12 Mar 2021 09:32:44 +
"Jiawei(Jonny) Wang" wrote:
> Hi Jan,
>
> > -Original Message-
> > From: Jan Viktorin
> > Sent: Friday, March 12, 2021 12:33 AM
> > To: Jiawei(Jonny) Wang
> > Cc: Slava Ovsiienko ; Asaf
# echo switchdev > /sys/class/net//compat/devlink/mode
It is good to mention that after the rebind, the can
change.
Regards,
Jan
>
> echo -n "" > > /sys/bus/pci/drivers/mlx5_core/bind
>
> With best regards,
> Slava
>
> > -Original Message
From: Jan Viktorin
Signed-off-by: Jan Viktorin
---
doc/guides/nics/mlx5.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
index 7c50497fb..0a2dc3dee 100644
--- a/doc/guides/nics/mlx5.rst
+++ b/doc/guides/nics/mlx5
From: Jan Viktorin
The step 4 is a contradiction. It advices to unbind the device from the
mlx5_core which removes the associated system network interface (e.g.
eth0). In the step 5, the same system network interface (e.g. eth0) is
required to exist.
Signed-off-by: Jan Viktorin
---
doc/guides
OK, after firmware update, it seems that it works now.
Thank you for help!
Jan
On Mon, 15 Mar 2021 14:22:16 +0100
Jan Viktorin wrote:
> Hello Jiawei,
>
> On Fri, 12 Mar 2021 09:32:44 +
> "Jiawei(Jonny) Wang" wrote:
>
> > Hi Jan,
> >
> > &
dicated PCI device)
> - ens1f0_2 (no dedicated PCI device)
>
> 6. As result we should get 7 netdevs - 1 PF (Uplink representor), 3 VFs, 3
> representors (no PCI device, pure netdev)
>
> With best regards, Slava
>
> > -Original Message-
> > From: Jan Viktorin
On Mon, 15 Mar 2021 19:52:46 +
Slava Ovsiienko wrote:
> Hi, Jan
>
> > -Original Message-
> > From: Jan Viktorin
> > Sent: Monday, March 15, 2021 21:49
> > To: Slava Ovsiienko
> > Cc: dev@dpdk.org; Asaf Penso ; Shahaf Shuler
> > ; Matan Az
On Thu, 12 Jan 2017 10:30:58 +0800
Yuanhan Liu wrote:
> On Wed, Jan 11, 2017 at 03:51:22PM +0100, Thomas Monjalon wrote:
> > 2017-01-11 12:27, Yuanhan Liu:
> > > The fact that virtio net header is initiated to zero in PMD driver
> > > init stage means that these costly writes are unnecessary an
es/2014-09/msg00162.html
they ifdef it for __aarch64.
Regards
Jan
--
Jan Viktorin E-mail: vikto...@rehivetech.com
System Architect Web:www.RehiveTech.com
RehiveTech
Brno, Czech Republic
_TAIL(&soc_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 f
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
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.
>
>
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
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.
>
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/
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
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
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
esented by the OS. Otherwise, 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
>
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
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 sometimes l
On Mon, 19 Sep 2016 12:17:53 +0530
Shreyansh Jain wrote:
> Hi Jan,
>
> On Friday 16 September 2016 05:57 PM, Jan Viktorin wrote:
> > On Fri, 9 Sep 2016 14:13:50 +0530
> > Shreyansh Jain wrote:
> >
> >> Each SoC PMD registers a set of callback for scanning
On Tue, 20 Sep 2016 06:46:31 +
Shreyansh Jain wrote:
> Hi Jan,
>
> > -Original Message-
> > From: Jan Viktorin [mailto:viktorin at rehivetech.com]
> > Sent: Monday, September 19, 2016 5:04 PM
> > To: Shreyansh Jain
> > Cc: dev at dpdk.org; Hemant
md_bnxt.h | 19 +++
drivers/net/bnxt/rte_pmd_bnxt_version.map | 1 +
8 files changed, 124 insertions(+), 9 deletions(-)
Regards
Jan
--
Jan Viktorin E-mail: vikto...@rehivetech.com
System Architect Web:www.RehiveTech.com
RehiveTech
Br
low.o] Error 1
make[3]: *** [tap] Error 2
make[2]: *** [net] Error 2
make[1]: *** [drivers] Error 2
make: *** [all] Error 2
Finished: FAILURE
Regards
Jan Viktorin
--
Jan Viktorin E-mail: vikto...@rehivetech.com
System Architect Web:www.RehiveTech.com
Rehiv
On Fri, 7 Apr 2017 14:05:59 +0200
Pascal Mazon wrote:
> On Fri, 7 Apr 2017 13:13:13 +0200
> Jan Viktorin wrote:
>
> > Hello Pascal,
> >
> > my internal ARMv7 DPDK autobuilder is failing. I've bisected to the
> > source of the problem:
> >
> &g
ing HAVE_TC_FLOWER.
sh -- '/home/viktorin/dpdk/buildtools/auto-config-h.sh' 'tap_autoconf.h.new' \
HAVE_TC_VLAN_ID \
linux/pkt_cls.h \
enum TCA_FLOWER_KEY_VLAN_PRIO \
It seems like the -mtune="cortex-a9" has extra quotes (or they are
misinterpreted
s: 02a8686263de ("mk: introduce ARMv7 architecture")
> Fixes: 4a7e4626975a ("mk: introduce NXP dpaa2 architecture based on armv8-a")
>
> Reported-by: Jan Viktorin
> Signed-off-by: Pascal Mazon
Tested-by: Jan Viktorin
> ---
>
> I couldn't test it
Hello Ashwin Sekhar,
some comments below...
On Thu, 27 Apr 2017 07:10:20 -0700
Ashwin Sekhar T K wrote:
> * Added CRC compute APIs for arm64 utilizing the pmull capability
> * Added new file net_crc_neon.h to hold the arm64 pmull CRC
> implementation
> * Added crypto capability in compilation
On Fri, 28 Apr 2017 10:19:20 +
"Sekhar, Ashwin" wrote:
> Hi Jan,
> Thanks for the comments. Please see my responses inline.
>
> On Friday 28 April 2017 03:25 PM, Jan Viktorin wrote:
> > Hello Ashwin Sekhar,
> >
> > some comments below...
> &g
ese
> capabilities
> * RTE_CPUFLAG_AES
> * RTE_CPUFLAG_PMULL
> * RTE_CPUFLAG_SHA1
> * RTE_CPUFLAG_SHA2
>
> Signed-off-by: Ashwin Sekhar T K
Reviewed-by: Jan Viktorin
compilation on x86 with gcc and clang
Tested compilation on:
* arm64 with gcc
* x86 with gcc and clang
>
> Signed-off-by: Ashwin Sekhar T K
Reviewed-by: Jan Viktorin
Hello Jimmy,
On Tue, 16 May 2017 15:38:22 +0530
Jimmy Carter wrote:
> Hi All
>
> I am using dpdk16.11.1 and want to use openwrt external toolchain so that I
> can cross compile for arm cortex 15
> neon.(arm_cortex-a15+neon-vfpv4_gcc-5.4.0_musl_eabi)
I've never built DPDK with musl-eabi. I don'
On Tue, 16 May 2017 13:22:19 +0200
Thomas Monjalon wrote:
> 16/05/2017 12:51, Jan Viktorin:
> > DPDK does not support OpenWRT because (as far as I know) nobody from
> > the DPDK community is using it in this way. I build DPDK via Buildroot
> > but this is unsupported
On Tue, 16 May 2017 07:44:59 -0400
Neil Horman wrote:
> On Tue, May 16, 2017 at 12:51:40PM +0200, Jan Viktorin wrote:
> > Hello Jimmy,
> >
> > On Tue, 16 May 2017 15:38:22 +0530
> > Jimmy Carter wrote:
> >
> > > Hi All
> > >
> >
2017 at 5:14 PM, Neil Horman wrote:
>
> > On Tue, May 16, 2017 at 12:51:40PM +0200, Jan Viktorin wrote:
> > > Hello Jimmy,
> > >
> > > On Tue, 16 May 2017 15:38:22 +0530
> > > Jimmy Carter wrote:
> > >
> > > > Hi All
>
@@
# Locally calculated
-sha256 d631495bc6e8d4c4aec72999ac03c3ce213bb996cb88f3bf14bb980dad1d3f7b
dpdk-16.04.tar.gz
+sha256 f917875b1432adaaebb2761c154623bb101e0308153aa011f06a69bd1e9e98fb
dpdk-16.04.tar.gz
it works.
$ ls output/images/
rootfs.ext2 vexpress-v2p-ca9.dtb zImage
Regards
Jan
>
>
> Thanks
>
> On Tue, May 16, 2017
On Thu, 11 May 2017 15:40:42 +0530
Jerin Jacob wrote:
> The patch does not provide any functional change for ARM32
> with respect to existing rte_pause() definition.
>
> CC: Jan Viktorin
> CC: Jianbo Liu
> Signed-off-by: Jerin Jacob
Acked-by: Jan Viktorin
; {
> * @return
> * The time base for this lcore.
> */
> -#ifndef CONFIG_RTE_ARM_EAL_RDTSC_USE_PMU
> +#ifndef RTE_ARM_EAL_RDTSC_USE_PMU
>
> /**
> * This call is easily portable to any ARM architecture, however,
--
Jan Viktorin E-mail: Viktorin
On Tue, 1 Dec 2015 13:41:13 -0500
Jianbo Liu wrote:
> CONFIG_* from config files can not be used in code.
>
> Signed-off-by: Jianbo Liu
> ---
Acked-by: Jan Viktorin
--
Jan Viktorin E-mail: Viktorin at RehiveTech.com
System Architect
| 51
> lib/librte_lpm/rte_lpm.h | 68
> ++++++++--
> 8 files changed, 105 insertions(+), 29 deletions(-)
>
--
Jan Viktorin E-mail: Viktorin at RehiveTech.com
System Architect Web:www.RehiveTech.com
RehiveTech
Brno, Czech Republic
On Tue, 1 Dec 2015 20:13:49 +0530
Jerin Jacob wrote:
> > enum rte_acl_classify_alg alg = RTE_ACL_CLASSIFY_DEFAULT;
> >
> > -#ifdef RTE_ARCH_ARM64
> > +#if defined(RTE_ARCH_ARM) || defined(RTE_ARCH_ARM64)
> > alg = RTE_ACL_CLASSIFY_NEON;
>
> I believe SIMD is optional in armv7. If tr
can converge the patches after the discussion.
> Please check "[dpdk-dev] [PATCH 0/3] add lpm support for NEON" on ml
I've missed that too. Did you CC me?
Jan
--
Jan Viktorin E-mail: Viktorin at RehiveTech.com
System Architect Web:www.R
On Wed, 2 Dec 2015 16:09:06 +0530
Jerin Jacob wrote:
> > > [snip]
> > > IMO, it's not always good to emulate GCC defined intrinsics of
> > > other architecture. What if a legacy DPDK application has such mappings
> > > then BOOM, multiple definition, which one is correct? which one
> > > to comme
On Wed, 2 Dec 2015 16:18:13 +0530
Jerin Jacob wrote:
> > > [snip]
> >
> > My preference would also be to put architecture dependent implementation
> > into different files.
> > Might be create lib/librte_lpm/arch/(arm|x86)/... here?
> > Konstantin
>
> +1
>
> my existing patch creates lib/
| 5 +
> lib/librte_lpm/rte_lpm_neon.h | 172
> ++
> 8 files changed, 212 insertions(+), 9 deletions(-)
> create mode 100644 lib/librte_lpm/rte_lpm_neon.h
>
> --
> 2.1.0
>
--
Jan Viktorin E-mail: V
; #endif
I like this approach. It is a question whether to inherit names from
SSE. However, why to reinvent the wheel...
We probably need other people to give their ideas about such
generalization of the API.
I think, there should be an autotest of the rte_vect API. Is it
possible to create one?
Regards
Jan
--
Jan Viktorin E-mail: Viktorin at RehiveTech.com
System Architect Web:www.RehiveTech.com
RehiveTech
Brno, Czech Republic
> hop[3] = (tbl[3] & RTE_LPM_LOOKUP_SUCCESS) ? (uint8_t)tbl[3] : defv;
> }
>
> +#endif
> +
I would separate the SSE implementation into its own file as well.
Otherwise, I like this patch. I hope to be able to test it soon.
> [snip]
--
Jan Viktorin E-mail: Viktorin at RehiveTech.com
System Architect Web:www.RehiveTech.com
RehiveTech
Brno, Czech Republic
ibrte_hash/* files in the patch set. Is it by mistake?
>
> EZchip TILE-Gx
> M: Zhigang Lu
--
Jan Viktorin E-mail: Viktorin at RehiveTech.com
System Architect Web:www.RehiveTech.com
RehiveTech
Brno, Czech Republic
On Wed, 2 Dec 2015 20:26:08 +0530
Jerin Jacob wrote:
> > [snip]
> > I would separate the SSE implementation into its own file as well.
>
> make sense. planning to make it as lib/librte_lpm/rte_lpm_sse.h
> and lib/librte_lpm/rte_lpm_neon.h. OK ?
>
> I can fix it in next revision.
Yes, pleas
? P?vodn? zpr?va ?
Od: Thomas Monjalon
Odesl?no: ?ter?, 8. prosince 2015 11:04
Komu: Jianbo Liu
Kopie: dev at dpdk.org; Jan Viktorin; Jerin Jacob
P?edm?t: Re: [dpdk-dev] [PATCH v2 2/3] eal/acl: enable acl for armv7-a
2015-12-08 15:56, Jianbo Liu:
> On 8 December 2015 at 10:23, Thomas Monja
ebody be a moderator? There is the chat that can be used for this...
Finally, some conclusion should be sent into the mailing list.
Regards
Jan?Viktorin
RehiveTech
Sent?from?a?mobile?device
? P?vodn? zpr?va ?
Od: Bob Monkman
Odesl?no: ?ter?, 8. prosince 2015 1:55
Komu: O'Driscoll, Tim; dev at
> ARCH_ARM64,
> > >> >> > and ARMv7 may be called AArch32 or ARCH_ARM. But I don't know why?
> > >> >> >
> > >> >> https://lkml.org/lkml/2012/7/15/133
> > >> >>
> > >> >> > Is ARCH_ARM32 or AR
t. Is there any convention how to do this?)
---
This commit removes warning reported when building for ARMv7 target.
Signed-off-by: Jan Viktorin
---
lib/librte_ether/rte_ether.h | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/lib/librte_ether/rte_ether.h b/lib/librte_
On Tue, 8 Dec 2015 12:02:54 -0800
Stephen Hemminger wrote:
> On Tue, 8 Dec 2015 20:29:53 +0100
> Jan Viktorin wrote:
>
> > Hello,
> >
> > I was looking at some warnings generated during ARM build. I can see
> > 53 warnings for my build based on v2.2.0
On Tue, 08 Dec 2015 21:30:03 +0100
Thomas Monjalon wrote:
> 2015-12-08 20:29, Jan Viktorin:
> > (I considered to not add the cover-letter as this is just a single small
> > patch.
> > I hope it does not matter a lot. Is there any convention how to do this?)
>
> The
On Tue, 08 Dec 2015 21:57:33 +0100
Thomas Monjalon wrote:
> 2015-12-08 21:55, Jan Viktorin:
> > On Tue, 08 Dec 2015 21:30:03 +0100
> > Thomas Monjalon wrote:
> >
> > > 2015-12-08 20:29, Jan Viktorin:
> > > > (I considered to not add the cover-lett
54675/
After I integrate the new DPDK install rules and fix some minor issues,
I assume that it will be accepted upstream there. Buildroot is useful
at least for cross toolchain generation.
Regards
Jan
--
Jan Viktorin E-mail: Viktorin at RehiveTech.com
System Arch
gt; On Wed, Dec 9, 2015 at 8:10 PM, Jan Viktorin
> wrote:
>
> > Hello,
> >
> > I've posted a new patch set with DPDK support into the Buildroot project:
> >
> > http://lists.busybox.net/pipermail/buildroot/2015-December/146564.html
> >
> > Patchwo
This patch reduces number of warnings from 53 to 40. It removes the usual false
positives utilizing unaligned_uint*_t data types.
Signed-off-by: Jan Viktorin
---
As far as I know, only a 64-bit unaligned access can be a problem for ARMv7.
I found only one such occurence:
118 struct rte_mbuf
On Fri, 4 Dec 2015 23:05:18 +0530
Santosh Shukla wrote:
> iopl() syscall not supported in linux-arm/arm64 so always return 0 value.
>
> Signed-off-by: Santosh Shukla
> ---
Acked-by: Jan Viktorin
Hello,
I am not involved in the vfio very much, however, I was watching some
vfio-related code in last few weeks. It looks promising to me and
IMHO it seems to the best way to bring a support of integrated Ethernet
MACs into DPDK (related to many SoCs). Unfortunately, the ARMv7 SoCs (I
know) lacks
ort.h
> create mode 100644 lib/librte_eal/common/include/arch/arm/rte_io.h
> create mode 100644 lib/librte_eal/common/include/arch/arm/rte_io_32.h
> create mode 100644 lib/librte_eal/common/include/arch/arm/rte_io_64.h
> create mode 100644 lib/librte_eal/common/include/
I believe, I've already acked this patch. I can see no change here so I
assume it's still the same.
On Mon, 14 Dec 2015 18:30:26 +0530
Santosh Shukla wrote:
> iopl() syscall not supported in linux-arm/arm64 so always return 0 value.
>
> Signed-off-by: Santosh Shukla
Acked-by: Jan Viktorin
> Signed-off-by: Thomas Monjalon
Acked-by: Jan Viktorin
otes/deprecation.rst
> >> @@ -12,6 +12,9 @@ Deprecation Notices
> >> ibadcrc, ibadlen, imcasts, fdirmatch, fdirmiss,
> >> tx_pause_xon, rx_pause_xon, tx_pause_xoff, rx_pause_xoff
> >>
> >> +* The ethdev structures rte_eth_link, rte_eth_dev_info a
On Thu, 17 Dec 2015 11:09:23 +0100
Thomas Monjalon wrote:
> Hi,
>
> 2015-12-17 09:52, Burakov, Anatoly:
> > > > > > On Tue, Dec 15, 2015 at 09:53:18AM -0700, Alex Williamson wrote:
> > > > > > So it works. Is it acceptable? Useful? Sufficiently complete?
> > > > > > Does it imply deprecating
Replace the BSD license header with the SPDX tag for files
with only an RehiveTech copyright on them.
Signed-off-by: Jan Viktorin
---
.../common/include/arch/arm/rte_atomic.h | 32 ++
.../common/include/arch/arm/rte_atomic_32.h| 32
Replace the BSD license header with the SPDX tag for files
with only an RehiveTech copyright on them.
Signed-off-by: Jan Viktorin
---
mk/arch/arm/rte.vars.mk | 32 ++--
mk/machine/armv7a/rte.vars.mk | 31 ++-
2 files changed, 4
Hi all,
I've updated all relevant code to SPDX license. The last commit
also updates the Cavium copyright, I've separated it for clarity
otherwise it can be squashed into 02.
Jan
Jan Viktorin (6):
mk: use SPDX tag for RehiveTech copyright files
lib: use SPDX tag for RehiveTech
Replace the BSD license header with the SPDX tag for files
with only an RehiveTech copyright on them.
Signed-off-by: Jan Viktorin
---
drivers/bus/vdev/rte_bus_vdev.h | 32 ++--
drivers/bus/vdev/vdev.c | 32 ++--
2 files changed, 4
Replace the BSD license header with the SPDX tag for files
with a RehiveTech and Cavium copyright on them.
Signed-off-by: Jan Viktorin
---
lib/librte_eal/common/arch/arm/rte_cpuflags.c | 34 +++
1 file changed, 3 insertions(+), 31 deletions(-)
diff --git a/lib
Replace the BSD license header with the SPDX tag for files
with only an RehiveTech copyright on them.
Signed-off-by: Jan Viktorin
---
test/test/resource.c | 33 ++---
test/test/resource.h | 33 ++---
test/test/test_resource.c
Replace the BSD license header with the SPDX tag for files
with only an RehiveTech copyright on them.
Signed-off-by: Jan Viktorin
---
config/defconfig_arm-armv7a-linuxapp-gcc | 31 ++-
1 file changed, 2 insertions(+), 29 deletions(-)
diff --git a/config
would be two separate devices with not information how they are
connected to each other. Such information was accessible only via the
device tree. Finally, I also needed to control the PHY from DPDK.
Again, information about PHY is unavailable via /sys.
Regards
Jan
--
Jan ViktorinE-mail: vikto...@rehivetech.com
System ArchitectWeb:www.RehiveTech.com
RehiveTech
Brno, Czech Republic
call to open() will return 0 as a valid descriptor.
Good catch! Please add also:
Fixes: b94e5c9406b5 ("eal/arm: add CPU flags for ARMv7")
Fixes: 97523f822ba9 ("eal/arm: add CPU flags for ARMv8")
Fixes: 9ae155385686 ("eal/ppc: cpu flag checks for IBM Power")
>
&g
wer")
>
> Signed-off-by: Lukasz Majczak
Acked-by: Jan Viktorin
On Mon, 29 Feb 2016 16:14:58 +0100
Thomas Monjalon wrote:
> 2015-12-09 16:16, Jan Viktorin:
> > This patch reduces number of warnings from 53 to 40. It removes the usual
> > false
> > positives utilizing unaligned_uint*_t data types.
> >
> > Signed-off-by: Jan
On Mon, 29 Feb 2016 16:55:38 +0100
Jan Viktorin wrote:
> On Mon, 29 Feb 2016 16:14:58 +0100
> Thomas Monjalon wrote:
>
> > 2015-12-09 16:16, Jan Viktorin:
> > > This patch reduces number of warnings from 53 to 40. It removes the usual
> > > false
> >
on the Device Tree
identifier (rte_soc_addr) to mimic the PCI behaviour.
Signed-off-by: Jan Viktorin
---
lib/librte_eal/common/Makefile | 2 +-
lib/librte_eal/common/eal_common_devargs.c | 6 +
lib/librte_eal/common/include/rte_devargs.h | 7 +
lib/librte_eal/common/include
This option has the same meaning for the SoC infra as the --no-pci
for the PCI infra.
Signed-off-by: Jan Viktorin
---
lib/librte_eal/common/eal_common_options.c | 5 +
lib/librte_eal/common/eal_internal_cfg.h | 1 +
lib/librte_eal/common/eal_options.h| 2 ++
3 files changed, 8
Probing and detaching of devices. The code is heavily based on the PCI infra.
Signed-off-by: Jan Viktorin
---
lib/librte_eal/common/eal_common_soc.c | 367 +
lib/librte_eal/common/eal_private.h| 12 ++
lib/librte_eal/linuxapp/eal/Makefile | 1 +
3 files
: Jan Viktorin
---
lib/librte_eal/common/include/rte_soc.h | 6 --
lib/librte_eal/linuxapp/eal/eal_soc.c | 15 +++
2 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/lib/librte_eal/common/include/rte_soc.h
b/lib/librte_eal/common/include/rte_soc.h
index 7c279b1
Signed-off-by: Jan Viktorin
---
lib/librte_eal/linuxapp/eal/eal.c | 4
1 file changed, 4 insertions(+)
diff --git a/lib/librte_eal/linuxapp/eal/eal.c
b/lib/librte_eal/linuxapp/eal/eal.c
index 635ec36..8a6691d 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal
(eg. an EMAC with a separate DMA engine), we cannot treat it as a
single device as the relation between whose might not be described in a
standardized way. So the drivers of the particular devices must take care of
this themselfs.
Signed-off-by: Jan Viktorin
---
lib/librte_eal/linuxapp/eal
1 - 100 of 624 matches
Mail list logo
