Re: [dpdk-dev] [PATCH v3] doc: update flow filtering document
Hi, Ferruh > -Original Message- > From: Yigit, Ferruh > Sent: Tuesday, February 6, 2018 10:19 PM > To: Mcnamara, John ; Zhao1, Wei > ; dev@dpdk.org > Cc: sta...@dpdk.org; or...@mellanox.com > Subject: Re: [dpdk-dev] [PATCH v3] doc: update flow filtering document > > On 2/5/2018 3:31 PM, Mcnamara, John wrote: > > > >> -Original Message- > >> From: Yigit, Ferruh > >> Sent: Wednesday, January 31, 2018 5:24 PM > >> To: Zhao1, Wei ; dev@dpdk.org > >> Cc: Mcnamara, John ; sta...@dpdk.org; > >> or...@mellanox.com > >> Subject: Re: [dpdk-dev] [PATCH v3] doc: update flow filtering > >> document > >> > >> On 1/31/2018 2:12 AM, Wei Zhao wrote: > >>> This patch will update example application of flow_filtering document. > >>> It add Tx queues configuration related comment. > >>> > >>> Signed-off-by: Wei Zhao > >>> Reviewed-by: Ori Kam > >> > >> Hi Wei, > >> > >> This patch is causing documentation warning: > >> ...dpdk/doc/guides/sample_app_ug/flow_filtering.rst:161: WARNING: > >> Could not lex literal_block as "c". Highlighting skipped. > > > > Hi, > > > > The reason for the warning was due to 2 instances like the following: > > > > +rte_exit(EXIT_FAILURE, > > +":: Rx queue setup failed: err=%d, > > +port=%u\n", > > +ret, port_id); > > > > > > Here the error string extends over 2 lines so the error message will > > print out a newline and a lot of whitespace in the middle of the string. It > should probably be something like the following: > > > > +rte_exit(EXIT_FAILURE, > > +":: Rx queue setup failed: err=%d, " > > +"port=%u\n", > > +ret, port_id); > > > > or just: > > > > +rte_exit(EXIT_FAILURE, > > +":: Rx queue setup failed: err=%d, > > port=%u\n", > > +ret, port_id); > > Thanks for clarifying this John. > > Patch pulled from next-net-intel to next-net and suggested fix applied on > next-net. Code in next-net-intel has been fixed for this issue, but code in v3 has not. So, the code you pull from next-net-intel has been changed to rte_exit(EXIT_FAILURE, ":: Rx queue setup failed: err=%d, port=%u\n", ret, port_id); you can have a double check, maybe it do not need fix patch.
[dpdk-dev] [PATCH v2] buildtools: output build failure reason to stderr
If build fails because of failed experimental check and stdout is
redirected to /dev/null, it is absolutely unclear why build fails.
Fixes: a4bcd61de82d ("buildtools: add script to check experimental API exports")
Signed-off-by: Andrew Rybchenko
---
v2:
- use <<- to keep indentation of the message
buildtools/check-experimental-syms.sh | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/buildtools/check-experimental-syms.sh
b/buildtools/check-experimental-syms.sh
index 7d21de3..5bc8cda 100755
--- a/buildtools/check-experimental-syms.sh
+++ b/buildtools/check-experimental-syms.sh
@@ -22,9 +22,11 @@ do
IN_EXP=$?
if [ $IN_TEXT -eq 0 -a $IN_EXP -ne 0 ]
then
- echo "$SYM is not flagged as experimental"
- echo "but is listed in version map"
- echo "Please add __rte_experimental to the definition of $SYM"
+ cat >&2 <<- END_OF_MESSAGE
+ $SYM is not flagged as experimental
+ but is listed in version map
+ Please add __rte_experimental to the definition of $SYM
+ END_OF_MESSAGE
exit 1
fi
done
--
2.7.4
Re: [dpdk-dev] [PATCH v2 06/10] net/virtio: fix queue setup consistency
Any update, Olivier?
We are near to release, and the bug-fix is important for the virtio vector path
usage. Thanks.
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Olivier Matz
> Sent: Thursday, February 1, 2018 4:28 PM
> To: Yao, Lei A
> Cc: dev@dpdk.org; y...@fridaylinux.org; maxime.coque...@redhat.com;
> Thomas Monjalon ; sta...@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2 06/10] net/virtio: fix queue setup
> consistency
>
> Hi Lei,
>
> It's on my todo list, I'll check this as soon as possible.
>
> Olivier
>
>
> On Thu, Feb 01, 2018 at 03:14:15AM +, Yao, Lei A wrote:
> > Hi, Olivier
> >
> > This is Lei from DPDK validation team in Intel. During our DPDK
> > 18.02-rc1 test, I find the following patch will cause one serious issue
> > with virtio
> vector path:
> > the traffic can't resume after stop/start the virtio device.
> >
> > The step like following:
> > 1. Launch vhost-user port using testpmd at Host 2. Launch VM with
> > virtio device, mergeable is off 3. Bind the virtio device to pmd
> > driver, launch testpmd, let the tx/rx use vector path
> > virtio_xmit_pkts_simple
> > virtio_recv_pkts_vec
> > 4. Send traffic to virtio device from vhost side, then stop the virtio
> > device 5. Start the virtio device again After step 5, the traffic
> > can't resume.
> >
> > Could you help check this and give a fix? This issue will impact the
> > virtio pmd user experience heavily. By the way, this patch is already
> > included into V17.11. Looks like we need give a patch to this LTS version.
> Thanks a lot!
> >
> > BRs
> > Lei
> > > -Original Message-
> > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Olivier Matz
> > > Sent: Thursday, September 7, 2017 8:14 PM
> > > To: dev@dpdk.org; y...@fridaylinux.org; maxime.coque...@redhat.com
> > > Cc: step...@networkplumber.org; sta...@dpdk.org
> > > Subject: [dpdk-dev] [PATCH v2 06/10] net/virtio: fix queue setup
> > > consistency
> > >
> > > In rx/tx queue setup functions, some code is executed only if
> > > use_simple_rxtx == 1. The value of this variable can change
> > > depending on the offload flags or sse support. If Rx queue setup is
> > > called before Tx queue setup, it can result in an invalid configuration:
> > >
> > > - dev_configure is called: use_simple_rxtx is initialized to 0
> > > - rx queue setup is called: queues are initialized without simple path
> > > support
> > > - tx queue setup is called: use_simple_rxtx switch to 1, and simple
> > > Rx/Tx handlers are selected
> > >
> > > Fix this by postponing a part of Rx/Tx queue initialization in
> > > dev_start(), as it was the case in the initial implementation.
> > >
> > > Fixes: 48cec290a3d2 ("net/virtio: move queue configure code to
> > > proper
> > > place")
> > > Cc: sta...@dpdk.org
> > >
> > > Signed-off-by: Olivier Matz
> > > ---
> > > drivers/net/virtio/virtio_ethdev.c | 13 +
> > > drivers/net/virtio/virtio_ethdev.h | 6 ++
> > > drivers/net/virtio/virtio_rxtx.c | 40 ++-
> > > ---
> > > 3 files changed, 51 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/net/virtio/virtio_ethdev.c
> > > b/drivers/net/virtio/virtio_ethdev.c
> > > index 8eee3ff80..c7888f103 100644
> > > --- a/drivers/net/virtio/virtio_ethdev.c
> > > +++ b/drivers/net/virtio/virtio_ethdev.c
> > > @@ -1737,6 +1737,19 @@ virtio_dev_start(struct rte_eth_dev *dev)
> > > struct virtnet_rx *rxvq;
> > > struct virtnet_tx *txvq __rte_unused;
> > > struct virtio_hw *hw = dev->data->dev_private;
> > > + int ret;
> > > +
> > > + /* Finish the initialization of the queues */
> > > + for (i = 0; i < dev->data->nb_rx_queues; i++) {
> > > + ret = virtio_dev_rx_queue_setup_finish(dev, i);
> > > + if (ret < 0)
> > > + return ret;
> > > + }
> > > + for (i = 0; i < dev->data->nb_tx_queues; i++) {
> > > + ret = virtio_dev_tx_queue_setup_finish(dev, i);
> > > + if (ret < 0)
> > > + return ret;
> > > + }
> > >
> > > /* check if lsc interrupt feature is enabled */
> > > if (dev->data->dev_conf.intr_conf.lsc) { diff --git
> > > a/drivers/net/virtio/virtio_ethdev.h
> > > b/drivers/net/virtio/virtio_ethdev.h
> > > index c3413c6d9..2039bc547 100644
> > > --- a/drivers/net/virtio/virtio_ethdev.h
> > > +++ b/drivers/net/virtio/virtio_ethdev.h
> > > @@ -92,10 +92,16 @@ int virtio_dev_rx_queue_setup(struct
> > > rte_eth_dev *dev, uint16_t rx_queue_id,
> > > const struct rte_eth_rxconf *rx_conf,
> > > struct rte_mempool *mb_pool);
> > >
> > > +int virtio_dev_rx_queue_setup_finish(struct rte_eth_dev *dev,
> > > + uint16_t rx_queue_id);
> > > +
> > > int virtio_dev_tx_queue_setup(struct rte_eth_dev *dev, uint16_t
> > > tx_queue_id,
> > > uint16_t nb_tx_desc, unsigned int socket_id,
> > > const struct rte_eth_txconf *tx_conf);
> > >
> > > +int virtio_dev_tx_queue_setup_finish(struc
Re: [dpdk-dev] [PATCH 00/14] implement packed virtqueues
On 2018年02月06日 21:58, Jens Freimann wrote: On Tue, Feb 06, 2018 at 02:20:02PM +0800, Jason Wang wrote: On 2018???01???29??? 22:11, Jens Freimann wrote: May I ask how do you test the patch? I believe you need some basic packed ring support in both qemu and vhost-user protocol. Yes, I have a small patch for qemu here: https://github.com/jensfr/qemu/commit/71b4013e3a183b1d5ab6d8ad2bb4829951425d33 Also you need another patch for dpdk to disable ctrl virtqueue (a workaround) which is on my dpdk branch: https://github.com/jensfr/dpdk/commit/305f4b2453448402c1994caef8d8e01923660ff3 I will add them to v2 when I send it out. regards, Jens I see. Thanks
[dpdk-dev] [PATCH v2] net/i40e: fix issue during customized info update
Customized info is updated without checking package
operation - ADD or DEL, it only covers ADD operation
currently. This patch adds process for DEL operation.
Fixes: e163c18a15b0 ("net/i40e: update ptype and pctype info")
Cc: sta...@dpdk.org
Signed-off-by: Beilei Xing
---
v2 change:
- Reset ptype table when rollback profile.
drivers/net/i40e/i40e_ethdev.c | 51 +
drivers/net/i40e/i40e_ethdev.h | 4 +++-
drivers/net/i40e/i40e_flow.c| 2 +-
drivers/net/i40e/rte_pmd_i40e.c | 6 +++--
4 files changed, 50 insertions(+), 13 deletions(-)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 06b0f03..bc8927d 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -11454,7 +11454,8 @@ i40e_find_customized_pctype(struct i40e_pf *pf, uint8_t
index)
static int
i40e_update_customized_pctype(struct rte_eth_dev *dev, uint8_t *pkg,
uint32_t pkg_size, uint32_t proto_num,
- struct rte_pmd_i40e_proto_info *proto)
+ struct rte_pmd_i40e_proto_info *proto,
+ enum rte_pmd_i40e_package_op op)
{
struct i40e_pf *pf = I40E_DEV_PRIVATE_TO_PF(dev->data->dev_private);
uint32_t pctype_num;
@@ -11467,6 +11468,12 @@ i40e_update_customized_pctype(struct rte_eth_dev *dev,
uint8_t *pkg,
uint32_t i, j, n;
int ret;
+ if (op != RTE_PMD_I40E_PKG_OP_WR_ADD &&
+ op != RTE_PMD_I40E_PKG_OP_WR_DEL) {
+ PMD_DRV_LOG(ERR, "Unsupported operation.");
+ return -1;
+ }
+
ret = rte_pmd_i40e_get_ddp_info(pkg, pkg_size,
(uint8_t *)&pctype_num, sizeof(pctype_num),
RTE_PMD_I40E_PKG_INFO_PCTYPE_NUM);
@@ -11529,8 +11536,13 @@ i40e_update_customized_pctype(struct rte_eth_dev *dev,
uint8_t *pkg,
i40e_find_customized_pctype(pf,
I40E_CUSTOMIZED_GTPU);
if (new_pctype) {
- new_pctype->pctype = pctype_value;
- new_pctype->valid = true;
+ if (op == RTE_PMD_I40E_PKG_OP_WR_ADD) {
+ new_pctype->pctype = pctype_value;
+ new_pctype->valid = true;
+ } else {
+ new_pctype->pctype = I40E_FILTER_PCTYPE_INVALID;
+ new_pctype->valid = false;
+ }
}
}
@@ -11540,8 +11552,9 @@ i40e_update_customized_pctype(struct rte_eth_dev *dev,
uint8_t *pkg,
static int
i40e_update_customized_ptype(struct rte_eth_dev *dev, uint8_t *pkg,
- uint32_t pkg_size, uint32_t proto_num,
- struct rte_pmd_i40e_proto_info *proto)
+uint32_t pkg_size, uint32_t proto_num,
+struct rte_pmd_i40e_proto_info *proto,
+enum rte_pmd_i40e_package_op op)
{
struct rte_pmd_i40e_ptype_mapping *ptype_mapping;
uint16_t port_id = dev->data->port_id;
@@ -11554,6 +11567,17 @@ i40e_update_customized_ptype(struct rte_eth_dev *dev,
uint8_t *pkg,
bool in_tunnel;
int ret;
+ if (op != RTE_PMD_I40E_PKG_OP_WR_ADD &&
+ op != RTE_PMD_I40E_PKG_OP_WR_DEL) {
+ PMD_DRV_LOG(ERR, "Unsupported operation.");
+ return -1;
+ }
+
+ if (op == RTE_PMD_I40E_PKG_OP_WR_DEL) {
+ rte_pmd_i40e_ptype_mapping_reset(port_id);
+ return 0;
+ }
+
/* get information about new ptype num */
ret = rte_pmd_i40e_get_ddp_info(pkg, pkg_size,
(uint8_t *)&ptype_num, sizeof(ptype_num),
@@ -11726,7 +11750,7 @@ i40e_update_customized_ptype(struct rte_eth_dev *dev,
uint8_t *pkg,
void
i40e_update_customized_info(struct rte_eth_dev *dev, uint8_t *pkg,
- uint32_t pkg_size)
+ uint32_t pkg_size, enum rte_pmd_i40e_package_op op)
{
struct i40e_pf *pf = I40E_DEV_PRIVATE_TO_PF(dev->data->dev_private);
uint32_t proto_num;
@@ -11735,6 +11759,12 @@ i40e_update_customized_info(struct rte_eth_dev *dev,
uint8_t *pkg,
uint32_t i;
int ret;
+ if (op != RTE_PMD_I40E_PKG_OP_WR_ADD &&
+ op != RTE_PMD_I40E_PKG_OP_WR_DEL) {
+ PMD_DRV_LOG(ERR, "Unsupported operation.");
+ return;
+ }
+
/* get information about protocol number */
ret = rte_pmd_i40e_get_ddp_info(pkg, pkg_size,
(uint8_t *)&proto_num, sizeof(proto_num),
@@ -11768,20 +11798,23 @@ i40e_update_customized_info(struct rte_eth_dev *dev,
uint8_t *pkg,
/* Check if GTP is supported. */
for (
[dpdk-dev] [pktgen PATCH] Fix a typo in app/pktgen.c
This patch fixes a typo in pktgen_main_rxtx_loop() method
of app/pktgen.c.
Signed-off-by: Rami Rosen
---
app/pktgen.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/app/pktgen.c b/app/pktgen.c
index 4904954..412585b 100644
--- a/app/pktgen.c
+++ b/app/pktgen.c
@@ -1263,7 +1263,7 @@ pktgen_main_rxtx_loop(uint8_t lid)
if (txcnt == 0)
rte_panic("No ports found for %d lcore\n", lid);
- printf("For TX found %d port(s) for lcore %d\n", rxcnt, lid);
+ printf("For TX found %d port(s) for lcore %d\n", txcnt, lid);
for(idx = 0; idx < txcnt; idx++) {
if (infos[idx] == NULL)
rte_panic("Invalid TX config: port at index %d not
found for %d lcore\n", idx, lid);
--
2.14.3
[dpdk-dev] [PATCH v1] doc: update deprecation notice of rte_devargs
The declaration and identification of devices will change in v18.05. Remove the precedent deprecation notice Add new one reflecting the planned changes more accurately, updated for v18.05. Signed-off-by: Gaetan Rivet --- doc/guides/rel_notes/deprecation.rst | 27 --- 1 file changed, 16 insertions(+), 11 deletions(-) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index d59ad5988..07312f59a 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -8,18 +8,23 @@ API and ABI deprecation notices are to be posted here. Deprecation Notices --- -* eal: several API and ABI changes are planned for ``rte_devargs`` in v18.02. - The format of device command line parameters will change. The bus will need - to be explicitly stated in the device declaration. The enum ``rte_devtype`` - was used to identify a bus and will disappear. - The structure ``rte_devargs`` will change. - The ``rte_devargs_list`` will be made private. - The following functions are deprecated starting from 17.08 and will either be - modified or removed in 18.02: +* eal: both declaring and identifying devices will be streamlined in v18.05. + New functions will appear to query a specific port from buses, classes of + device and device drivers. Device declaration will be made coherent with the + new scheme of device identification. + As such, ``rte_devargs`` device representation will change. - - ``rte_eal_devargs_add`` - - ``rte_eal_devargs_type_count`` - - ``rte_eal_parse_devargs_str``, replaced by ``rte_eal_devargs_parse`` + - removal of ``name`` and ``args`` fields. + - The enum ``rte_devtype`` was used to identify a bus and will disappear. + - The ``rte_devargs_list`` will be made private. + - Functions previously deprecated will change or disappear: + ++ ``rte_eal_devargs_add`` ++ ``rte_eal_devargs_type_count`` ++ ``rte_eal_parse_devargs_str``, replaced by ``rte_eal_devargs_parse`` ++ ``rte_eal_devargs_parse`` will change its format and use. ++ all ``rte_devargs`` related functions will be renamed, changing the + ``rte_eal_devargs_`` prefix to ``rte_devargs_``. * pci: Several exposed functions are misnamed. The following functions are deprecated starting from v17.11 and are replaced: -- 2.11.0
Re: [dpdk-dev] EAL reports "ot enough memory available on socket 0!"
On Tue, Feb 06, 2018 at 09:09:26PM +, Wiles, Keith wrote: > > > > On Feb 6, 2018, at 12:38 PM, Huertas García, Víctor > > wrote: > > > > Hi all, > > > > > > This is my first post in this mailing list. I am glad to become a member of > > this community. > > > > > > I am a newbie using DPDK and I have tried to compile and execute an example > > app called "l3fwd-acl". > > > > > > The DPDK command is DPDK_Test -c 0xf0 -n 2 --socket-mem 64 > > ran this command as root or used sudo correct? > > > > > but the application tells me the following: > > > > > > EAL: Detected 8 lcore(s) > > EAL: Probing VFIO support... > > EAL: VFIO support initialized > > EAL: Cannot obtain physical addresses: Success. Only vfio will function. > > EAL: Not enough memory available on socket 0! Requested: 64MB, available: > > 0MB > > EAL: FATAL: Cannot init memory > > > > EAL: Cannot init memory > > > > EAL: Error - exiting with code: 1 > > Cause: Invalid EAL parameters > > > > > > > > I don't know what else I can do to make this app run as I have reserved > > hugepages as the user guide tells as well as mounted the /mnt/huge folder. > > > > > > cat /proc/meminfo | grep Huge > > AnonHugePages:520192 kB > > HugePages_Total: 64 > > HugePages_Free: 64 > > HugePages_Rsvd:0 > > HugePages_Surp:0 > > Hugepagesize: 2048 kB > > I assume you added an entry into /etc/sysctl.conf and rebooted, just to make > sure the huge pages are allocated early in the boot process. > > I use 1G huge pages and I assume you are using 2M huge pages > > vm.nr_hugepages=32 # 32x2M is 64M > > I also disable randomize_va_space, which is not required for those tests. > > kernel.randomize_va_space=1 > > > > > > > > My machine is has this topology (only one Numa node is detected): > > > > > > udo usertools/cpu_layout.py > > [sudo] password for root: > > == > > Core and Socket Information (as reported by '/sys/devices/system/cpu') > > == > > > > cores = [0, 1, 2, 3] > > sockets = [0, 1] > > > > Socket 0Socket 1 > > > > Core 0 [0] [4] > > Core 1 [1] [5] > > Core 2 [2] [6] > > Core 3 [3] [7] > > The CPU layout shows two sockets and normally that means 2 numa node. > > I would change the command above —-socket-mem 32,32 (note: two ‘-‘ in front) > this command gives 32M socket 0 and 32M to socket 1 > > I have seen some funny memory configs, with huge pages if you do not use > /etc/sysctl.conf and reboot. Sometimes memory will be allocated to one socket. > > I hope that helps. > I would also suggest increasing the amount of memory reserved. DPDK can sometimes be quite memory hungry, so perhaps up the amount of hugepages reserved in the kernel. Also, if you are ok with DPDK using all the hugepages you have statically reserved, you can omit the --socket-mem parameter. /Bruce
Re: [dpdk-dev] [PATCH v2] net/i40e: fix issue during customized info update
> -Original Message-
> From: Xing, Beilei
> Sent: Wednesday, February 7, 2018 4:41 PM
> To: Zhang, Qi Z ; Wu, Jingjing
> Cc: dev@dpdk.org; sta...@dpdk.org
> Subject: [PATCH v2] net/i40e: fix issue during customized info update
>
> Customized info is updated without checking package
> operation - ADD or DEL, it only covers ADD operation
> currently. This patch adds process for DEL operation.
>
> Fixes: e163c18a15b0 ("net/i40e: update ptype and pctype info")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Beilei Xing
Acked-by: Jingjing Wu
[dpdk-dev] [Bug 12] Request for submit in Kernel Upstream
https://dpdk.org/tracker/show_bug.cgi?id=12 Qian (qian.q...@intel.com) changed: What|Removed |Added Status|CONFIRMED |RESOLVED CC||qian.q...@intel.com Resolution|--- |INVALID --- Comment #1 from Qian (qian.q...@intel.com) --- It's not a bug:). Some people have tried a lot to upstream KNI module to Linux kernel. You could check with Ferruh from Intel for more details. -- You are receiving this mail because: You are the assignee for the bug.
[dpdk-dev] [PATCH 18.05 v4] eal: add function to return number of detected sockets
During lcore scan, find maximum socket ID and store it. This will
break the ABI, so bump ABI version.
Signed-off-by: Anatoly Burakov
---
Notes:
v4:
- Remove backwards ABI compatibility, bump ABI instead
v3:
- Added ABI compatibility
v2:
- checkpatch changes
- check socket before deciding if the core is not to be used
lib/librte_eal/bsdapp/eal/Makefile| 2 +-
lib/librte_eal/common/eal_common_lcore.c | 37 +--
lib/librte_eal/common/include/rte_eal.h | 1 +
lib/librte_eal/common/include/rte_lcore.h | 8 +++
lib/librte_eal/linuxapp/eal/Makefile | 2 +-
lib/librte_eal/rte_eal_version.map| 9 +++-
6 files changed, 44 insertions(+), 15 deletions(-)
diff --git a/lib/librte_eal/bsdapp/eal/Makefile
b/lib/librte_eal/bsdapp/eal/Makefile
index dd455e6..ed1d17b 100644
--- a/lib/librte_eal/bsdapp/eal/Makefile
+++ b/lib/librte_eal/bsdapp/eal/Makefile
@@ -21,7 +21,7 @@ LDLIBS += -lgcc_s
EXPORT_MAP := ../../rte_eal_version.map
-LIBABIVER := 6
+LIBABIVER := 7
# specific to bsdapp exec-env
SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) := eal.c
diff --git a/lib/librte_eal/common/eal_common_lcore.c
b/lib/librte_eal/common/eal_common_lcore.c
index 7724fa4..827ddeb 100644
--- a/lib/librte_eal/common/eal_common_lcore.c
+++ b/lib/librte_eal/common/eal_common_lcore.c
@@ -28,6 +28,7 @@ rte_eal_cpu_init(void)
struct rte_config *config = rte_eal_get_configuration();
unsigned lcore_id;
unsigned count = 0;
+ unsigned int socket_id, max_socket_id = 0;
/*
* Parse the maximum set of logical cores, detect the subset of running
@@ -39,6 +40,19 @@ rte_eal_cpu_init(void)
/* init cpuset for per lcore config */
CPU_ZERO(&lcore_config[lcore_id].cpuset);
+ /* find socket first */
+ socket_id = eal_cpu_socket_id(lcore_id);
+ if (socket_id >= RTE_MAX_NUMA_NODES) {
+#ifdef RTE_EAL_ALLOW_INV_SOCKET_ID
+ socket_id = 0;
+#else
+ RTE_LOG(ERR, EAL, "Socket ID (%u) is greater than
RTE_MAX_NUMA_NODES (%d)\n",
+ socket_id, RTE_MAX_NUMA_NODES);
+ return -1;
+#endif
+ }
+ max_socket_id = RTE_MAX(max_socket_id, socket_id);
+
/* in 1:1 mapping, record related cpu detected state */
lcore_config[lcore_id].detected = eal_cpu_detected(lcore_id);
if (lcore_config[lcore_id].detected == 0) {
@@ -54,18 +68,7 @@ rte_eal_cpu_init(void)
config->lcore_role[lcore_id] = ROLE_RTE;
lcore_config[lcore_id].core_role = ROLE_RTE;
lcore_config[lcore_id].core_id = eal_cpu_core_id(lcore_id);
- lcore_config[lcore_id].socket_id = eal_cpu_socket_id(lcore_id);
- if (lcore_config[lcore_id].socket_id >= RTE_MAX_NUMA_NODES) {
-#ifdef RTE_EAL_ALLOW_INV_SOCKET_ID
- lcore_config[lcore_id].socket_id = 0;
-#else
- RTE_LOG(ERR, EAL, "Socket ID (%u) is greater than "
- "RTE_MAX_NUMA_NODES (%d)\n",
- lcore_config[lcore_id].socket_id,
- RTE_MAX_NUMA_NODES);
- return -1;
-#endif
- }
+ lcore_config[lcore_id].socket_id = socket_id;
RTE_LOG(DEBUG, EAL, "Detected lcore %u as "
"core %u on socket %u\n",
lcore_id, lcore_config[lcore_id].core_id,
@@ -79,5 +82,15 @@ rte_eal_cpu_init(void)
RTE_MAX_LCORE);
RTE_LOG(INFO, EAL, "Detected %u lcore(s)\n", config->lcore_count);
+ config->numa_node_count = max_socket_id + 1;
+ RTE_LOG(INFO, EAL, "Detected %u NUMA nodes\n", config->numa_node_count);
+
return 0;
}
+
+unsigned int
+rte_num_sockets(void)
+{
+ const struct rte_config *config = rte_eal_get_configuration();
+ return config->numa_node_count;
+}
diff --git a/lib/librte_eal/common/include/rte_eal.h
b/lib/librte_eal/common/include/rte_eal.h
index 08c6637..63fcc2e 100644
--- a/lib/librte_eal/common/include/rte_eal.h
+++ b/lib/librte_eal/common/include/rte_eal.h
@@ -57,6 +57,7 @@ enum rte_proc_type_t {
struct rte_config {
uint32_t master_lcore; /**< Id of the master lcore */
uint32_t lcore_count;/**< Number of available logical cores. */
+ uint32_t numa_node_count;/**< Number of detected NUMA nodes. */
uint32_t service_lcore_count;/**< Number of available service cores. */
enum rte_lcore_role_t lcore_role[RTE_MAX_LCORE]; /**< State of cores. */
diff --git a/lib/librte_eal/common/include/rte_lcore.h
b/lib/librte_eal/common/include/rte_lcore.h
index d84bcff..ddf4c64 100644
--- a/lib/librte_eal/common/include/rte_lcore.h
+++ b/lib/librte_eal/common/include/rte
[dpdk-dev] [PATCH 18.05 v4] Add function to return number of detected sockets
This patch is for 18.05 and implements changes referenced in the deprecation notice[1]. (not yet merged as of this writing) This patchset breaks the EAL ABI and bumps its version. This is arguably OK as memory changes will change a lot in EAL and thus likely break ABI anyway. However, two other alternative implementations are possible: 1) local static variable recording number of detected sockets. This is arguably less clean approach, but will not break the ABI and will have relatively little impact on the codebase. 2) keeping ABI compatibility, as shown in v3 of this patch [2]. My preference would be to keep this one. [1] http://dpdk.org/dev/patchwork/patch/33853/ [2] http://dpdk.org/dev/patchwork/patch/34994/ Anatoly Burakov (1): eal: add function to return number of detected sockets lib/librte_eal/bsdapp/eal/Makefile| 2 +- lib/librte_eal/common/eal_common_lcore.c | 37 +-- lib/librte_eal/common/include/rte_eal.h | 1 + lib/librte_eal/common/include/rte_lcore.h | 8 +++ lib/librte_eal/linuxapp/eal/Makefile | 2 +- lib/librte_eal/rte_eal_version.map| 9 +++- 6 files changed, 44 insertions(+), 15 deletions(-) -- 2.7.4
Re: [dpdk-dev] [PATCH] doc: add ABI change notice for numa_node_count in eal
-Original Message- > Date: Tue, 23 Jan 2018 10:39:58 + > From: "Mcnamara, John" > To: "Burakov, Anatoly" , "dev@dpdk.org" > > CC: Neil Horman , "Kovacevic, Marko" > > Subject: Re: [dpdk-dev] [PATCH] doc: add ABI change notice for > numa_node_count in eal > > > > > -Original Message- > > From: Burakov, Anatoly > > Sent: Tuesday, January 16, 2018 5:54 PM > > To: dev@dpdk.org > > Cc: Neil Horman ; Mcnamara, John > > ; Kovacevic, Marko > > Subject: [PATCH] doc: add ABI change notice for numa_node_count in eal > > > > There will be a new function added in v18.05 that will return number of > > detected sockets, which will change the ABI. > > > > Signed-off-by: Anatoly Burakov > > --- > > doc/guides/rel_notes/deprecation.rst | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/doc/guides/rel_notes/deprecation.rst > > b/doc/guides/rel_notes/deprecation.rst > > index 13e8543..9662150 100644 > > --- a/doc/guides/rel_notes/deprecation.rst > > +++ b/doc/guides/rel_notes/deprecation.rst > > @@ -8,6 +8,8 @@ API and ABI deprecation notices are to be posted here. > > Deprecation Notices > > --- > > > > +* eal: new ``numa_node_count`` member will be added to ``rte_config`` > > +structure in v18.05. > > * eal: several API and ABI changes are planned for ``rte_devargs`` in > > v18.02. > > In general it is best to leave a blank line between the bullet points. But > that > doesn't affect the rendering so: > > Acked-by: John McNamara Acked-by: Jerin Jacob > >
Re: [dpdk-dev] [PATCH v2] doc: add deprecation notice for memory hotplug changes
-Original Message- > Date: Mon, 5 Feb 2018 11:47:42 + > From: Bruce Richardson > To: Anatoly Burakov > CC: dev@dpdk.org, Neil Horman , John McNamara > , Marko Kovacevic > Subject: Re: [dpdk-dev] [PATCH v2] doc: add deprecation notice for memory > hotplug changes > User-Agent: Mutt/1.9.1 (2017-09-22) > > On Thu, Jan 18, 2018 at 10:32:28AM +, Anatoly Burakov wrote: > > Due to coming changes outlined in memory hotplug RFC, there will > > be several API/ABI changes. > > > > Signed-off-by: Anatoly Burakov > > --- > Acked-by: Bruce Richardson Acked-by: Jerin Jacob >
[dpdk-dev] [Bug 11] crypto_preformance_test: core dumped
https://dpdk.org/tracker/show_bug.cgi?id=11 Pablo de Lara (pablo.de.lara.gua...@intel.com) changed: What|Removed |Added Status|CONFIRMED |RESOLVED CC||pablo.de.lara.guarch@intel. ||com Version|unspecified |17.11 Resolution|--- |FIXED --- Comment #3 from Pablo de Lara (pablo.de.lara.gua...@intel.com) --- Patch http://dpdk.org/dev/patchwork/patch/34355/ fixed the issue. -- You are receiving this mail because: You are the assignee for the bug.
Re: [dpdk-dev] [PATCH v2] buildtools: output build failure reason to stderr
On Wed, Feb 07, 2018 at 08:24:00AM +, Andrew Rybchenko wrote:
> If build fails because of failed experimental check and stdout is
> redirected to /dev/null, it is absolutely unclear why build fails.
>
> Fixes: a4bcd61de82d ("buildtools: add script to check experimental API
> exports")
>
> Signed-off-by: Andrew Rybchenko
> ---
> v2:
> - use <<- to keep indentation of the message
>
> buildtools/check-experimental-syms.sh | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/buildtools/check-experimental-syms.sh
> b/buildtools/check-experimental-syms.sh
> index 7d21de3..5bc8cda 100755
> --- a/buildtools/check-experimental-syms.sh
> +++ b/buildtools/check-experimental-syms.sh
> @@ -22,9 +22,11 @@ do
> IN_EXP=$?
> if [ $IN_TEXT -eq 0 -a $IN_EXP -ne 0 ]
> then
> - echo "$SYM is not flagged as experimental"
> - echo "but is listed in version map"
> - echo "Please add __rte_experimental to the definition of $SYM"
> + cat >&2 <<- END_OF_MESSAGE
> + $SYM is not flagged as experimental
> + but is listed in version map
> + Please add __rte_experimental to the definition of $SYM
> + END_OF_MESSAGE
> exit 1
> fi
> done
> --
> 2.7.4
>
>
Acked-by: Neil Horman
Re: [dpdk-dev] [PATCH v1] doc: update deprecation notice of rte_devargs
On Wednesday 07 February 2018 02:56 PM, Gaetan Rivet wrote: The declaration and identification of devices will change in v18.05. Remove the precedent deprecation notice Add new one reflecting the planned changes more accurately, updated for v18.05. Signed-off-by: Gaetan Rivet --- Acked-By: Shreyansh Jain
Re: [dpdk-dev] [PATCH] doc/ip_pipeline.rst: update f_post_init and correct f_track
> Update f_post_init for pipeline frontend. > Move f_track from pipeline backend to pipeline frontend. > > Signed-off-by: longtb5 > > doc/guides/sample_app_ug/ip_pipeline.rst | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) Everything Is ok formatting wise and info the only I see is the Subject line: doc/ip_pipeline.rst: update f_post_init and correct f_track Command to check: ./devtools/check-git-log.sh -1 Running git check log on HEAD~1: 34835 == Wrong headline format: doc/ip_pipeline.rst: update f_post_init and correct f_track Once its corrected you can add my ack. Acked-by: Marko Kovacevic
[dpdk-dev] [PATCH] net/mlx5: revert support in IPv4 time-to-live filter
Nor upstream kernel nor MLNX_OFED support such filter.
Reverts commit 0fb2c9842b20 ("net/mlx5: support IPv4 time-to-live filter")
Cc: nelio.laranje...@6wind.com
Signed-off-by: Shahaf Shuler
---
doc/guides/rel_notes/release_18_02.rst | 1 -
drivers/net/mlx5/mlx5_flow.c | 1 -
2 files changed, 2 deletions(-)
diff --git a/doc/guides/rel_notes/release_18_02.rst
b/doc/guides/rel_notes/release_18_02.rst
index 32067969f..0d4630335 100644
--- a/doc/guides/rel_notes/release_18_02.rst
+++ b/doc/guides/rel_notes/release_18_02.rst
@@ -94,7 +94,6 @@ New Features
* Improved multi-segment packet performance.
* Changed driver name to use the PCI address to be compatible with OVS-DPDK
APIs.
* Extended statistics for physical port packet/byte counters.
- * Supported IPv4 time-to-live filter.
* Converted to the new offloads API.
* Supported device removal check operation.
diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
index 822705060..f88ece123 100644
--- a/drivers/net/mlx5/mlx5_flow.c
+++ b/drivers/net/mlx5/mlx5_flow.c
@@ -313,7 +313,6 @@ static const struct mlx5_flow_items mlx5_flow_items[] = {
.dst_addr = -1,
.type_of_service = -1,
.next_proto_id = -1,
- .time_to_live = -1,
},
},
.default_mask = &rte_flow_item_ipv4_mask,
--
2.12.0
[dpdk-dev] [PATCH v2] net/mlx5: revert support in IPv4 time-to-live filter
Neither upstream kernel nor MLNX_OFED support such filter.
There is no point announcing this feature.
Reverts commit 0fb2c9842b20 ("net/mlx5: support IPv4 time-to-live filter")
Cc: nelio.laranje...@6wind.com
Signed-off-by: Shahaf Shuler
---
On v2:
- Changed commit log.
---
doc/guides/rel_notes/release_18_02.rst | 1 -
drivers/net/mlx5/mlx5_flow.c | 1 -
2 files changed, 2 deletions(-)
diff --git a/doc/guides/rel_notes/release_18_02.rst
b/doc/guides/rel_notes/release_18_02.rst
index 32067969f..0d4630335 100644
--- a/doc/guides/rel_notes/release_18_02.rst
+++ b/doc/guides/rel_notes/release_18_02.rst
@@ -94,7 +94,6 @@ New Features
* Improved multi-segment packet performance.
* Changed driver name to use the PCI address to be compatible with OVS-DPDK
APIs.
* Extended statistics for physical port packet/byte counters.
- * Supported IPv4 time-to-live filter.
* Converted to the new offloads API.
* Supported device removal check operation.
diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
index 822705060..f88ece123 100644
--- a/drivers/net/mlx5/mlx5_flow.c
+++ b/drivers/net/mlx5/mlx5_flow.c
@@ -313,7 +313,6 @@ static const struct mlx5_flow_items mlx5_flow_items[] = {
.dst_addr = -1,
.type_of_service = -1,
.next_proto_id = -1,
- .time_to_live = -1,
},
},
.default_mask = &rte_flow_item_ipv4_mask,
--
2.12.0
Re: [dpdk-dev] EAL reports "ot enough memory available on socket 0!"
Thanks Bruce and Keith, I have run the application with root privileges and at least the memory error reported by EAL has been solved. Thanks a lot! Now it runs, although it complains about other issues (it doesn't detect interfaces despite the fact I have associated them with vfio-pci driver using dpdk-setup.sh script) but I think I can handle it. Furthermore, I managed to finally enable NUMA nodes in my architecture. I tell you what I did just in case someone has found the same problem. I discovered in the BIOS a parameter in the NorthBridge Chipset Configuration called "Crystal Beach/DMA" which was disabled. I enabled it and appeared an additional hidden parameter called "Crystal Beach /DCA" which, I don't what does it mean, but I left it disabled. Then I restarted the machine and the numactl --hardware showed me two marvelous NUMA nodes (one for each socket as Keith told me). I just have to guess to which NUMA node the NIC cards are associated in order to have full hardware affinity. I have found plenty of info about how to know it. In the next experimentation I will try to increase the number of hugepages to use but I have one question. If for example the AnnonHugePages returned by the /proc/meminfo tells me that there are 210944 kB and the size of the HugePageSize is 2048kB, does the maximum number of hugepages configurable equivalent to dividing 210944 / 2048 = 103 ? If I configured more than 103 it would generate an error? Thanks for your quick answer. BTW I will tell you how I managed to configure the Eclipse IDE to run in Debug mode the DPDK application with root privileges. Maybe the rest of developer community already know it but I publish it anyway as I think that telling how to use Eclipse and DPDK is very interesting for future developers (a tutorial on how to configure Eclipse and DPDK for developing purposes is something that would be very helpful and I missed it in the DPDK web page). Step 1: tell the Linux not to ask you the root password if you run the "sudo gdb" in the Debug environment . $ sudo visudo Add after the line 'root ALL=(ALL) ALL' the following line ALL=(root) NOPASSWD:/usr/bin/gdb Step 2: Configure the "Debug Configurations" section at Eclipse. Once you have added your application to be executed in debug mode at Eclipse and generated a particular Debug configuration for it, you have to go: Debug Configurations -> "Your App" -> “Debugger” Tag -> “Main” Tag at "Debugger Options" At "GDB debugger" field you have put sudo gdb instead of just gdb Apply it and that's it. Regards, Víctor Huertas García Senior Engineer Space - Communication Systems -Mensaje original- De: Bruce Richardson [mailto:bruce.richard...@intel.com] Enviado el: miércoles, 07 de febrero de 2018 10:33 Para: Wiles, Keith CC: Huertas García, Víctor; dev@dpdk.org Asunto: Re: [dpdk-dev] EAL reports "ot enough memory available on socket 0!" On Tue, Feb 06, 2018 at 09:09:26PM +, Wiles, Keith wrote: > > > > On Feb 6, 2018, at 12:38 PM, Huertas García, Víctor > > wrote: > > > > Hi all, > > > > > > This is my first post in this mailing list. I am glad to become a member of > > this community. > > > > > > I am a newbie using DPDK and I have tried to compile and execute an example > > app called "l3fwd-acl". > > > > > > The DPDK command is DPDK_Test -c 0xf0 -n 2 --socket-mem 64 > > ran this command as root or used sudo correct? > > > > > but the application tells me the following: > > > > > > EAL: Detected 8 lcore(s) > > EAL: Probing VFIO support... > > EAL: VFIO support initialized > > EAL: Cannot obtain physical addresses: Success. Only vfio will function. > > EAL: Not enough memory available on socket 0! Requested: 64MB, > > available: 0MB > > EAL: FATAL: Cannot init memory > > > > EAL: Cannot init memory > > > > EAL: Error - exiting with code: 1 > > Cause: Invalid EAL parameters > > > > > > > > I don't know what else I can do to make this app run as I have reserved > > hugepages as the user guide tells as well as mounted the /mnt/huge folder. > > > > > > cat /proc/meminfo | grep Huge > > AnonHugePages:520192 kB > > HugePages_Total: 64 > > HugePages_Free: 64 > > HugePages_Rsvd:0 > > HugePages_Surp:0 > > Hugepagesize: 2048 kB > > I assume you added an entry into /etc/sysctl.conf and rebooted, just to make > sure the huge pages are allocated early in the boot process. > > I use 1G huge pages and I assume you are using 2M huge pages > > vm.nr_hugepages=32 # 32x2M is 64M > > I also disable randomize_va_space, which is not required for those tests. > > kernel.randomize_va_space=1 > > > > > > > > My machine is has this topology (only one Numa node is detected): > > > > > > udo usertools/cpu_layout.py > > [sudo] password for root: > > > > == Core and Socket Information (as reported by > > '/sys/devices/system/cpu') > > ===
Re: [dpdk-dev] [pktgen PATCH] Fix a typo in app/pktgen.c
> On Feb 7, 2018, at 10:15 AM, Rosen, Rami wrote:
>
> This patch fixes a typo in pktgen_main_rxtx_loop() method
> of app/pktgen.c.
>
> Signed-off-by: Rami Rosen
> ---
> app/pktgen.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/app/pktgen.c b/app/pktgen.c
> index 4904954..412585b 100644
> --- a/app/pktgen.c
> +++ b/app/pktgen.c
> @@ -1263,7 +1263,7 @@ pktgen_main_rxtx_loop(uint8_t lid)
> if (txcnt == 0)
> rte_panic("No ports found for %d lcore\n", lid);
>
> - printf("For TX found %d port(s) for lcore %d\n", rxcnt, lid);
> + printf("For TX found %d port(s) for lcore %d\n", txcnt, lid);
Thanks I will apply it.
> for(idx = 0; idx < txcnt; idx++) {
> if (infos[idx] == NULL)
> rte_panic("Invalid TX config: port at index %d not
> found for %d lcore\n", idx, lid);
> --
> 2.14.3
>
Regards,
Keith
Re: [dpdk-dev] [PATCH] net/tap: fix res cleanup when tap create fails
Acked-by: Pascal Mazon
On 05/02/2018 17:17, Moti Haimovsky wrote:
> This patch complements the partial cleanup done inside
> eth_dev_tap_create when the routine failed.
> Such a failure left a non-functional device attached to the system.
>
> Fixes: 050fe6e9ff97 ("drivers/net: use ethdev allocation helper for vdev")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Moti Haimovsky
> ---
> drivers/net/tap/rte_eth_tap.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.c
> index dc3847e..8931dec 100644
> --- a/drivers/net/tap/rte_eth_tap.c
> +++ b/drivers/net/tap/rte_eth_tap.c
> @@ -1347,13 +1347,13 @@ enum ioctl_mode {
> data = rte_zmalloc_socket(tap_name, sizeof(*data), 0, numa_node);
> if (!data) {
> RTE_LOG(ERR, PMD, "TAP Failed to allocate data\n");
> - goto error_exit;
> + goto error_exit_nodev;
> }
>
> dev = rte_eth_vdev_allocate(vdev, sizeof(*pmd));
> if (!dev) {
> RTE_LOG(ERR, PMD, "TAP Unable to allocate device struct\n");
> - goto error_exit;
> + goto error_exit_nodev;
> }
>
> pmd = dev->data->dev_private;
> @@ -1524,6 +1524,11 @@ enum ioctl_mode {
> tap_flow_implicit_flush(pmd, NULL);
>
> error_exit:
> + if (pmd->ioctl_sock > 0)
> + close(pmd->ioctl_sock);
> + rte_eth_dev_release_port(dev);
> +
> +error_exit_nodev:
> RTE_LOG(ERR, PMD, "TAP Unable to initialize %s\n",
> rte_vdev_device_name(vdev));
>
Re: [dpdk-dev] [PATCH] doc: update i40e guide
> -Original Message- > From: Xing, Beilei > Sent: Sunday, February 4, 2018 3:41 AM > To: Mcnamara, John ; dev@dpdk.org; Wu, Jingjing > > Cc: sta...@dpdk.org > Subject: [PATCH] doc: update i40e guide > > This patch updates the i40e guide with new device parameter support-multi- > driver. > > Signed-off-by: Beilei Xing Acked-by: John McNamara
Re: [dpdk-dev] [PATCH 1/8] vhost: add security model documentation to vhost_user.c
> -Original Message- > From: Stefan Hajnoczi [mailto:stefa...@redhat.com] > Sent: Tuesday, February 6, 2018 2:23 PM > To: Kovacevic, Marko > Cc: dev@dpdk.org; Maxime Coquelin ; Yuanhan > Liu ; Mcnamara, John > Subject: Re: [dpdk-dev] [PATCH 1/8] vhost: add security model > documentation to vhost_user.c > > On Tue, Feb 06, 2018 at 01:26:13PM +, Kovacevic, Marko wrote: > > > Input validation is not applied consistently in vhost_user.c. This > > > suggests that not everyone has the same security model in mind when > > > working on the code. > > > > > > Make the security model explicit so that everyone can understand and > > > follow the same model when modifying the code. > > > > > > Signed-off-by: Stefan Hajnoczi > > > --- > > > lib/librte_vhost/vhost_user.c | 17 + > > > 1 file changed, 17 insertions(+) > > > > > > diff --git a/lib/librte_vhost/vhost_user.c > > > b/lib/librte_vhost/vhost_user.c > > > > <...> > > > > This is a useful comment but I don't know if it makes sense to include > it in the vhost_user.c file. > > > > Particularly at the top where it looks like a general descriptive > comment for the file. > > > > It would probably be better in the vhost-user section of the > programmer's guide: > > > > http://dpdk.org/doc/guides/prog_guide/vhost_lib.html > > That is the public API documentation for users of the library. They don't > parse VhostUserMsg so I'm not sure the comment would be relevant there. Hi, If it is public API documentation then it should probably be in a .h file in doxygen format. I'm in favour of the information being added, and thanks for that, just not in that position in that file. John
Re: [dpdk-dev] [PATCH] examples/cmdline: update copyright and license
On 1/23/2018 4:43 PM, Lee Daly wrote: > This updates the license on files in examples to be the standard > BSD-3-Clause license used for the rest of DPDK, > bringing the files in compliance with the DPDK licensing policy. > > Signed-off-by: Lee Daly Acked-by: Ferruh Yigit
Re: [dpdk-dev] [PATCH] examples: update copyrights and license
On 1/24/2018 1:27 PM, Lee Daly wrote: > This updates the Intel and Cavium license on files in examples to be > the standard BSD-3-Clause license used for the rest of DPDK, > bringing the files in compliance with the DPDK licensing policy. > > Signed-off-by: Lee Daly Acked-by: Ferruh Yigit
Re: [dpdk-dev] [PATCH] examples/l3fwd: update copyright and licenses
On 1/23/2018 4:45 PM, Lee Daly wrote: > This updates the Intel and Linaro Limited license on files in examples > to be the standard BSD-3-Clause license used for the rest of DPDK, > bringing the files in compliance with the DPDK licensing policy. > > Signed-off-by: Lee Daly Acked-by: Ferruh Yigit
Re: [dpdk-dev] [PATCH] examples/l3fwd: update copyright and license
On 1/23/2018 4:45 PM, Lee Daly wrote: > This updates the Intel and IBM license on files in examples to be the standard > BSD-3-Clause license used for the rest of DPDK, > bringing the files in compliance with the DPDK licensing policy. > > Signed-off-by: Lee Daly Acked-by: Ferruh Yigit
Re: [dpdk-dev] [PATCH 1/8] vhost: add security model documentation to vhost_user.c
Hi John, On 02/07/2018 05:10 PM, Mcnamara, John wrote: -Original Message- From: Stefan Hajnoczi [mailto:stefa...@redhat.com] Sent: Tuesday, February 6, 2018 2:23 PM To: Kovacevic, Marko Cc: dev@dpdk.org; Maxime Coquelin ; Yuanhan Liu ; Mcnamara, John Subject: Re: [dpdk-dev] [PATCH 1/8] vhost: add security model documentation to vhost_user.c On Tue, Feb 06, 2018 at 01:26:13PM +, Kovacevic, Marko wrote: Input validation is not applied consistently in vhost_user.c. This suggests that not everyone has the same security model in mind when working on the code. Make the security model explicit so that everyone can understand and follow the same model when modifying the code. Signed-off-by: Stefan Hajnoczi --- lib/librte_vhost/vhost_user.c | 17 + 1 file changed, 17 insertions(+) diff --git a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c <...> This is a useful comment but I don't know if it makes sense to include it in the vhost_user.c file. Particularly at the top where it looks like a general descriptive comment for the file. It would probably be better in the vhost-user section of the programmer's guide: http://dpdk.org/doc/guides/prog_guide/vhost_lib.html That is the public API documentation for users of the library. They don't parse VhostUserMsg so I'm not sure the comment would be relevant there. Hi, If it is public API documentation then it should probably be in a .h file in doxygen format. I'm in favour of the information being added, and thanks for that, just not in that position in that file. This is not part of the API but purely vhost-user lib internals, so I think this is the right place for this comment. It is more likely to be seen by the developer here than in a separate file. Cheers, Maxime John
Re: [dpdk-dev] [PATCH] examples: update copyrights and license
-Original Message- > Date: Wed, 24 Jan 2018 13:27:16 + > From: Lee Daly > To: john.mcnam...@intel.com, pablo.de.lara.gua...@intel.com, > harry.van.haa...@intel.com, bruce.richard...@intel.com > CC: dev@dpdk.org, Lee Daly > Subject: [dpdk-dev] [PATCH] examples: update copyrights and license > X-Mailer: git-send-email 2.7.4 > > This updates the Intel and Cavium license on files in examples to be > the standard BSD-3-Clause license used for the rest of DPDK, > bringing the files in compliance with the DPDK licensing policy. > > Signed-off-by: Lee Daly Acked-by: Jerin Jacob > --- > .../performance-thread/common/arch/x86/stack.h | 30 > +- > 1 file changed, 1 insertion(+), 29 deletions(-) > > diff --git a/examples/performance-thread/common/arch/x86/stack.h > b/examples/performance-thread/common/arch/x86/stack.h > index 98723ba..e1e35da 100644 > --- a/examples/performance-thread/common/arch/x86/stack.h > +++ b/examples/performance-thread/common/arch/x86/stack.h > @@ -1,35 +1,7 @@ > -/*- > - * BSD LICENSE > - * > +/* SPDX-License-Identifier: BSD-3-Clause > * Copyright(c) 2015 Intel Corporation. All rights reserved. > * Copyright(c) Cavium, Inc. 2017. > * All rights reserved. > - * > - * Redistribution and use in source and binary forms, with or without > - * modification, are permitted provided that the following conditions > - * are met: > - * > - * * Redistributions of source code must retain the above copyright > - * notice, this list of conditions and the following disclaimer. > - * * Redistributions in binary form must reproduce the above copyright > - * notice, this list of conditions and the following disclaimer in > - * the documentation and/or other materials provided with the > - * distribution. > - * * Neither the name of Intel Corporation nor the names of its > - * contributors may be used to endorse or promote products derived > - * from this software without specific prior written permission. > - * > - * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS > - * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT > - * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR > - * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT > - * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, > - * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT > - * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, > - * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY > - * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT > - * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE > - * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. > */ > > /* > -- > 2.7.4 >
[dpdk-dev] [PATCH v3] examples/ip_pipeline: update copyright and license
This updates the Intel and Oliver Matz licenses on a file in examples to be the standard BSD-3-Clause license used for the rest of DPDK, bringing the files in compliance with the DPDK licensing policy. --- V2: Combined Intel and Olivier Matz license blocks V3: Removed all right reserved from Intel license Signed-off-by: Lee Daly Acked-by: Ferruh Yigit --- examples/ip_pipeline/parser.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/examples/ip_pipeline/parser.c b/examples/ip_pipeline/parser.c index 42d8d2a..0901e9c 100644 --- a/examples/ip_pipeline/parser.c +++ b/examples/ip_pipeline/parser.c @@ -1,5 +1,5 @@ /* SPDX-License-Identifier: BSD-3-Clause - * Copyright(c) 2016 Intel Corporation. All rights reserved. + * Copyright(c) 2016 Intel Corporation. * Copyright (c) 2009, Olivier MATZ * All rights reserved. */ -- 2.7.4
[dpdk-dev] [PATCH v4] examples/ip_pipeline: update copyright and license
This updates the Intel and Oliver Matz licenses on a file in examples to be the standard BSD-3-Clause license used for the rest of DPDK, bringing the files in compliance with the DPDK licensing policy. --- V2: Combined Intel and Olivier Matz license blocks V3: Removed all right reserved from Intel license V4: Merge V2 and V3 Signed-off-by: Lee Daly Acked-by: Ferruh Yigit --- examples/ip_pipeline/parser.c | 60 ++- 1 file changed, 2 insertions(+), 58 deletions(-) diff --git a/examples/ip_pipeline/parser.c b/examples/ip_pipeline/parser.c index 689e206..0901e9c 100644 --- a/examples/ip_pipeline/parser.c +++ b/examples/ip_pipeline/parser.c @@ -1,63 +1,7 @@ -/*- - * BSD LICENSE - * - * Copyright(c) 2016 Intel Corporation. All rights reserved. - * All rights reserved. - * - * Redistribution and use in source and binary forms, with or without - * modification, are permitted provided that the following conditions - * are met: - * - * * Redistributions of source code must retain the above copyright - * notice, this list of conditions and the following disclaimer. - * * Redistributions in binary form must reproduce the above copyright - * notice, this list of conditions and the following disclaimer in - * the documentation and/or other materials provided with the - * distribution. - * * Neither the name of Intel Corporation nor the names of its - * contributors may be used to endorse or promote products derived - * from this software without specific prior written permission. - * - * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS - * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT - * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR - * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT - * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, - * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT - * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, - * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY - * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE - * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - */ - -/* - * For my_ether_aton() function: - * +/* SPDX-License-Identifier: BSD-3-Clause + * Copyright(c) 2016 Intel Corporation. * Copyright (c) 2009, Olivier MATZ * All rights reserved. - * Redistribution and use in source and binary forms, with or without - * modification, are permitted provided that the following conditions are met: - * - * * Redistributions of source code must retain the above copyright - * notice, this list of conditions and the following disclaimer. - * * Redistributions in binary form must reproduce the above copyright - * notice, this list of conditions and the following disclaimer in the - * documentation and/or other materials provided with the distribution. - * * Neither the name of the University of California, Berkeley nor the - * names of its contributors may be used to endorse or promote products - * derived from this software without specific prior written permission. - * - * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND ANY - * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED - * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE - * DISCLAIMED. IN NO EVENT SHALL THE REGENTS AND CONTRIBUTORS BE LIABLE FOR ANY - * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES - * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; - * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND - * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS - * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ /* -- 2.7.4
Re: [dpdk-dev] [PATCH 1/8] vhost: add security model documentation to vhost_user.c
> -Original Message- > From: Maxime Coquelin [mailto:maxime.coque...@redhat.com] > Sent: Wednesday, February 7, 2018 4:18 PM > To: Mcnamara, John ; Stefan Hajnoczi > ; Kovacevic, Marko > Cc: dev@dpdk.org; Yuanhan Liu > Subject: Re: [dpdk-dev] [PATCH 1/8] vhost: add security model > documentation to vhost_user.c > > Hi John, > > On 02/07/2018 05:10 PM, Mcnamara, John wrote: > > > > > >> -Original Message- > >> From: Stefan Hajnoczi [mailto:stefa...@redhat.com] > >> Sent: Tuesday, February 6, 2018 2:23 PM > >> To: Kovacevic, Marko > >> Cc: dev@dpdk.org; Maxime Coquelin ; > >> Yuanhan Liu ; Mcnamara, John > >> > >> Subject: Re: [dpdk-dev] [PATCH 1/8] vhost: add security model > >> documentation to vhost_user.c > >> > >> On Tue, Feb 06, 2018 at 01:26:13PM +, Kovacevic, Marko wrote: > Input validation is not applied consistently in vhost_user.c. This > suggests that not everyone has the same security model in mind when > working on the code. > > Make the security model explicit so that everyone can understand > and follow the same model when modifying the code. > > Signed-off-by: Stefan Hajnoczi > --- > lib/librte_vhost/vhost_user.c | 17 + > 1 file changed, 17 insertions(+) > > diff --git a/lib/librte_vhost/vhost_user.c > b/lib/librte_vhost/vhost_user.c > >>> > >>> <...> > >>> > >>> This is a useful comment but I don't know if it makes sense to > >>> include > >> it in the vhost_user.c file. > >>> > >>> Particularly at the top where it looks like a general descriptive > >> comment for the file. > >>> > >>> It would probably be better in the vhost-user section of the > >> programmer's guide: > >>> > >>> http://dpdk.org/doc/guides/prog_guide/vhost_lib.html > >> > >> That is the public API documentation for users of the library. They > >> don't parse VhostUserMsg so I'm not sure the comment would be relevant > there. > > > > Hi, > > > > If it is public API documentation then it should probably be in a .h > > file in doxygen format. > > > > I'm in favour of the information being added, and thanks for that, > > just not in that position in that file. > > This is not part of the API but purely vhost-user lib internals, so I > think this is the right place for this comment. > > It is more likely to be seen by the developer here than in a separate > file. Ok. In that case: Acked-by: John McNamara
[dpdk-dev] [PATCH v1] doc: update dpdk proc info limitations
Updated the limitations for dpdk-procinfo to inform user of the proper use. To avoid failures and build issues Signed-off-by: Marko Kovacevic --- doc/guides/tools/proc_info.rst | 26 +- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/doc/guides/tools/proc_info.rst b/doc/guides/tools/proc_info.rst index b35b02f..d5b5ed6 100644 --- a/doc/guides/tools/proc_info.rst +++ b/doc/guides/tools/proc_info.rst @@ -10,17 +10,6 @@ statistics, resetting port statistics and printing DPDK memory information. This application extends the original functionality that was supported by dump_cfg. -.. note:: - -dpdk-procinfo should run alongside primary process with same DPDK version. - -.. note:: - - When running `dpdk-procinfo`` with shared library mode, it is required to - pass the same NIC PMD libraries as used for the primary application. Any - mismatch in PMD library arguments can lead to undefined behaviour and results - affecting primary application too. - Running the Application --- The application has a number of command line options: @@ -52,6 +41,17 @@ If no port mask is specified xstats are reset for all DPDK ports. **-m**: Print DPDK memory information. -.. note:: +Limitations +--- + +* dpdk-procinfo should run alongside primary process with same DPDK version. + +* When running ``dpdk-procinfo`` with shared library mode, it is required to + pass the same NIC PMD libraries as used for the primary application. Any + mismatch in PMD library arguments can lead to undefined behaviour and results + affecting primary application too. + +* Stats retrieval using ``dpdk-procinfo`` is not supported for virtual devices like PCAP and TAP. - Stats retrieval using ``dpdk-procinfo`` is not supported for virtual devices like PCAP and TAP. +* Since default DPDK EAL arguments for ``dpdk-procinfo`` are ``-c1, -n4 & --proc-type=secondary``, + It is not expected that the user passes any EAL arguments. -- 2.9.5
[dpdk-dev] [PATCH] net/qede: fix tunnel init params
From: Harish Patil
Add the missing VF check to initialize tunnel params correctly.
Fixes: dd28bc8c6ef4 ("net/qede: fix VF port creation sequence")
Cc: sta...@dpdk.org
Signed-off-by: Harish Patil
---
drivers/net/qede/qede_ethdev.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/net/qede/qede_ethdev.c b/drivers/net/qede/qede_ethdev.c
index 46e0e36..a91f436 100644
--- a/drivers/net/qede/qede_ethdev.c
+++ b/drivers/net/qede/qede_ethdev.c
@@ -3123,16 +3123,22 @@ static int qede_common_dev_init(struct rte_eth_dev
*eth_dev, bool is_vf)
adapter->vport_started = false;
/* VF tunnel offloads is enabled by default in PF driver */
- adapter->vxlan.enable = true;
adapter->vxlan.num_filters = 0;
- adapter->vxlan.filter_type = ETH_TUNNEL_FILTER_IMAC |
-ETH_TUNNEL_FILTER_IVLAN;
- adapter->vxlan.udp_port = QEDE_VXLAN_DEF_PORT;
- adapter->geneve.enable = true;
- adapter->vxlan.num_filters = 0;
- adapter->vxlan.filter_type = ETH_TUNNEL_FILTER_IMAC |
-ETH_TUNNEL_FILTER_IVLAN;
- adapter->vxlan.udp_port = QEDE_GENEVE_DEF_PORT;
+ adapter->geneve.num_filters = 0;
+ if (is_vf) {
+ adapter->vxlan.enable = true;
+ adapter->vxlan.filter_type = ETH_TUNNEL_FILTER_IMAC |
+ETH_TUNNEL_FILTER_IVLAN;
+ adapter->vxlan.udp_port = QEDE_VXLAN_DEF_PORT;
+ adapter->geneve.enable = true;
+
+ adapter->geneve.filter_type = ETH_TUNNEL_FILTER_IMAC |
+ ETH_TUNNEL_FILTER_IVLAN;
+ adapter->geneve.udp_port = QEDE_GENEVE_DEF_PORT;
+ } else {
+ adapter->vxlan.enable = false;
+ adapter->geneve.enable = false;
+ }
DP_INFO(edev, "MAC address : %02x:%02x:%02x:%02x:%02x:%02x\n",
adapter->primary_mac.addr_bytes[0],
--
1.7.10.3
Re: [dpdk-dev] [PATCH] net/bnxt: fix packet type
Hi,
On Tue, Feb 06, 2018 at 03:23:34PM -0800, Ajit Khaparde wrote:
> On Tue, Feb 6, 2018 at 9:07 AM, Olivier Matz wrote:
>
> > The hw flags are not read correctly: the defines
> > RX_PKT_CMPL_FLAGS_ITYPE_* are not bits but values, so the should not be
> > tested with if (value & X) but with if ((value & MASK) == X).
> > This was resulting in a wrong packet type.
> >
> > For instance, an IPv4/ICMP packet was returning a value of 7 for
> > the layer 4, which is undefined.
> >
> > This patch rework the way packet types are processed, to ensure
> > that only valid packet types will be advertised.
> >
> > Fixes: 3d2a6644eb05 ("net/bnxt: support getting ptypes")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Olivier Matz
> >
> Acked-by: Ajit Khaparde
>
[...]
> > + case RTE_LE32(RX_PKT_CMPL_FLAGS_ITYPE_UDP):
> > + if (!t_ipcs)
> > + pkt_type |= l3 | RTE_PTYPE_L4_UDP;
> > + else
> > + pkt_type |= l3 | RTE_PTYPE_INNER_L4_UDP;
> > + break;
> > +
> > + case RTE_LE32(RX_PKT_CMPL_FLAGS_ITYPE_IP):
> > + if (!t_ipcs)
> > + pkt_type |= l3 | RTE_PTYPE_L4_ICMP;
> > + else
> > + pkt_type |= l3 | RTE_PTYPE_INNER_L4_ICMP;
> > + break;
> > + }
Sorry, it looks there is a typo here: it should be pkt_type |= l3
(not ICMP). I'll send a new version.
Re: [dpdk-dev] [PATCH v2 06/10] net/virtio: fix queue setup consistency
Hi,
It's in my short plans, but unfortunately some other high priority tasks
were inserted before. Honnestly, I'm not sure I'll be able to make it
for the release, but I'll do my best.
Olivier
On Wed, Feb 07, 2018 at 08:31:07AM +, Xu, Qian Q wrote:
> Any update, Olivier?
> We are near to release, and the bug-fix is important for the virtio vector
> path usage. Thanks.
>
> > -Original Message-
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Olivier Matz
> > Sent: Thursday, February 1, 2018 4:28 PM
> > To: Yao, Lei A
> > Cc: dev@dpdk.org; y...@fridaylinux.org; maxime.coque...@redhat.com;
> > Thomas Monjalon ; sta...@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH v2 06/10] net/virtio: fix queue setup
> > consistency
> >
> > Hi Lei,
> >
> > It's on my todo list, I'll check this as soon as possible.
> >
> > Olivier
> >
> >
> > On Thu, Feb 01, 2018 at 03:14:15AM +, Yao, Lei A wrote:
> > > Hi, Olivier
> > >
> > > This is Lei from DPDK validation team in Intel. During our DPDK
> > > 18.02-rc1 test, I find the following patch will cause one serious issue
> > > with virtio
> > vector path:
> > > the traffic can't resume after stop/start the virtio device.
> > >
> > > The step like following:
> > > 1. Launch vhost-user port using testpmd at Host 2. Launch VM with
> > > virtio device, mergeable is off 3. Bind the virtio device to pmd
> > > driver, launch testpmd, let the tx/rx use vector path
> > > virtio_xmit_pkts_simple
> > > virtio_recv_pkts_vec
> > > 4. Send traffic to virtio device from vhost side, then stop the virtio
> > > device 5. Start the virtio device again After step 5, the traffic
> > > can't resume.
> > >
> > > Could you help check this and give a fix? This issue will impact the
> > > virtio pmd user experience heavily. By the way, this patch is already
> > > included into V17.11. Looks like we need give a patch to this LTS version.
> > Thanks a lot!
> > >
> > > BRs
> > > Lei
> > > > -Original Message-
> > > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Olivier Matz
> > > > Sent: Thursday, September 7, 2017 8:14 PM
> > > > To: dev@dpdk.org; y...@fridaylinux.org; maxime.coque...@redhat.com
> > > > Cc: step...@networkplumber.org; sta...@dpdk.org
> > > > Subject: [dpdk-dev] [PATCH v2 06/10] net/virtio: fix queue setup
> > > > consistency
> > > >
> > > > In rx/tx queue setup functions, some code is executed only if
> > > > use_simple_rxtx == 1. The value of this variable can change
> > > > depending on the offload flags or sse support. If Rx queue setup is
> > > > called before Tx queue setup, it can result in an invalid configuration:
> > > >
> > > > - dev_configure is called: use_simple_rxtx is initialized to 0
> > > > - rx queue setup is called: queues are initialized without simple path
> > > > support
> > > > - tx queue setup is called: use_simple_rxtx switch to 1, and simple
> > > > Rx/Tx handlers are selected
> > > >
> > > > Fix this by postponing a part of Rx/Tx queue initialization in
> > > > dev_start(), as it was the case in the initial implementation.
> > > >
> > > > Fixes: 48cec290a3d2 ("net/virtio: move queue configure code to
> > > > proper
> > > > place")
> > > > Cc: sta...@dpdk.org
> > > >
> > > > Signed-off-by: Olivier Matz
> > > > ---
> > > > drivers/net/virtio/virtio_ethdev.c | 13 +
> > > > drivers/net/virtio/virtio_ethdev.h | 6 ++
> > > > drivers/net/virtio/virtio_rxtx.c | 40 ++-
> > > > ---
> > > > 3 files changed, 51 insertions(+), 8 deletions(-)
> > > >
> > > > diff --git a/drivers/net/virtio/virtio_ethdev.c
> > > > b/drivers/net/virtio/virtio_ethdev.c
> > > > index 8eee3ff80..c7888f103 100644
> > > > --- a/drivers/net/virtio/virtio_ethdev.c
> > > > +++ b/drivers/net/virtio/virtio_ethdev.c
> > > > @@ -1737,6 +1737,19 @@ virtio_dev_start(struct rte_eth_dev *dev)
> > > > struct virtnet_rx *rxvq;
> > > > struct virtnet_tx *txvq __rte_unused;
> > > > struct virtio_hw *hw = dev->data->dev_private;
> > > > + int ret;
> > > > +
> > > > + /* Finish the initialization of the queues */
> > > > + for (i = 0; i < dev->data->nb_rx_queues; i++) {
> > > > + ret = virtio_dev_rx_queue_setup_finish(dev, i);
> > > > + if (ret < 0)
> > > > + return ret;
> > > > + }
> > > > + for (i = 0; i < dev->data->nb_tx_queues; i++) {
> > > > + ret = virtio_dev_tx_queue_setup_finish(dev, i);
> > > > + if (ret < 0)
> > > > + return ret;
> > > > + }
> > > >
> > > > /* check if lsc interrupt feature is enabled */
> > > > if (dev->data->dev_conf.intr_conf.lsc) { diff --git
> > > > a/drivers/net/virtio/virtio_ethdev.h
> > > > b/drivers/net/virtio/virtio_ethdev.h
> > > > index c3413c6d9..2039bc547 100644
> > > > --- a/drivers/net/virtio/virtio_ethdev.h
> > > > +++ b/drivers/net/virtio/virtio_ethdev.h
> > > > @@ -92,10 +92,16 @@
[dpdk-dev] [PATCH v2] doc: update ip pipeline callback functions
From: longtb5 Update f_post_init for pipeline frontend. Move f_track from pipeline backend to pipeline frontend. Signed-off-by: Bao-Long Tran Acked-by: Marko Kovacevic --- doc/guides/sample_app_ug/ip_pipeline.rst | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/doc/guides/sample_app_ug/ip_pipeline.rst b/doc/guides/sample_app_ug/ip_pipeline.rst index e0aa148..dd0a23f 100644 --- a/doc/guides/sample_app_ug/ip_pipeline.rst +++ b/doc/guides/sample_app_ug/ip_pipeline.rst @@ -876,8 +876,6 @@ The front-end communicates with the back-end through message queues. || | of some requests which are mandatory for all pipelines (e.g. | || | ping, statistics). | ++--++ - | f_track| Function pointer | See section Tracking pipeline output port to physical link | - ++--++ .. _table_ip_pipelines_front_end: @@ -892,6 +890,10 @@ The front-end communicates with the back-end through message queues. | f_init | Function pointer | Function to initialize the front-end of the current pipeline | || | instance. | ++---+---+ + | f_post_init| Function pointer | Function to run once after f_init. | + ++---+---+ + | f_track| Function pointer | See section Tracking pipeline output port to physical link. | + ++---+---+ | f_free | Function pointer | Function to free the resources allocated by the front-end of | || | the current pipeline instance. | ++---+---+ -- 2.7.4
Re: [dpdk-dev] [PATCH 2/3] net/vdpa_virtio_pci: introduce vdpa sample driver
Hi Maxime, > -Original Message- > From: Maxime Coquelin [mailto:maxime.coque...@redhat.com] > Sent: Tuesday, February 6, 2018 10:24 PM > To: Wang, Xiao W ; dev@dpdk.org > Cc: Tan, Jianfeng ; Bie, Tiwei ; > y...@fridaylinux.org; Liang, Cunming ; Daly, Dan > ; Wang, Zhihong > Subject: Re: [PATCH 2/3] net/vdpa_virtio_pci: introduce vdpa sample driver > > Hi Xiao, > > On 02/04/2018 03:55 PM, Xiao Wang wrote: > > This driver is a reference sample of making vDPA device driver based > > on vhost lib, this driver uses a standard virtio-net PCI device as > > vDPA device, it can serve as a backend for a virtio-net pci device > > in nested VM. > > > > The key driver ops implemented are: > > > > * vdpa_virtio_eng_init > > Mapping virtio pci device with VFIO into userspace, and read device > > capability and intialize internal data. > > > > * vdpa_virtio_eng_uninit > > Release the mapped device. > > > > * vdpa_virtio_info_query > > Device capability reporting, e.g. queue number, features. > > > > * vdpa_virtio_dev_config > > With the guest virtio information provideed by vhost lib, this > > function configures device and IOMMU to set up vhost datapath, > > which includes: Rx/Tx vring, VFIO interrupt, kick relay. > > > > * vdpa_virtio_dev_close > > Unset the stuff that are configured previously by dev_conf. > > > > This driver requires the virtio device supports VIRTIO_F_IOMMU_PLATFORM > > , because the buffer address written in desc is IOVA. > > > > Because vDPA driver needs to set up MSI-X vector to interrupt the guest, > > only vfio-pci is supported currently. > > > > Signed-off-by: Xiao Wang > > --- > > config/common_base |6 + > > config/common_linuxapp |1 + > > drivers/net/Makefile |1 + > > drivers/net/vdpa_virtio_pci/Makefile | 31 + > > .../net/vdpa_virtio_pci/rte_eth_vdpa_virtio_pci.c | 1527 > > > .../rte_vdpa_virtio_pci_version.map|4 + > > mk/rte.app.mk |1 + > > 7 files changed, 1571 insertions(+) > > create mode 100644 drivers/net/vdpa_virtio_pci/Makefile > > create mode 100644 drivers/net/vdpa_virtio_pci/rte_eth_vdpa_virtio_pci.c > > create mode 100644 > drivers/net/vdpa_virtio_pci/rte_vdpa_virtio_pci_version.map > > Is there a specific constraint that makes you expose PCI functions and > duplicate a lot of vfio code into the driver? The existing vfio code doesn't fit VDPA well, this vDPA driver needs to program IOMMU for a vDPA device with a VM's memory table. While the eal/vfio uses a struct vfio_cfg to takes all regular devices and add them to a single vfio_container, and program IOMMU with DPDK process's memory table. This driver doing PCI VFIO initialization itself can avoid affecting the global vfio_cfg structure. > > Wouldn't it be better (if possible) to use RTE_PMD_REGISTER_PCI() & co. > to benefit from all the existing infrastructure? RTE_PMD_REGISTER_PCI() & co will make this driver as PCI driver (physical device), then this will conflict with the virtio_pmd. So I make vDPA device driver as a vdev driver. > > Maxime Thanks for the comments, Xiao
[dpdk-dev] [PATCH] Revert "net/i40e/base: enhance loopback AQ command"
This patch fix loopback fail after share code change
This reverts commit 7b7711bea5f4b5c47010c42a690fb4f4c1b57858.
Signed-off-by: Yanglong Wu
---
drivers/net/i40e/base/i40e_adminq_cmd.h | 21 ++---
drivers/net/i40e/base/i40e_common.c | 12
drivers/net/i40e/base/i40e_diag.c | 17 ++---
drivers/net/i40e/base/i40e_prototype.h | 5 ++---
drivers/net/i40e/i40e_ethdev.c | 4 +---
5 files changed, 11 insertions(+), 48 deletions(-)
diff --git a/drivers/net/i40e/base/i40e_adminq_cmd.h
b/drivers/net/i40e/base/i40e_adminq_cmd.h
index bbf094add..801c0ff1b 100644
--- a/drivers/net/i40e/base/i40e_adminq_cmd.h
+++ b/drivers/net/i40e/base/i40e_adminq_cmd.h
@@ -2130,28 +2130,11 @@ I40E_CHECK_CMD_LENGTH(i40e_aqc_an_advt_reg);
/* Set Loopback mode (0x0618) */
struct i40e_aqc_set_lb_mode {
- u8 lb_level;
-#define I40E_AQ_LB_NONE0
-#define I40E_AQ_LB_MAC 1
-#define I40E_AQ_LB_SERDES 2
-#define I40E_AQ_LB_PHY_INT 3
-#define I40E_AQ_LB_PHY_EXT 4
-#define I40E_AQ_LB_CPVL_PCS5
-#define I40E_AQ_LB_CPVL_EXT6
+ __le16 lb_mode;
#define I40E_AQ_LB_PHY_LOCAL 0x01
#define I40E_AQ_LB_PHY_REMOTE 0x02
#define I40E_AQ_LB_MAC_LOCAL 0x04
- u8 lb_type;
-#define I40E_AQ_LB_LOCAL 0
-#define I40E_AQ_LB_FAR 0x01
- u8 speed;
-#define I40E_AQ_LB_SPEED_NONE 0
-#define I40E_AQ_LB_SPEED_1G1
-#define I40E_AQ_LB_SPEED_10G 2
-#define I40E_AQ_LB_SPEED_40G 3
-#define I40E_AQ_LB_SPEED_20G 4
- u8 force_speed;
- u8 reserved[12];
+ u8 reserved[14];
};
I40E_CHECK_CMD_LENGTH(i40e_aqc_set_lb_mode);
diff --git a/drivers/net/i40e/base/i40e_common.c
b/drivers/net/i40e/base/i40e_common.c
index 6c65a3236..e0a5be14c 100644
--- a/drivers/net/i40e/base/i40e_common.c
+++ b/drivers/net/i40e/base/i40e_common.c
@@ -2172,9 +2172,9 @@ enum i40e_status_code i40e_aq_get_partner_advt(struct
i40e_hw *hw,
*
* Sets loopback modes.
**/
-enum i40e_status_code
-i40e_aq_set_lb_modes(struct i40e_hw *hw, u8 lb_level, u8 lb_type, u8 speed,
-struct i40e_asq_cmd_details *cmd_details)
+enum i40e_status_code i40e_aq_set_lb_modes(struct i40e_hw *hw,
+ u16 lb_modes,
+ struct i40e_asq_cmd_details *cmd_details)
{
struct i40e_aq_desc desc;
struct i40e_aqc_set_lb_mode *cmd =
@@ -2184,11 +2184,7 @@ i40e_aq_set_lb_modes(struct i40e_hw *hw, u8 lb_level, u8
lb_type, u8 speed,
i40e_fill_default_direct_cmd_desc(&desc,
i40e_aqc_opc_set_lb_modes);
- cmd->lb_level = lb_level;
- cmd->lb_type = lb_type;
- cmd->speed = speed;
- if (speed)
- cmd->force_speed = 1;
+ cmd->lb_mode = CPU_TO_LE16(lb_modes);
status = i40e_asq_send_command(hw, &desc, NULL, 0, cmd_details);
diff --git a/drivers/net/i40e/base/i40e_diag.c
b/drivers/net/i40e/base/i40e_diag.c
index 0efa59de3..c3c76a0c8 100644
--- a/drivers/net/i40e/base/i40e_diag.c
+++ b/drivers/net/i40e/base/i40e_diag.c
@@ -45,21 +45,8 @@ enum i40e_status_code i40e_diag_set_loopback(struct i40e_hw
*hw,
enum i40e_lb_mode mode)
{
enum i40e_status_code ret_code = I40E_SUCCESS;
- u8 speed = I40E_AQ_LB_SPEED_10G;
- u8 level = 0;
- u8 type = 0;
-
- if (mode == I40E_LB_MODE_PHY_LOCAL) {
- level = I40E_AQ_LB_PHY_INT;
- type = I40E_AQ_LB_LOCAL;
- } else if (mode == I40E_LB_MODE_PHY_REMOTE) {
- level = I40E_AQ_LB_PHY_INT;
- type = I40E_AQ_LB_FAR;
- } else if (mode == I40E_LB_MODE_MAC_LOCAL) {
- level = I40E_AQ_LB_MAC;
- type = I40E_AQ_LB_LOCAL;
- }
- if (i40e_aq_set_lb_modes(hw, level, type, speed, NULL))
+
+ if (i40e_aq_set_lb_modes(hw, mode, NULL))
ret_code = I40E_ERR_DIAG_TEST_FAILED;
return ret_code;
diff --git a/drivers/net/i40e/base/i40e_prototype.h
b/drivers/net/i40e/base/i40e_prototype.h
index 1edfb2d18..c6ec2d769 100644
--- a/drivers/net/i40e/base/i40e_prototype.h
+++ b/drivers/net/i40e/base/i40e_prototype.h
@@ -142,9 +142,8 @@ enum i40e_status_code i40e_aq_get_local_advt_reg(struct
i40e_hw *hw,
enum i40e_status_code i40e_aq_get_partner_advt(struct i40e_hw *hw,
u64 *advt_reg,
struct i40e_asq_cmd_details *cmd_details);
-enum i40e_status_code
-i40e_aq_set_lb_modes(struct i40e_hw *hw, u8 lb_level, u8 lb_type, u8 speed,
-struct i40e_asq_cmd_details *cmd_details);
+enum i40e_status_code i40e_aq_set_lb_modes(struct i40e_hw *hw, u16 lb_modes,
+ struct i40e_asq_cmd_details *cmd_details);
enum i40e_status_code i40e_aq_clear_pxe_mode(struct i40e_hw *hw,
struct i40e_asq_cmd_details *cmd_details);
enum i40e_status_code i4
Re: [dpdk-dev] [PATCH] doc: update i40e guide
> -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Mcnamara, John > Sent: Thursday, February 8, 2018 12:07 AM > To: Xing, Beilei; dev@dpdk.org; Wu, Jingjing > Cc: sta...@dpdk.org > Subject: Re: [dpdk-dev] [PATCH] doc: update i40e guide > > > > > -Original Message- > > From: Xing, Beilei > > Sent: Sunday, February 4, 2018 3:41 AM > > To: Mcnamara, John ; dev@dpdk.org; Wu, > > Jingjing > > Cc: sta...@dpdk.org > > Subject: [PATCH] doc: update i40e guide > > > > This patch updates the i40e guide with new device parameter > > support-multi- driver. > > > > Signed-off-by: Beilei Xing > > > Acked-by: John McNamara Applied to dpdk-next-net-intel, thanks! /Helin >
Re: [dpdk-dev] [PATCH] Revert "net/i40e/base: enhance loopback AQ command"
> -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Yanglong Wu > Sent: Thursday, February 8, 2018 10:34 AM > To: dev@dpdk.org > Cc: Zhang, Helin ; Lu, Wenzhuo > ; Xing, Beilei ; Wu, Yanglong > > Subject: [dpdk-dev] [PATCH] Revert "net/i40e/base: enhance loopback AQ > command" > > This patch fix loopback fail after share code change > > This reverts commit 7b7711bea5f4b5c47010c42a690fb4f4c1b57858. > > Signed-off-by: Yanglong Wu Acked-by: Qi Zhang
Re: [dpdk-dev] [PATCH 1/7] vhost: make capabilities configurable
Hi Maxime,
> -Original Message-
> From: Maxime Coquelin [mailto:maxime.coque...@redhat.com]
> Sent: Tuesday, February 6, 2018 6:19 PM
> To: Wang, Zhihong ; dev@dpdk.org
> Cc: Tan, Jianfeng ; Bie, Tiwei
> ; y...@fridaylinux.org; Liang, Cunming
> ; Wang, Xiao W ; Daly,
> Dan
> Subject: Re: [PATCH 1/7] vhost: make capabilities configurable
>
> Hi Zhihong,
>
...
> > +int rte_vhost_driver_set_queue_num(const char *path, uint16_t
> queue_num)
> > +{
> > + struct vhost_user_socket *vsocket;
> > +
> > + pthread_mutex_lock(&vhost_user.mutex);
> > + vsocket = find_vhost_user_socket(path);
> > + if (vsocket)
> > + vsocket->queue_num = queue_num;
>
> Shouldn't be MIN(queue_num, VHOST_MAX_QUEUE_PAIRS) to be sure you
> can
> switch from HW offload to SW processing?
Yes, the check is necessary.
>
> > + pthread_mutex_unlock(&vhost_user.mutex);
> > +
> > + return vsocket ? 0 : -1;
> > +}
...
> > -static void
> > +static int
> > vhost_user_set_protocol_features(struct virtio_net *dev,
> > uint64_t protocol_features)
> > {
> > - if (protocol_features & ~VHOST_USER_PROTOCOL_FEATURES)
>
> I think the above check is still necessary, or it should be checked
> in rte_vhost_driver_set_protocol_features().
Thanks. Yes I think all set capabilities should be contained in the
capabilities of the vhost-user lib.
Will update rte_vhost_driver_set_*().
-Zhihong
>
> Indeed, the application shouldn't set a protocol feature bit that isn't
> supported by the libvhost-user library.
>
> > - return;
> > + uint64_t vhost_protocol_features = 0;
> > +
> > + rte_vhost_driver_get_protocol_features(dev->ifname,
> > + &vhost_protocol_features);
> > + if (protocol_features & ~vhost_protocol_features) {
> > + RTE_LOG(ERR, VHOST_CONFIG,
> > + "(%d) received invalid negotiated
> protocol_features.\n",
> > + dev->vid);
> > + return -1;
> > + }
> >
> > dev->protocol_features = protocol_features;
> > +
> > + return 0;
> > }
> >
> > static int
> > @@ -1391,7 +1416,8 @@ vhost_user_msg_handler(int vid, int fd)
> > break;
> >
> > case VHOST_USER_GET_PROTOCOL_FEATURES:
> > - vhost_user_get_protocol_features(dev, &msg);
> > + msg.payload.u64 = vhost_user_get_protocol_features(dev);
> > + msg.size = sizeof(msg.payload.u64);
> > send_vhost_reply(fd, &msg);
> > break;
> > case VHOST_USER_SET_PROTOCOL_FEATURES:
> > @@ -1451,7 +1477,7 @@ vhost_user_msg_handler(int vid, int fd)
> > break;
> >
> > case VHOST_USER_GET_QUEUE_NUM:
> > - msg.payload.u64 = VHOST_MAX_QUEUE_PAIRS;
> > + msg.payload.u64 = vhost_user_get_queue_num(dev);
> > msg.size = sizeof(msg.payload.u64);
> > send_vhost_reply(fd, &msg);
> > break;
> >
>
> Maxime
[dpdk-dev] [PATCH v2] net/i40e: fix i40e loopback configuration error
This reverts commit:
7b7711bea5f4("net/i40e/base: enhance loopback AQ command").
Commit(7b7711bea5f4) means to support multi type of loopbacks,
but it results to configuration error for adminq. So we revert
this commit in this version.
Fixes: 7b7711bea5f4 ("net/i40e/base: enhance loopback AQ command")
Signed-off-by: Yanglong Wu
Acked-by: Qi Zhang
---
v2:
update commit log
---
drivers/net/i40e/base/i40e_adminq_cmd.h | 21 ++---
drivers/net/i40e/base/i40e_common.c | 12
drivers/net/i40e/base/i40e_diag.c | 17 ++---
drivers/net/i40e/base/i40e_prototype.h | 5 ++---
drivers/net/i40e/i40e_ethdev.c | 4 +---
5 files changed, 11 insertions(+), 48 deletions(-)
diff --git a/drivers/net/i40e/base/i40e_adminq_cmd.h
b/drivers/net/i40e/base/i40e_adminq_cmd.h
index bbf094add..801c0ff1b 100644
--- a/drivers/net/i40e/base/i40e_adminq_cmd.h
+++ b/drivers/net/i40e/base/i40e_adminq_cmd.h
@@ -2130,28 +2130,11 @@ I40E_CHECK_CMD_LENGTH(i40e_aqc_an_advt_reg);
/* Set Loopback mode (0x0618) */
struct i40e_aqc_set_lb_mode {
- u8 lb_level;
-#define I40E_AQ_LB_NONE0
-#define I40E_AQ_LB_MAC 1
-#define I40E_AQ_LB_SERDES 2
-#define I40E_AQ_LB_PHY_INT 3
-#define I40E_AQ_LB_PHY_EXT 4
-#define I40E_AQ_LB_CPVL_PCS5
-#define I40E_AQ_LB_CPVL_EXT6
+ __le16 lb_mode;
#define I40E_AQ_LB_PHY_LOCAL 0x01
#define I40E_AQ_LB_PHY_REMOTE 0x02
#define I40E_AQ_LB_MAC_LOCAL 0x04
- u8 lb_type;
-#define I40E_AQ_LB_LOCAL 0
-#define I40E_AQ_LB_FAR 0x01
- u8 speed;
-#define I40E_AQ_LB_SPEED_NONE 0
-#define I40E_AQ_LB_SPEED_1G1
-#define I40E_AQ_LB_SPEED_10G 2
-#define I40E_AQ_LB_SPEED_40G 3
-#define I40E_AQ_LB_SPEED_20G 4
- u8 force_speed;
- u8 reserved[12];
+ u8 reserved[14];
};
I40E_CHECK_CMD_LENGTH(i40e_aqc_set_lb_mode);
diff --git a/drivers/net/i40e/base/i40e_common.c
b/drivers/net/i40e/base/i40e_common.c
index 6c65a3236..e0a5be14c 100644
--- a/drivers/net/i40e/base/i40e_common.c
+++ b/drivers/net/i40e/base/i40e_common.c
@@ -2172,9 +2172,9 @@ enum i40e_status_code i40e_aq_get_partner_advt(struct
i40e_hw *hw,
*
* Sets loopback modes.
**/
-enum i40e_status_code
-i40e_aq_set_lb_modes(struct i40e_hw *hw, u8 lb_level, u8 lb_type, u8 speed,
-struct i40e_asq_cmd_details *cmd_details)
+enum i40e_status_code i40e_aq_set_lb_modes(struct i40e_hw *hw,
+ u16 lb_modes,
+ struct i40e_asq_cmd_details *cmd_details)
{
struct i40e_aq_desc desc;
struct i40e_aqc_set_lb_mode *cmd =
@@ -2184,11 +2184,7 @@ i40e_aq_set_lb_modes(struct i40e_hw *hw, u8 lb_level, u8
lb_type, u8 speed,
i40e_fill_default_direct_cmd_desc(&desc,
i40e_aqc_opc_set_lb_modes);
- cmd->lb_level = lb_level;
- cmd->lb_type = lb_type;
- cmd->speed = speed;
- if (speed)
- cmd->force_speed = 1;
+ cmd->lb_mode = CPU_TO_LE16(lb_modes);
status = i40e_asq_send_command(hw, &desc, NULL, 0, cmd_details);
diff --git a/drivers/net/i40e/base/i40e_diag.c
b/drivers/net/i40e/base/i40e_diag.c
index 0efa59de3..c3c76a0c8 100644
--- a/drivers/net/i40e/base/i40e_diag.c
+++ b/drivers/net/i40e/base/i40e_diag.c
@@ -45,21 +45,8 @@ enum i40e_status_code i40e_diag_set_loopback(struct i40e_hw
*hw,
enum i40e_lb_mode mode)
{
enum i40e_status_code ret_code = I40E_SUCCESS;
- u8 speed = I40E_AQ_LB_SPEED_10G;
- u8 level = 0;
- u8 type = 0;
-
- if (mode == I40E_LB_MODE_PHY_LOCAL) {
- level = I40E_AQ_LB_PHY_INT;
- type = I40E_AQ_LB_LOCAL;
- } else if (mode == I40E_LB_MODE_PHY_REMOTE) {
- level = I40E_AQ_LB_PHY_INT;
- type = I40E_AQ_LB_FAR;
- } else if (mode == I40E_LB_MODE_MAC_LOCAL) {
- level = I40E_AQ_LB_MAC;
- type = I40E_AQ_LB_LOCAL;
- }
- if (i40e_aq_set_lb_modes(hw, level, type, speed, NULL))
+
+ if (i40e_aq_set_lb_modes(hw, mode, NULL))
ret_code = I40E_ERR_DIAG_TEST_FAILED;
return ret_code;
diff --git a/drivers/net/i40e/base/i40e_prototype.h
b/drivers/net/i40e/base/i40e_prototype.h
index 1edfb2d18..c6ec2d769 100644
--- a/drivers/net/i40e/base/i40e_prototype.h
+++ b/drivers/net/i40e/base/i40e_prototype.h
@@ -142,9 +142,8 @@ enum i40e_status_code i40e_aq_get_local_advt_reg(struct
i40e_hw *hw,
enum i40e_status_code i40e_aq_get_partner_advt(struct i40e_hw *hw,
u64 *advt_reg,
struct i40e_asq_cmd_details *cmd_details);
-enum i40e_status_code
-i40e_aq_set_lb_modes(struct i40e_hw *hw, u8 lb_level, u8 lb_type, u8 speed,
-struct i40e_asq_cmd_details *cmd_details);
+enum i40e_status_code i40e_aq_set_lb_modes(struct i40e_hw *hw, u16
[dpdk-dev] [PATCH v2] net/i40e: fix i40e loopback configuration error
This reverts commit:
commit 7b7711bea5f4 ("net/i40e/base: enhance loopback AQ command").
The commit "net/i40e/base: enhance loopback AQ command" means
to support multi type of loopbacks,but it results to configuration
error for the adminq. So we revert this commit in this version.
Fixes:commit 7b7711bea5f4 ("net/i40e/base: enhance loopback AQ command")
Signed-off-by: Yanglong Wu
Acked-by: Qi Zhang
---
v2:
update commit log
---
drivers/net/i40e/base/i40e_adminq_cmd.h | 21 ++---
drivers/net/i40e/base/i40e_common.c | 12
drivers/net/i40e/base/i40e_diag.c | 17 ++---
drivers/net/i40e/base/i40e_prototype.h | 5 ++---
drivers/net/i40e/i40e_ethdev.c | 4 +---
5 files changed, 11 insertions(+), 48 deletions(-)
diff --git a/drivers/net/i40e/base/i40e_adminq_cmd.h
b/drivers/net/i40e/base/i40e_adminq_cmd.h
index bbf094add..801c0ff1b 100644
--- a/drivers/net/i40e/base/i40e_adminq_cmd.h
+++ b/drivers/net/i40e/base/i40e_adminq_cmd.h
@@ -2130,28 +2130,11 @@ I40E_CHECK_CMD_LENGTH(i40e_aqc_an_advt_reg);
/* Set Loopback mode (0x0618) */
struct i40e_aqc_set_lb_mode {
- u8 lb_level;
-#define I40E_AQ_LB_NONE0
-#define I40E_AQ_LB_MAC 1
-#define I40E_AQ_LB_SERDES 2
-#define I40E_AQ_LB_PHY_INT 3
-#define I40E_AQ_LB_PHY_EXT 4
-#define I40E_AQ_LB_CPVL_PCS5
-#define I40E_AQ_LB_CPVL_EXT6
+ __le16 lb_mode;
#define I40E_AQ_LB_PHY_LOCAL 0x01
#define I40E_AQ_LB_PHY_REMOTE 0x02
#define I40E_AQ_LB_MAC_LOCAL 0x04
- u8 lb_type;
-#define I40E_AQ_LB_LOCAL 0
-#define I40E_AQ_LB_FAR 0x01
- u8 speed;
-#define I40E_AQ_LB_SPEED_NONE 0
-#define I40E_AQ_LB_SPEED_1G1
-#define I40E_AQ_LB_SPEED_10G 2
-#define I40E_AQ_LB_SPEED_40G 3
-#define I40E_AQ_LB_SPEED_20G 4
- u8 force_speed;
- u8 reserved[12];
+ u8 reserved[14];
};
I40E_CHECK_CMD_LENGTH(i40e_aqc_set_lb_mode);
diff --git a/drivers/net/i40e/base/i40e_common.c
b/drivers/net/i40e/base/i40e_common.c
index 6c65a3236..e0a5be14c 100644
--- a/drivers/net/i40e/base/i40e_common.c
+++ b/drivers/net/i40e/base/i40e_common.c
@@ -2172,9 +2172,9 @@ enum i40e_status_code i40e_aq_get_partner_advt(struct
i40e_hw *hw,
*
* Sets loopback modes.
**/
-enum i40e_status_code
-i40e_aq_set_lb_modes(struct i40e_hw *hw, u8 lb_level, u8 lb_type, u8 speed,
-struct i40e_asq_cmd_details *cmd_details)
+enum i40e_status_code i40e_aq_set_lb_modes(struct i40e_hw *hw,
+ u16 lb_modes,
+ struct i40e_asq_cmd_details *cmd_details)
{
struct i40e_aq_desc desc;
struct i40e_aqc_set_lb_mode *cmd =
@@ -2184,11 +2184,7 @@ i40e_aq_set_lb_modes(struct i40e_hw *hw, u8 lb_level, u8
lb_type, u8 speed,
i40e_fill_default_direct_cmd_desc(&desc,
i40e_aqc_opc_set_lb_modes);
- cmd->lb_level = lb_level;
- cmd->lb_type = lb_type;
- cmd->speed = speed;
- if (speed)
- cmd->force_speed = 1;
+ cmd->lb_mode = CPU_TO_LE16(lb_modes);
status = i40e_asq_send_command(hw, &desc, NULL, 0, cmd_details);
diff --git a/drivers/net/i40e/base/i40e_diag.c
b/drivers/net/i40e/base/i40e_diag.c
index 0efa59de3..c3c76a0c8 100644
--- a/drivers/net/i40e/base/i40e_diag.c
+++ b/drivers/net/i40e/base/i40e_diag.c
@@ -45,21 +45,8 @@ enum i40e_status_code i40e_diag_set_loopback(struct i40e_hw
*hw,
enum i40e_lb_mode mode)
{
enum i40e_status_code ret_code = I40E_SUCCESS;
- u8 speed = I40E_AQ_LB_SPEED_10G;
- u8 level = 0;
- u8 type = 0;
-
- if (mode == I40E_LB_MODE_PHY_LOCAL) {
- level = I40E_AQ_LB_PHY_INT;
- type = I40E_AQ_LB_LOCAL;
- } else if (mode == I40E_LB_MODE_PHY_REMOTE) {
- level = I40E_AQ_LB_PHY_INT;
- type = I40E_AQ_LB_FAR;
- } else if (mode == I40E_LB_MODE_MAC_LOCAL) {
- level = I40E_AQ_LB_MAC;
- type = I40E_AQ_LB_LOCAL;
- }
- if (i40e_aq_set_lb_modes(hw, level, type, speed, NULL))
+
+ if (i40e_aq_set_lb_modes(hw, mode, NULL))
ret_code = I40E_ERR_DIAG_TEST_FAILED;
return ret_code;
diff --git a/drivers/net/i40e/base/i40e_prototype.h
b/drivers/net/i40e/base/i40e_prototype.h
index 1edfb2d18..c6ec2d769 100644
--- a/drivers/net/i40e/base/i40e_prototype.h
+++ b/drivers/net/i40e/base/i40e_prototype.h
@@ -142,9 +142,8 @@ enum i40e_status_code i40e_aq_get_local_advt_reg(struct
i40e_hw *hw,
enum i40e_status_code i40e_aq_get_partner_advt(struct i40e_hw *hw,
u64 *advt_reg,
struct i40e_asq_cmd_details *cmd_details);
-enum i40e_status_code
-i40e_aq_set_lb_modes(struct i40e_hw *hw, u8 lb_level, u8 lb_type, u8 speed,
-struct i40e_asq_cmd_details *cmd_details);
+enum i40e_statu
[dpdk-dev] [PATCH] net/ixgbe: fix CRC strip enabling
New testpmd will get CRC strip offload from rx_offload_capa. Ixgbe card
has the capability. This patch adds CRC strip flag into rx_offload_capa
in ixgbe and ixgbevf.
Fixes: 8b9bd0efe0b6 ("app/testpmd: disable Rx VLAN offloads by default")
Cc: sta...@dpdk.org
Signed-off-by: Xiaoyun Li
---
drivers/net/ixgbe/ixgbe_ethdev.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index c423cf2..4483258 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -3651,7 +3651,8 @@ ixgbe_dev_info_get(struct rte_eth_dev *dev, struct
rte_eth_dev_info *dev_info)
DEV_RX_OFFLOAD_VLAN_STRIP |
DEV_RX_OFFLOAD_IPV4_CKSUM |
DEV_RX_OFFLOAD_UDP_CKSUM |
- DEV_RX_OFFLOAD_TCP_CKSUM;
+ DEV_RX_OFFLOAD_TCP_CKSUM |
+ DEV_RX_OFFLOAD_CRC_STRIP;
/*
* RSC is only supported by 82599 and x540 PF devices in a non-SR-IOV
@@ -3798,7 +3799,8 @@ ixgbevf_dev_info_get(struct rte_eth_dev *dev,
dev_info->rx_offload_capa = DEV_RX_OFFLOAD_VLAN_STRIP |
DEV_RX_OFFLOAD_IPV4_CKSUM |
DEV_RX_OFFLOAD_UDP_CKSUM |
- DEV_RX_OFFLOAD_TCP_CKSUM;
+ DEV_RX_OFFLOAD_TCP_CKSUM |
+ DEV_RX_OFFLOAD_CRC_STRIP;
dev_info->tx_offload_capa = DEV_TX_OFFLOAD_VLAN_INSERT |
DEV_TX_OFFLOAD_IPV4_CKSUM |
DEV_TX_OFFLOAD_UDP_CKSUM |
--
2.7.4
Re: [dpdk-dev] [PATCH] net/ixgbe: fix CRC strip enabling
Hi,
> -Original Message-
> From: Li, Xiaoyun
> Sent: Thursday, February 8, 2018 1:45 PM
> To: Lu, Wenzhuo
> Cc: dev@dpdk.org; Zhang, Helin ; Li, Xiaoyun
> ; sta...@dpdk.org
> Subject: [PATCH] net/ixgbe: fix CRC strip enabling
>
> New testpmd will get CRC strip offload from rx_offload_capa. Ixgbe card has
> the capability. This patch adds CRC strip flag into rx_offload_capa in ixgbe
> and ixgbevf.
>
> Fixes: 8b9bd0efe0b6 ("app/testpmd: disable Rx VLAN offloads by default")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Xiaoyun Li
Acked-by: Wenzhuo Lu
Re: [dpdk-dev] [PATCH v2] net/i40e: fix i40e loopback configuration error
> -Original Message-
> From: Wu, Yanglong
> Sent: Thursday, February 8, 2018 1:00 PM
> To: dev@dpdk.org
> Cc: Zhang, Helin; Lu, Wenzhuo; Xing, Beilei; Zhang, Qi Z; Wu, Yanglong
> Subject: [PATCH v2] net/i40e: fix i40e loopback configuration error
>
> This reverts commit:
> commit 7b7711bea5f4 ("net/i40e/base: enhance loopback AQ
> command").
>
> The commit "net/i40e/base: enhance loopback AQ command" means to
> support multi type of loopbacks,but it results to configuration error for the
> adminq. So we revert this commit in this version.
>
> Fixes:commit 7b7711bea5f4 ("net/i40e/base: enhance loopback AQ command")
>
> Signed-off-by: Yanglong Wu
> Acked-by: Qi Zhang
Applied to dpdk-next-net-intel, with commit log changes. Thanks!
/Helin
[dpdk-dev] [PATCH] examples/ipsec-secgw: add support for AES 256
Adding support for AES 256 algorithm in ipsec-secgw application
Signed-off-by: Anoob Joseph
---
doc/guides/sample_app_ug/ipsec_secgw.rst | 1 +
examples/ipsec-secgw/sa.c| 7 +++
2 files changed, 8 insertions(+)
diff --git a/doc/guides/sample_app_ug/ipsec_secgw.rst
b/doc/guides/sample_app_ug/ipsec_secgw.rst
index ae18acd..12ebd37 100644
--- a/doc/guides/sample_app_ug/ipsec_secgw.rst
+++ b/doc/guides/sample_app_ug/ipsec_secgw.rst
@@ -422,6 +422,7 @@ where each options means:
* *null*: NULL algorithm
* *aes-128-cbc*: AES-CBC 128-bit algorithm
+ * *aes-256-cbc*: AES-CBC 256-bit algorithm
* *aes-128-ctr*: AES-CTR 128-bit algorithm
* Syntax: *cipher_algo *
diff --git a/examples/ipsec-secgw/sa.c b/examples/ipsec-secgw/sa.c
index 25ceea1..21239dd 100644
--- a/examples/ipsec-secgw/sa.c
+++ b/examples/ipsec-secgw/sa.c
@@ -69,6 +69,13 @@ const struct supported_cipher_algo cipher_algos[] = {
.key_len = 16
},
{
+ .keyword = "aes-256-cbc",
+ .algo = RTE_CRYPTO_CIPHER_AES_CBC,
+ .iv_len = 16,
+ .block_size = 16,
+ .key_len = 32
+ },
+ {
.keyword = "aes-128-ctr",
.algo = RTE_CRYPTO_CIPHER_AES_CTR,
.iv_len = 8,
--
2.7.4
Re: [dpdk-dev] [PATCH] net/ixgbe: fix CRC strip enabling
> -Original Message-
> From: Lu, Wenzhuo
> Sent: Thursday, February 8, 2018 2:08 PM
> To: Li, Xiaoyun
> Cc: dev@dpdk.org; Zhang, Helin; sta...@dpdk.org
> Subject: RE: [PATCH] net/ixgbe: fix CRC strip enabling
>
> Hi,
>
> > -Original Message-
> > From: Li, Xiaoyun
> > Sent: Thursday, February 8, 2018 1:45 PM
> > To: Lu, Wenzhuo
> > Cc: dev@dpdk.org; Zhang, Helin ; Li, Xiaoyun
> > ; sta...@dpdk.org
> > Subject: [PATCH] net/ixgbe: fix CRC strip enabling
> >
> > New testpmd will get CRC strip offload from rx_offload_capa. Ixgbe
> > card has the capability. This patch adds CRC strip flag into
> > rx_offload_capa in ixgbe and ixgbevf.
> >
> > Fixes: 8b9bd0efe0b6 ("app/testpmd: disable Rx VLAN offloads by
> > default")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Xiaoyun Li
> Acked-by: Wenzhuo Lu
Applied to dpdk-next-dpdk-intel, with commit log changes. Thanks!
/Helin
[dpdk-dev] [PATCH v1] doc: update mlx4 flow limitations
From: Moti Haimovsky This patch updates mlx4 documentation with flow configuration limitations imposed by NIC hardware and PMD implementation Signed-off-by: Ophir Munk --- doc/guides/nics/mlx4.rst | 77 1 file changed, 77 insertions(+) diff --git a/doc/guides/nics/mlx4.rst b/doc/guides/nics/mlx4.rst index 98b9716..b81a875 100644 --- a/doc/guides/nics/mlx4.rst +++ b/doc/guides/nics/mlx4.rst @@ -515,3 +515,80 @@ devices managed by librte_pmd_mlx4. Port 3 Link Up - speed 4 Mbps - full-duplex Done testpmd> + +Limitations +--- + +Flow rules +~~ + +L2 (eth) + + +- Can only use real destination MAC +- Source MAC is not taken into consideration + + For example using testpmd command - src mask must be 00:00:00:00:00:00 + otherwise the following command will fail + +.. code-block:: console + + testpmd> flow create 1 ingress pattern eth + src spec 00:16:3e:2b:e6:47 src mask FF:FF:FF:FF:FF:FF + / end actions drop / end + +- Supports only full MASK + + For example the following testpmd command will fail + +.. code-block:: console + + testpmd> flow create 1 ingress pattern eth + src spec 00:16:3e:2b:e6:47 + dst spec 4A:11:6C:FA:60:D0 dst mask FF:00:FF:FF:FF:00 + / end actions drop / end + + +- When configured to run in promiscuous or all-multicast modes does + not support additional rules +- Does not support the explicit exclusion of all multicast traffic +- Does not support partial VLAN TCI VID matching + +L3 (ipv4) +^ + +- Supports only 0 or full mask. Prerequisites: Need to have eth dst spec + +L4 (tcp/udp) + + +- Supports only full mask + + For example the following testpmd command will fail + +.. code-block:: console + + testpmd> flow create 0 ingress pattern eth + src spec e4:1d:2d:2d:8d:22 + dst spec 00:15:5D:10:8D:00 dst mask FF:FF:FF:FF:FF:FF + / ipv4 src spec 144.144.92.0 src prefix 16 + / end actions drop / end + + Prerequisites: Need to have eth dst spec and IPv4 before it with all + its limitations + +Flow actions + + +RSS +^^^ + +RSS is performed on packets to spread them among several queues based on hash +function calculation and according to provided parameters. + +- RSS hash is calculated on fixed packet fields including: L3 source and + destination addresses (ipv4 or ipv6) and L4 source and destination addresses + (upd or tcp ports) +- Uses default constant RSS key +- Only power of two number of queues is supported +- Every Rx queue can be specified only once in RSS action -- 2.7.4
Re: [dpdk-dev] [PATCH] examples: update copyright and license
> -Original Message- > From: Lee Daly [mailto:lee.d...@intel.com] > Sent: 2018年1月17日 22:39 > To: olivier.m...@6wind.com; remy.hor...@intel.com; or...@mellanox.com; > bruce.richard...@intel.com; pablo.de.lara.gua...@intel.com; > radu.nico...@intel.com; tomasz.kante...@intel.com; > cristian.dumitre...@intel.com; chao...@linux.vnet.ibm.com; > john.mcnam...@intel.com; harry.van.haa...@intel.com; jijiang@intel.com > Cc: dev@dpdk.org; Lee Daly > Subject: [PATCH] examples: update copyright and license > > This updates the license on files in examples to be the standard > BSD-3-Clause license used for the rest of DPDK, > bringing the files in compliance with the DPDK licensing policy. > > Signed-off-by: Lee Daly > --- > examples/Makefile | 31 +- > examples/cmdline/commands.c| 58 > +- > examples/cmdline/main.c| 58 > +- > examples/cmdline/parse_obj_list.c | 58 +- > examples/cmdline/parse_obj_list.h | 58 +- > examples/flow_filtering/Makefile | 33 +-- > examples/flow_filtering/flow_blocks.c | 32 +- > examples/flow_filtering/main.c | 32 +- > examples/ip_pipeline/parser.c | 69 +- > examples/ip_pipeline/pipeline/hash_func_arm64.h| 35 ++- > examples/l3fwd/l3fwd_altivec.h | 37 ++-- > examples/l3fwd/l3fwd_common.h | 32 +- > examples/l3fwd/l3fwd_em_hlm.h | 37 ++-- > examples/l3fwd/l3fwd_em_hlm_neon.h | 36 ++- > examples/l3fwd/l3fwd_lpm_altivec.h | 36 ++- > examples/l3fwd/l3fwd_lpm_neon.h| 36 ++- > examples/l3fwd/l3fwd_neon.h| 36 ++- > examples/netmap_compat/netmap/netmap.h | 30 +- > examples/netmap_compat/netmap/netmap_user.h| 30 +- > examples/performance-thread/common/arch/x86/ctx.c | 58 +- > .../performance-thread/common/arch/x86/stack.h | 61 ++- > examples/performance-thread/common/lthread.c | 56 +- > examples/performance-thread/common/lthread.h | 56 +- > examples/performance-thread/common/lthread_api.h | 56 +- > examples/performance-thread/common/lthread_cond.c | 56 +- > examples/performance-thread/common/lthread_cond.h | 56 +- > examples/performance-thread/common/lthread_int.h | 58 ++ > 27 files changed, 79 insertions(+), 1152 deletions(-) > > diff --git a/examples/Makefile b/examples/Makefile > index 9f7974a..f0cf2a1 100644 > --- a/examples/Makefile > +++ b/examples/Makefile > @@ -1,32 +1,5 @@ > -# BSD LICENSE > -# > -# Copyright(c) 2016 6WIND S.A. > -# > -# Redistribution and use in source and binary forms, with or without > -# modification, are permitted provided that the following conditions > -# are met: > -# > -# * Redistributions of source code must retain the above copyright > -# notice, this list of conditions and the following disclaimer. > -# * Redistributions in binary form must reproduce the above copyright > -# notice, this list of conditions and the following disclaimer in > -# the documentation and/or other materials provided with the > -# distribution. > -# * Neither the name of 6WIND S.A. nor the names of its > -# contributors may be used to endorse or promote products derived > -# from this software without specific prior written permission. > -# > -# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND > CONTRIBUTORS > -# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT > NOT > -# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND > FITNESS FOR > -# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE > COPYRIGHT > -# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, > INCIDENTAL, > -# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT > NOT > -# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS > OF USE, > -# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED > AND ON ANY > -# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR > TORT > -# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF > THE USE > -# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH > DAMAGE. > +# SPDX-License-Identifier: BSD-3-Clause > +# Copyright(c) 2016 6WIND S.A. > > ifeq ($(RTE_SDK),) > $(error "Please define RTE_SDK environment variable") > diff --git a/examples/cmdline/commands.c b/examples/cmdline/commands.c > index f3ba247..06916d7 100644 > --- a/examples/cmdline/commands.c > +++ b/examples/cmdline/commands.
