* Re: [PATCH 0/3] fix Rx checksum offloads
From: Adrien Mazarguil @ 2016-11-02 15:57 UTC (permalink / raw)
To: Nelio Laranjeiro; +Cc: dev
In-Reply-To: <cover.1478082521.git.nelio.laranjeiro@6wind.com>
On Wed, Nov 02, 2016 at 11:39:36AM +0100, Nelio Laranjeiro wrote:
> Fill correctly the Mbuf Rx offloads.
>
> Nelio Laranjeiro (3):
> net/mlx5: fix Rx checksum macros
> net/mlx5: define explicit fields for Rx offloads
> net/mlx: fix support for new Rx checksum flags
>
> drivers/net/mlx4/mlx4.c | 21 ++++------
> drivers/net/mlx5/mlx5_prm.h | 37 +++++++++++++++++-
> drivers/net/mlx5/mlx5_rxtx.c | 93 ++++++++++++++++++++------------------------
> 3 files changed, 87 insertions(+), 64 deletions(-)
>
> --
> 2.1.4
Thanks. For the series:
Acked-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
--
Adrien Mazarguil
6WIND
^ permalink raw reply
* Re: [PATCH 0/2] update mlx5 release note and guide
From: Adrien Mazarguil @ 2016-11-02 15:58 UTC (permalink / raw)
To: Nelio Laranjeiro; +Cc: dev
In-Reply-To: <cover.1478094292.git.nelio.laranjeiro@6wind.com>
On Wed, Nov 02, 2016 at 02:46:42PM +0100, Nelio Laranjeiro wrote:
> Nelio Laranjeiro (2):
> doc: update mlx5 dependencies
> doc: add mlx5 release notes
>
> doc/guides/nics/mlx5.rst | 8 +-
> doc/guides/rel_notes/release_16_11.rst | 136 ++++++++++++++++++++++++++-------
> 2 files changed, 114 insertions(+), 30 deletions(-)
>
> --
> 2.1.4
Acked-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
--
Adrien Mazarguil
6WIND
^ permalink raw reply
* [PATCH] scripts: fix quiet checkpatch
From: Thomas Monjalon @ 2016-11-02 16:10 UTC (permalink / raw)
To: dev
The commit e13fbc065c7f ("scripts: improve quiet checkpatch")
removed the line "total: 1 errors, 0 warnings, 7 lines checked"
from the quiet report.
Later, commit e7c38f471384 ("scripts: remove useless checkpatch notes")
removed few lines before "total:.*lines checked", so it was not working
well for quiet reporting.
Better to keep the "total:" line in quiet mode and remove the other ones.
That's why the checkpatch.pl option --no-summary is not used anymore
by reverting the commit "improve quiet checkpatch".
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
---
scripts/checkpatches.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/checkpatches.sh b/scripts/checkpatches.sh
index 622a5b6..5286fe6 100755
--- a/scripts/checkpatches.sh
+++ b/scripts/checkpatches.sh
@@ -64,7 +64,7 @@ verbose=false
while getopts hn:qv ARG ; do
case $ARG in
n ) number=$OPTARG ;;
- q ) quiet=true && options="$options --no-summary" ;;
+ q ) quiet=true ;;
v ) verbose=true ;;
h ) print_usage ; exit 0 ;;
? ) print_usage ; exit 1 ;;
--
2.7.0
^ permalink raw reply related
* [PATCH] scripts: add standard input to checkpatch
From: Thomas Monjalon @ 2016-11-02 16:10 UTC (permalink / raw)
To: dev
It is now possible to check a patch by providing an email
through stdin.
It is especially useful to automate checkpatch run when
receiving an email.
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
---
scripts/checkpatches.sh | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/scripts/checkpatches.sh b/scripts/checkpatches.sh
index 5286fe6..0f3ed9d 100755
--- a/scripts/checkpatches.sh
+++ b/scripts/checkpatches.sh
@@ -53,7 +53,7 @@ print_usage () {
Run Linux kernel checkpatch.pl with DPDK options.
The environment variable DPDK_CHECKPATCH_PATH must be set.
- The patches to check can be from files specified on the command line,
+ The patches to check can be from stdin, files specified on the command line,
or latest git commits limited with -n option (default limit: origin/master).
END_OF_HELP
}
@@ -90,6 +90,8 @@ check () { # <patch> <commit> <title>
elif [ -n "$2" ] ; then
report=$(git format-patch --no-stat --stdout -1 $commit |
$DPDK_CHECKPATCH_PATH $options - 2>/dev/null)
+ else
+ report=$($DPDK_CHECKPATCH_PATH $options - 2>/dev/null)
fi
[ $? -ne 0 ] || continue
$verbose || printf '\n### %s\n\n' "$3"
@@ -97,7 +99,15 @@ check () { # <patch> <commit> <title>
status=$(($status + 1))
}
-if [ -z "$1" ] ; then
+if [ ! -t 0 ] ; then # stdin
+ subject=$(while read header value ; do
+ if [ "$header" = 'Subject:' ] ; then
+ echo $value
+ break
+ fi
+ done)
+ check '' '' "$subject"
+elif [ -z "$1" ] ; then
if [ $number -eq 0 ] ; then
commits=$(git rev-list --reverse origin/master..)
else
--
2.7.0
^ permalink raw reply related
* Re: [PATCH] igb_uio: fix build with backported kernel
From: martin_curran-gray @ 2016-11-02 16:19 UTC (permalink / raw)
To: dev
Hi ,
Sorry, struggling to see what happened to this thread
I managed to get dpdk 2.2.0 to build on CentOs 6.8 by sorting the MSIX_ENTRY_CTRL_MASKBIT
But I'm trying to get 16.7 to run on 6.8, and am hitting the vlan_tx_tag_present(_skb)
I tried just putting a bare
#define vlan_tx_tag_present(_skb) 0
line in the two kcompat.h files
one for igb and one for ixgbe
but I'm hitting other issues now.
/root/mcgray/dpdk-16.07/x86_64-native-linuxapp-gcc/build/lib/librte_eal/linuxapp/kni/kni_misc.c:441:20: error: macro "alloc_netdev" passed 4 arguments, but takes just 3
I had already turned of KNI in my config file, so why is the dpdk-setup.sh even trying to build this stuff??
I don't need KNI as far as I know
I saw mention of backported kernel?
I guess my 16.7 is a few months old now, if I go and get another download will this all just go away?
Thanks
Sry, this stuff all a bit beyond my experience so far.
Martin Curran-Gray
^ permalink raw reply
* Re: [PATCH] igb_uio: fix build with backported kernel
From: Ferruh Yigit @ 2016-11-02 16:30 UTC (permalink / raw)
To: martin_curran-gray, dev
In-Reply-To: <22C95CA62CBADB498D32A348F0F073BC269617BF@wcosexch02k.cos.is.keysight.com>
On 11/2/2016 4:19 PM, martin_curran-gray@keysight.com wrote:
> Hi ,
>
> Sorry, struggling to see what happened to this thread
>
> I managed to get dpdk 2.2.0 to build on CentOs 6.8 by sorting the MSIX_ENTRY_CTRL_MASKBIT
>
> But I'm trying to get 16.7 to run on 6.8, and am hitting the vlan_tx_tag_present(_skb)
>
> I tried just putting a bare
> #define vlan_tx_tag_present(_skb) 0
> line in the two kcompat.h files
> one for igb and one for ixgbe
>
> but I'm hitting other issues now.
>
> /root/mcgray/dpdk-16.07/x86_64-native-linuxapp-gcc/build/lib/librte_eal/linuxapp/kni/kni_misc.c:441:20: error: macro "alloc_netdev" passed 4 arguments, but takes just 3
>
> I had already turned of KNI in my config file, so why is the dpdk-setup.sh even trying to build this stuff??
I guess it is not disabled properly. How are you disabling KNI?
>
> I don't need KNI as far as I know
>
> I saw mention of backported kernel?
>
> I guess my 16.7 is a few months old now, if I go and get another download will this all just go away?
>
> Thanks
>
> Sry, this stuff all a bit beyond my experience so far.
>
>
>
> Martin Curran-Gray
>
^ permalink raw reply
* Re: [PATCH] igb_uio: fix build with backported kernel
From: martin_curran-gray @ 2016-11-02 16:40 UTC (permalink / raw)
To: ferruh.yigit, dev
In-Reply-To: <1b6c6350-3ba3-e9c5-d61f-df148c08793c@intel.com>
Hi,
I set
CONFIG_RTE_LIBRTE_KNI=n
In common_linux_app
Hmmm I didn't set
CONFIG_RTE_KNI_KMOD=n
It was a y
Lets see
Ah success
Thanks!
M.
-----Original Message-----
From: Ferruh Yigit [mailto:ferruh.yigit@intel.com]
Sent: 02 November 2016 16:31
To: CURRAN-GRAY,MARTIN (K-Scotland,ex1) <martin_curran-gray@keysight.com>; dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH] igb_uio: fix build with backported kernel
On 11/2/2016 4:19 PM, martin_curran-gray@keysight.com wrote:
> Hi ,
>
> Sorry, struggling to see what happened to this thread
>
> I managed to get dpdk 2.2.0 to build on CentOs 6.8 by sorting the MSIX_ENTRY_CTRL_MASKBIT
>
> But I'm trying to get 16.7 to run on 6.8, and am hitting the vlan_tx_tag_present(_skb)
>
> I tried just putting a bare
> #define vlan_tx_tag_present(_skb) 0
> line in the two kcompat.h files
> one for igb and one for ixgbe
>
> but I'm hitting other issues now.
>
> /root/mcgray/dpdk-16.07/x86_64-native-linuxapp-gcc/build/lib/librte_eal/linuxapp/kni/kni_misc.c:441:20: error: macro "alloc_netdev" passed 4 arguments, but takes just 3
>
> I had already turned of KNI in my config file, so why is the dpdk-setup.sh even trying to build this stuff??
I guess it is not disabled properly. How are you disabling KNI?
>
> I don't need KNI as far as I know
>
> I saw mention of backported kernel?
>
> I guess my 16.7 is a few months old now, if I go and get another download will this all just go away?
>
> Thanks
>
> Sry, this stuff all a bit beyond my experience so far.
>
>
>
> Martin Curran-Gray
>
^ permalink raw reply
* Re: [PATCH] E1000: fix for forced speed/duplex config
From: Ferruh Yigit @ 2016-11-02 17:36 UTC (permalink / raw)
To: Ananda Sathyanarayana, wenzhuo.lu; +Cc: dev
In-Reply-To: <1478040424-102624-1-git-send-email-ananda@versa-networks.com>
Hi Ananda,
Thank you for the patch. Can you please take care a few minor issues?
Patch tag should be: "net/e1000:", so patch title becomes:
"net/e1000: fix for forced speed/duplex config"
On 11/1/2016 10:47 PM, Ananda Sathyanarayana wrote:
> From the code, it looks like, hw->mac.autoneg, variable is used to
> switch between calling either autoneg function or forcing
> speed/duplex function. But this variable is not modified in
> eth_em_start/eth_igb_start routines (it is always set to 1)
> even while forcing the link speed.
>
> Following discussion thread has some more information on
> this
>
> http://dpdk.org/ml/archives/dev/2016-October/049272.html
Requires a fixes line:
http://dpdk.org/doc/guides/contributing/patches.html#commit-messages-body
>
> Signed-off-by: Ananda Sathyanarayana <ananda@versa-networks.com>
You can keep Wenzhuo's ack for next version of the patch.
Acked-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
> ---
> drivers/net/e1000/em_ethdev.c | 16 ++++++++++++++--
> drivers/net/e1000/igb_ethdev.c | 16 ++++++++++++++--
> 2 files changed, 28 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/e1000/em_ethdev.c b/drivers/net/e1000/em_ethdev.c
> index 7cf5f0c..a2412f5 100644
> --- a/drivers/net/e1000/em_ethdev.c
> +++ b/drivers/net/e1000/em_ethdev.c
> @@ -639,6 +639,7 @@ eth_em_start(struct rte_eth_dev *dev)
> speeds = &dev->data->dev_conf.link_speeds;
> if (*speeds == ETH_LINK_SPEED_AUTONEG) {
> hw->phy.autoneg_advertised = E1000_ALL_SPEED_DUPLEX;
> + hw->mac.autoneg = 1;
checkpatch gives many whitespace errors.
>From coding style document:
"Global whitespace rule in DPDK, use tabs for indentation, spaces for
alignment."
And how to use checkpatch:
http://dpdk.org/doc/guides/contributing/patches.html#checking-the-patches
> } else {
> num_speeds = 0;
> autoneg = (*speeds & ETH_LINK_SPEED_FIXED) == 0;
> @@ -672,9 +673,20 @@ eth_em_start(struct rte_eth_dev *dev)
> hw->phy.autoneg_advertised |= ADVERTISE_1000_FULL;
> num_speeds++;
> }
> - if (num_speeds == 0 || (!autoneg && (num_speeds > 1)))
> + if (num_speeds == 0 || (!autoneg && (num_speeds > 1))) {
No need to update this line, dpdk coding style doesn't require
parenthesis for single line statement:
http://dpdk.org/doc/guides/contributing/coding_style.html#control-statements-and-loops
> goto error_invalid_config;
> - }
> + }
> + /*
> + * Set/reset the mac.autoneg based on the link speed,
> + * fixed or not
> + */
> + if (!autoneg) {
> + hw->mac.autoneg = 0;
> + hw->mac.forced_speed_duplex = hw->phy.autoneg_advertised;
This line over 80 character limit.
> + } else {
> + hw->mac.autoneg = 1;
> + }
> + }
>
> e1000_setup_link(hw);
>
> diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
Same comments valid for this file too.
Thanks,
ferruh
^ permalink raw reply
* [PATCH] crypto: clarify how crypto operations affect buffers
From: Fiona Trahe @ 2016-11-02 17:53 UTC (permalink / raw)
To: dev
Updated comments on API to clarify which parts of mbufs are
copied or changed by crypto operations.
Signed-off-by: Fiona Trahe <fiona.trahe@intel.com>
---
lib/librte_cryptodev/rte_crypto_sym.h | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/lib/librte_cryptodev/rte_crypto_sym.h b/lib/librte_cryptodev/rte_crypto_sym.h
index 693774e..d3d38e4 100644
--- a/lib/librte_cryptodev/rte_crypto_sym.h
+++ b/lib/librte_cryptodev/rte_crypto_sym.h
@@ -366,6 +366,25 @@ struct rte_cryptodev_sym_session;
* it must have a valid *rte_mbuf* structure attached, via m_src parameter,
* which contains the source data which the crypto operation is to be performed
* on.
+ * While the mbuf is in use by a crypto operation no part of the mbuf should be
+ * changed by the application as the device may read or write to any part of the
+ * mbuf. In the case of hardware crypto devices some or all of the mbuf
+ * may be DMAed in and out of the device, so writing over the original data,
+ * though only the part specified by the rte_crypto_sym_op for transformation
+ * will be changed.
+ * Out-of-place (OOP) operation, where the source mbuf is different to the
+ * destination mbuf, is a special case. Data will be copied from m_src to m_dst.
+ * The part copied includes all the parts of the source mbuf that will be
+ * operated on, based on the cipher.data.offset+cipher.data.length and
+ * auth.data.offset+auth.data.length values in the rte_crypto_sym_op. The part
+ * indicated by the cipher parameters will be transformed, any extra data around
+ * this indicated by the auth parameters will be copied unchanged from source to
+ * destination mbuf.
+ * Also in OOP operation the cipher.data.offset and auth.data.offset apply to
+ * both source and destination mbufs. As these offsets are relative to the
+ * data_off parameter in each mbuf this can result in the data written to the
+ * destination buffer being at a different alignment, relative to buffer start,
+ * to the data in the source buffer.
*/
struct rte_crypto_sym_op {
struct rte_mbuf *m_src; /**< source mbuf */
--
2.5.0
^ permalink raw reply related
* [PATCH v2] E1000: fix for forced speed/duplex config
From: Ananda Sathyanarayana @ 2016-11-02 23:36 UTC (permalink / raw)
To: wenzhuo.lu; +Cc: dev
Fixed the formating/syntax issues reported
>From the code, it looks like, hw->mac.autoneg, variable is used to
switch between calling either autoneg function or forcing
speed/duplex function. But this variable is not modified in
eth_em_start/eth_igb_start routines (it is always set to 1)
even while forcing the link speed.
Following discussion thread has some more information on
this
http://dpdk.org/ml/archives/dev/2016-October/049272.html
Signed-off-by: Ananda Sathyanarayana <ananda@versa-networks.com>
---
drivers/net/e1000/em_ethdev.c | 12 ++++++++++++
drivers/net/e1000/igb_ethdev.c | 12 ++++++++++++
2 files changed, 24 insertions(+)
diff --git a/drivers/net/e1000/em_ethdev.c b/drivers/net/e1000/em_ethdev.c
index 7cf5f0c..aee3d34 100644
--- a/drivers/net/e1000/em_ethdev.c
+++ b/drivers/net/e1000/em_ethdev.c
@@ -639,6 +639,7 @@ eth_em_start(struct rte_eth_dev *dev)
speeds = &dev->data->dev_conf.link_speeds;
if (*speeds == ETH_LINK_SPEED_AUTONEG) {
hw->phy.autoneg_advertised = E1000_ALL_SPEED_DUPLEX;
+ hw->mac.autoneg = 1;
} else {
num_speeds = 0;
autoneg = (*speeds & ETH_LINK_SPEED_FIXED) == 0;
@@ -674,6 +675,17 @@ eth_em_start(struct rte_eth_dev *dev)
}
if (num_speeds == 0 || (!autoneg && (num_speeds > 1)))
goto error_invalid_config;
+
+ /* Set/reset the mac.autoneg based on the link speed,
+ * fixed or not
+ */
+ if (!autoneg) {
+ hw->mac.autoneg = 0;
+ hw->mac.forced_speed_duplex =
+ hw->phy.autoneg_advertised;
+ } else {
+ hw->mac.autoneg = 1;
+ }
}
e1000_setup_link(hw);
diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index 4924396..2fddf0c 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -1327,6 +1327,7 @@ eth_igb_start(struct rte_eth_dev *dev)
speeds = &dev->data->dev_conf.link_speeds;
if (*speeds == ETH_LINK_SPEED_AUTONEG) {
hw->phy.autoneg_advertised = E1000_ALL_SPEED_DUPLEX;
+ hw->mac.autoneg = 1;
} else {
num_speeds = 0;
autoneg = (*speeds & ETH_LINK_SPEED_FIXED) == 0;
@@ -1362,6 +1363,17 @@ eth_igb_start(struct rte_eth_dev *dev)
}
if (num_speeds == 0 || (!autoneg && (num_speeds > 1)))
goto error_invalid_config;
+
+ /* Set/reset the mac.autoneg based on the link speed,
+ * fixed or not
+ */
+ if (!autoneg) {
+ hw->mac.autoneg = 0;
+ hw->mac.forced_speed_duplex =
+ hw->phy.autoneg_advertised;
+ } else {
+ hw->mac.autoneg = 1;
+ }
}
e1000_setup_link(hw);
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v2] E1000: fix for forced speed/duplex config
From: Lu, Wenzhuo @ 2016-11-03 0:35 UTC (permalink / raw)
To: Ananda Sathyanarayana; +Cc: dev@dpdk.org
In-Reply-To: <1478129815-241504-1-git-send-email-ananda@versa-networks.com>
Hi,
> -----Original Message-----
> From: Ananda Sathyanarayana [mailto:ananda@versa-networks.com]
> Sent: Thursday, November 3, 2016 7:37 AM
> To: Lu, Wenzhuo
> Cc: dev@dpdk.org; Ananda Sathyanarayana
> Subject: [PATCH v2] E1000: fix for forced speed/duplex config
>
> Fixed the formating/syntax issues reported
>
> From the code, it looks like, hw->mac.autoneg, variable is used to switch
> between calling either autoneg function or forcing speed/duplex function. But
> this variable is not modified in eth_em_start/eth_igb_start routines (it is always
> set to 1) even while forcing the link speed.
>
> Following discussion thread has some more information on this
>
> http://dpdk.org/ml/archives/dev/2016-October/049272.html
>
> Signed-off-by: Ananda Sathyanarayana <ananda@versa-networks.com>
Acked-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
^ permalink raw reply
* Re: [PATCH v3] net/kni: add KNI PMD
From: Yong Wang @ 2016-11-03 1:24 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: dev@dpdk.org
In-Reply-To: <20161010131946.13303-1-ferruh.yigit@intel.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ferruh Yigit
> Sent: Monday, October 10, 2016 6:20 AM
> To: dev@dpdk.org
> Cc: Ferruh Yigit <ferruh.yigit@intel.com>
> Subject: [dpdk-dev] [PATCH v3] net/kni: add KNI PMD
>
> Add KNI PMD which wraps librte_kni for ease of use.
>
> KNI PMD can be used as any regular PMD to send / receive packets to the
> Linux networking stack.
>
> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
> ---
>
> v3:
> * rebase on top of latest master
>
> v2:
> * updated driver name eth_kni -> net_kni
> ---
> config/common_base | 1 +
> config/common_linuxapp | 1 +
> drivers/net/Makefile | 1 +
> drivers/net/kni/Makefile | 63 +++++
> drivers/net/kni/rte_eth_kni.c | 463
> ++++++++++++++++++++++++++++++++
> drivers/net/kni/rte_pmd_kni_version.map | 4 +
> mk/rte.app.mk | 10 +-
> 7 files changed, 538 insertions(+), 5 deletions(-)
> create mode 100644 drivers/net/kni/Makefile
> create mode 100644 drivers/net/kni/rte_eth_kni.c
> create mode 100644 drivers/net/kni/rte_pmd_kni_version.map
>
> diff --git a/config/common_base b/config/common_base
> index f5d2eff..03b93c7 100644
> --- a/config/common_base
> +++ b/config/common_base
> @@ -543,6 +543,7 @@ CONFIG_RTE_PIPELINE_STATS_COLLECT=n
> # Compile librte_kni
> #
> CONFIG_RTE_LIBRTE_KNI=n
> +CONFIG_RTE_LIBRTE_PMD_KNI=n
Nit: change this to CONFIG_RTE_LIBRTE_KNI_PMD instead to be consistent with all other pmds.
> CONFIG_RTE_KNI_KMOD=n
> CONFIG_RTE_KNI_PREEMPT_DEFAULT=y
> CONFIG_RTE_KNI_KO_DEBUG=n
> diff --git a/config/common_linuxapp b/config/common_linuxapp
> index 2483dfa..2ecd510 100644
> --- a/config/common_linuxapp
> +++ b/config/common_linuxapp
> @@ -39,6 +39,7 @@ CONFIG_RTE_EAL_IGB_UIO=y
> CONFIG_RTE_EAL_VFIO=y
> CONFIG_RTE_KNI_KMOD=y
> CONFIG_RTE_LIBRTE_KNI=y
> +CONFIG_RTE_LIBRTE_PMD_KNI=y
> CONFIG_RTE_LIBRTE_VHOST=y
> CONFIG_RTE_LIBRTE_PMD_VHOST=y
> CONFIG_RTE_LIBRTE_PMD_AF_PACKET=y
> diff --git a/drivers/net/Makefile b/drivers/net/Makefile
> index bc93230..c4771cd 100644
> --- a/drivers/net/Makefile
> +++ b/drivers/net/Makefile
> @@ -41,6 +41,7 @@ DIRS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += enic
> DIRS-$(CONFIG_RTE_LIBRTE_FM10K_PMD) += fm10k
> DIRS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e
> DIRS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += ixgbe
> +DIRS-$(CONFIG_RTE_LIBRTE_PMD_KNI) += kni
> DIRS-$(CONFIG_RTE_LIBRTE_MLX4_PMD) += mlx4
> DIRS-$(CONFIG_RTE_LIBRTE_MLX5_PMD) += mlx5
> DIRS-$(CONFIG_RTE_LIBRTE_MPIPE_PMD) += mpipe
> diff --git a/drivers/net/kni/Makefile b/drivers/net/kni/Makefile
> new file mode 100644
> index 0000000..0b7cf91
> --- /dev/null
> +++ b/drivers/net/kni/Makefile
> @@ -0,0 +1,63 @@
> +# BSD LICENSE
> +#
> +# Copyright(c) 2016 Intel Corporation. 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.
> +
> +include $(RTE_SDK)/mk/rte.vars.mk
> +
> +#
> +# library name
> +#
> +LIB = librte_pmd_kni.a
> +
> +CFLAGS += -O3
> +CFLAGS += $(WERROR_FLAGS)
> +LDLIBS += -lpthread
> +
> +EXPORT_MAP := rte_pmd_kni_version.map
> +
> +LIBABIVER := 1
> +
> +#
> +# all source are stored in SRCS-y
> +#
> +SRCS-$(CONFIG_RTE_LIBRTE_PMD_KNI) += rte_eth_kni.c
> +
> +#
> +# Export include files
> +#
> +SYMLINK-y-include +=
> +
> +# this lib depends upon:
> +DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_KNI) += lib/librte_eal
> +DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_KNI) += lib/librte_ether
> +DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_KNI) += lib/librte_kni
> +DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_KNI) += lib/librte_mbuf
> +DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_KNI) += lib/librte_mempool
> +
> +include $(RTE_SDK)/mk/rte.lib.mk
> diff --git a/drivers/net/kni/rte_eth_kni.c b/drivers/net/kni/rte_eth_kni.c
> new file mode 100644
> index 0000000..ce9e758
> --- /dev/null
> +++ b/drivers/net/kni/rte_eth_kni.c
> @@ -0,0 +1,463 @@
> +/*-
> + * 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.
> + */
> +
> +#include <fcntl.h>
> +#include <pthread.h>
> +#include <unistd.h>
> +
> +#include <rte_ethdev.h>
> +#include <rte_kni.h>
> +#include <rte_malloc.h>
> +#include <rte_vdev.h>
> +
> +#define KNI_MAX_QUEUE_PER_PORT 8
> +#define MAX_PACKET_SZ 2048
> +#define MAX_KNI_PORTS 8
> +#define DRV_NAME net_kni
The name generated this way is not consistent with other vdevs. Why not simply assign "KNI PMD" to drv_name?
> +
> +struct pmd_queue_stats {
> + uint64_t pkts;
> + uint64_t bytes;
> + uint64_t err_pkts;
> +};
> +
> +struct pmd_queue {
> + struct pmd_internals *internals;
> + struct rte_mempool *mb_pool;
> +
> + struct pmd_queue_stats rx;
> + struct pmd_queue_stats tx;
> +};
> +
> +struct pmd_internals {
> + struct rte_kni *kni;
> + int is_kni_started;
> +
> + pthread_t thread;
> + int stop_thread;
> +
> + struct pmd_queue rx_queues[KNI_MAX_QUEUE_PER_PORT];
> + struct pmd_queue tx_queues[KNI_MAX_QUEUE_PER_PORT];
> +};
> +
> +static struct ether_addr eth_addr;
> +static const char *drivername = RTE_STR(DRV_NAME);
> +static struct rte_eth_link pmd_link = {
> + .link_speed = 10000,
> + .link_duplex = ETH_LINK_FULL_DUPLEX,
> + .link_status = 0
> +};
> +static int is_kni_initialized;
> +
> +static uint16_t
> +eth_kni_rx(void *q, struct rte_mbuf **bufs, uint16_t nb_bufs)
> +{
> + struct pmd_queue *kni_q = q;
> + struct rte_kni *kni = kni_q->internals->kni;
> + uint16_t nb_pkts;
> +
> + nb_pkts = rte_kni_rx_burst(kni, bufs, nb_bufs);
> +
> + kni_q->rx.pkts += nb_pkts;
> + kni_q->rx.err_pkts += nb_bufs - nb_pkts;
> +
> + return nb_pkts;
> +}
> +
I don't think it's safe to do receive from two queues concurrently on two cores sharing the same underlying KNI device due to the current limitation of KNI user-space queues not being multi-thread safe. Is the proposed plan to have the application layer implement synchronization logic? If that's the case, it needs to be clearly documented and depending on the implementation, measurable overhead will be incurred. Otherwise (only single-queue supported), could you check queue number if the application tries to configure multi-queue?
> +static uint16_t
> +eth_kni_tx(void *q, struct rte_mbuf **bufs, uint16_t nb_bufs)
> +{
> + struct pmd_queue *kni_q = q;
> + struct rte_kni *kni = kni_q->internals->kni;
> + uint16_t nb_pkts;
> +
> + nb_pkts = rte_kni_tx_burst(kni, bufs, nb_bufs);
> +
> + kni_q->tx.pkts += nb_pkts;
> + kni_q->tx.err_pkts += nb_bufs - nb_pkts;
> +
> + return nb_pkts;
> +}
> +
> +static void *
> +kni_handle_request(void *param)
> +{
> + struct pmd_internals *internals = param;
> +#define MS 1000
> +
> + while (!internals->stop_thread) {
> + rte_kni_handle_request(internals->kni);
> + usleep(500 * MS);
> + }
> +
> + return param;
> +}
> +
> +static int
> +eth_kni_start(struct rte_eth_dev *dev)
> +{
> + struct pmd_internals *internals = dev->data->dev_private;
> + uint16_t port_id = dev->data->port_id;
> + struct rte_mempool *mb_pool;
> + struct rte_kni_conf conf;
> + const char *name = dev->data->name + 4; /* remove eth_ */
> +
> + snprintf(conf.name, RTE_KNI_NAMESIZE, "%s", name);
> + conf.force_bind = 0;
> + conf.group_id = port_id;
> + conf.mbuf_size = MAX_PACKET_SZ;
> + mb_pool = internals->rx_queues[0].mb_pool;
> +
> + internals->kni = rte_kni_alloc(mb_pool, &conf, NULL);
> + if (internals->kni == NULL) {
> + RTE_LOG(ERR, PMD,
> + "Fail to create kni for port: %d\n", port_id);
> + return -1;
> + }
> +
> + return 0;
> +}
> +
> +static int
> +eth_kni_dev_start(struct rte_eth_dev *dev)
> +{
> + struct pmd_internals *internals = dev->data->dev_private;
> + int ret;
> +
> + if (internals->is_kni_started == 0) {
> + ret = eth_kni_start(dev);
> + if (ret)
> + return -1;
> + internals->is_kni_started = 1;
> + }
> +
> + ret = pthread_create(&internals->thread, NULL, kni_handle_request,
> + internals);
> + if (ret) {
> + RTE_LOG(ERR, PMD, "Fail to create kni request thread\n");
> + return -1;
> + }
> +
> + dev->data->dev_link.link_status = 1;
> +
> + return 0;
> +}
> +
> +static void
> +eth_kni_dev_stop(struct rte_eth_dev *dev)
> +{
> + struct pmd_internals *internals = dev->data->dev_private;
> + int ret;
> +
> + internals->stop_thread = 1;
> +
> + ret = pthread_cancel(internals->thread);
> + if (ret)
> + RTE_LOG(ERR, PMD, "Can't cancel the thread\n");
> +
> + ret = pthread_join(internals->thread, NULL);
> + if (ret)
> + RTE_LOG(ERR, PMD, "Can't join the thread\n");
> +
> + internals->stop_thread = 0;
> +
> + dev->data->dev_link.link_status = 0;
> +}
> +
> +static int
> +eth_kni_dev_configure(struct rte_eth_dev *dev __rte_unused)
> +{
> + return 0;
> +}
> +
> +static void
> +eth_kni_dev_info(struct rte_eth_dev *dev, struct rte_eth_dev_info
> *dev_info)
> +{
> + struct rte_eth_dev_data *data = dev->data;
> + struct pmd_internals *internals = data->dev_private;
> +
> + dev_info->driver_name = data->drv_name;
> + dev_info->max_mac_addrs = 1;
> + dev_info->max_rx_pktlen = (uint32_t)-1;
> + dev_info->max_rx_queues = RTE_DIM(internals->rx_queues);
> + dev_info->max_tx_queues = RTE_DIM(internals->tx_queues);
> + dev_info->min_rx_bufsize = 0;
> + dev_info->pci_dev = NULL;
> +}
> +
> +static int
> +eth_kni_rx_queue_setup(struct rte_eth_dev *dev,
> + uint16_t rx_queue_id,
> + uint16_t nb_rx_desc __rte_unused,
> + unsigned int socket_id __rte_unused,
> + const struct rte_eth_rxconf *rx_conf __rte_unused,
> + struct rte_mempool *mb_pool)
> +{
> + struct pmd_internals *internals = dev->data->dev_private;
> + struct pmd_queue *q;
> +
> + q = &internals->rx_queues[rx_queue_id];
> + q->internals = internals;
> + q->mb_pool = mb_pool;
> +
> + dev->data->rx_queues[rx_queue_id] = q;
> +
> + return 0;
> +}
> +
> +static int
> +eth_kni_tx_queue_setup(struct rte_eth_dev *dev,
> + uint16_t tx_queue_id,
> + uint16_t nb_tx_desc __rte_unused,
> + unsigned int socket_id __rte_unused,
> + const struct rte_eth_txconf *tx_conf __rte_unused)
> +{
> + struct pmd_internals *internals = dev->data->dev_private;
> + struct pmd_queue *q;
> +
> + q = &internals->tx_queues[tx_queue_id];
> + q->internals = internals;
> +
> + dev->data->tx_queues[tx_queue_id] = q;
> +
> + return 0;
> +}
> +
> +static void
> +eth_kni_queue_release(void *q __rte_unused)
> +{
> +}
> +
> +static int
> +eth_kni_link_update(struct rte_eth_dev *dev __rte_unused,
> + int wait_to_complete __rte_unused)
> +{
> + return 0;
> +}
> +
> +static void
> +eth_kni_stats_get(struct rte_eth_dev *dev, struct rte_eth_stats *stats)
> +{
> + unsigned long rx_packets_total = 0, rx_bytes_total = 0;
> + unsigned long tx_packets_total = 0, tx_bytes_total = 0;
> + struct rte_eth_dev_data *data = dev->data;
> + unsigned long tx_packets_err_total = 0;
> + unsigned int i, num_stats;
> + struct pmd_queue *q;
> +
> + num_stats = RTE_MIN((unsigned
> int)RTE_ETHDEV_QUEUE_STAT_CNTRS,
> + data->nb_rx_queues);
> + for (i = 0; i < num_stats; i++) {
> + q = data->rx_queues[i];
> + stats->q_ipackets[i] = q->rx.pkts;
> + stats->q_ibytes[i] = q->rx.bytes;
> + rx_packets_total += stats->q_ipackets[i];
> + rx_bytes_total += stats->q_ibytes[i];
> + }
> +
> + num_stats = RTE_MIN((unsigned
> int)RTE_ETHDEV_QUEUE_STAT_CNTRS,
> + data->nb_tx_queues);
> + for (i = 0; i < num_stats; i++) {
> + q = data->tx_queues[i];
> + stats->q_opackets[i] = q->tx.pkts;
> + stats->q_obytes[i] = q->tx.bytes;
> + stats->q_errors[i] = q->tx.err_pkts;
> + tx_packets_total += stats->q_opackets[i];
> + tx_bytes_total += stats->q_obytes[i];
> + tx_packets_err_total += stats->q_errors[i];
> + }
> +
> + stats->ipackets = rx_packets_total;
> + stats->ibytes = rx_bytes_total;
> + stats->opackets = tx_packets_total;
> + stats->obytes = tx_bytes_total;
> + stats->oerrors = tx_packets_err_total;
> +}
> +
> +static void
> +eth_kni_stats_reset(struct rte_eth_dev *dev)
> +{
> + struct rte_eth_dev_data *data = dev->data;
> + struct pmd_queue *q;
> + unsigned int i;
> +
> + for (i = 0; i < data->nb_rx_queues; i++) {
> + q = data->rx_queues[i];
> + q->rx.pkts = 0;
> + q->rx.bytes = 0;
> + }
> + for (i = 0; i < data->nb_tx_queues; i++) {
> + q = data->tx_queues[i];
> + q->tx.pkts = 0;
> + q->tx.bytes = 0;
> + q->tx.err_pkts = 0;
> + }
> +}
> +
> +static const struct eth_dev_ops eth_kni_ops = {
> + .dev_start = eth_kni_dev_start,
> + .dev_stop = eth_kni_dev_stop,
> + .dev_configure = eth_kni_dev_configure,
> + .dev_infos_get = eth_kni_dev_info,
> + .rx_queue_setup = eth_kni_rx_queue_setup,
> + .tx_queue_setup = eth_kni_tx_queue_setup,
> + .rx_queue_release = eth_kni_queue_release,
> + .tx_queue_release = eth_kni_queue_release,
> + .link_update = eth_kni_link_update,
> + .stats_get = eth_kni_stats_get,
> + .stats_reset = eth_kni_stats_reset,
> +};
> +
> +static struct rte_eth_dev *
> +eth_kni_create(const char *name, unsigned int numa_node)
> +{
> + struct pmd_internals *internals = NULL;
> + struct rte_eth_dev_data *data;
> + struct rte_eth_dev *eth_dev;
> + uint16_t nb_rx_queues = 1;
> + uint16_t nb_tx_queues = 1;
Since these two values are always 1 here, I think they could be removed.
> +
> + RTE_LOG(INFO, PMD, "Creating kni ethdev on numa socket %u\n",
> + numa_node);
> +
> + data = rte_zmalloc_socket(name, sizeof(*data), 0, numa_node);
> + if (data == NULL)
> + goto error;
> +
> + internals = rte_zmalloc_socket(name, sizeof(*internals), 0,
> numa_node);
> + if (internals == NULL)
> + goto error;
> +
> + /* reserve an ethdev entry */
> + eth_dev = rte_eth_dev_allocate(name);
> + if (eth_dev == NULL)
> + goto error;
> +
> + data->dev_private = internals;
> + data->port_id = eth_dev->data->port_id;
> + memmove(data->name, eth_dev->data->name, sizeof(data-
> >name));
> + data->nb_rx_queues = nb_rx_queues;
> + data->nb_tx_queues = nb_tx_queues;
> + data->dev_link = pmd_link;
> + data->mac_addrs = ð_addr;
> +
> + eth_dev->data = data;
> + eth_dev->dev_ops = ð_kni_ops;
> + eth_dev->driver = NULL;
> +
> + data->dev_flags = RTE_ETH_DEV_DETACHABLE;
> + data->kdrv = RTE_KDRV_NONE;
> + data->drv_name = drivername;
> + data->numa_node = numa_node;
> +
> + return eth_dev;
> +
> +error:
> + rte_free(data);
> + rte_free(internals);
> +
> + return NULL;
> +}
> +
> +static int
> +kni_init(void)
> +{
> + if (is_kni_initialized == 0)
> + rte_kni_init(MAX_KNI_PORTS);
> +
> + is_kni_initialized += 1;
> +
> + return 0;
> +}
> +
> +static int
> +eth_kni_probe(const char *name, const char *params __rte_unused)
> +{
> + struct rte_eth_dev *eth_dev;
> + int ret;
> +
> + RTE_LOG(INFO, PMD, "Initializing eth_kni for %s\n", name);
> +
> + ret = kni_init();
> + if (ret < 0)
> + /* Not return error to prevent panic in rte_eal_init() */
> + return 0;
> +
> + eth_dev = eth_kni_create(name, rte_socket_id());
> + if (eth_dev == NULL)
> + return -1;
> +
> + eth_dev->rx_pkt_burst = eth_kni_rx;
> + eth_dev->tx_pkt_burst = eth_kni_tx;
> +
> + return 0;
> +}
> +
> +static int
> +eth_kni_remove(const char *name)
> +{
> + struct rte_eth_dev *eth_dev;
> + struct pmd_internals *internals;
> +
> + RTE_LOG(INFO, PMD, "Un-Initializing eth_kni for %s\n", name);
> +
> + /* find the ethdev entry */
> + eth_dev = rte_eth_dev_allocated(name);
> + if (eth_dev == NULL)
> + return -1;
> +
> + eth_kni_dev_stop(eth_dev);
> +
> + if (eth_dev->data) {
> + internals = eth_dev->data->dev_private;
> + rte_kni_release(internals->kni);
> +
> + rte_free(internals);
> + }
> + rte_free(eth_dev->data);
> +
> + rte_eth_dev_release_port(eth_dev);
> +
> + is_kni_initialized -= 1;
> + if (is_kni_initialized == 0)
> + rte_kni_close();
> +
> + return 0;
> +}
> +
> +static struct rte_vdev_driver eth_kni_drv = {
> + .probe = eth_kni_probe,
> + .remove = eth_kni_remove,
> +};
> +
> +DRIVER_REGISTER_VDEV(DRV_NAME, eth_kni_drv);
> diff --git a/drivers/net/kni/rte_pmd_kni_version.map
> b/drivers/net/kni/rte_pmd_kni_version.map
> new file mode 100644
> index 0000000..61463bf
> --- /dev/null
> +++ b/drivers/net/kni/rte_pmd_kni_version.map
> @@ -0,0 +1,4 @@
> +DPDK_16.11 {
> +
> + local: *;
> +};
> diff --git a/mk/rte.app.mk b/mk/rte.app.mk
> index ac50a21..a94983b 100644
> --- a/mk/rte.app.mk
> +++ b/mk/rte.app.mk
> @@ -59,11 +59,6 @@ _LDLIBS-y += -L$(RTE_SDK_BIN)/lib
> #
> # Order is important: from higher level to lower level
> #
> -
> -ifeq ($(CONFIG_RTE_EXEC_ENV_LINUXAPP),y)
> -_LDLIBS-$(CONFIG_RTE_LIBRTE_KNI) += -lrte_kni
> -endif
> -
> _LDLIBS-$(CONFIG_RTE_LIBRTE_PIPELINE) += -lrte_pipeline
> _LDLIBS-$(CONFIG_RTE_LIBRTE_TABLE) += -lrte_table
> _LDLIBS-$(CONFIG_RTE_LIBRTE_PORT) += -lrte_port
> @@ -84,6 +79,10 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_POWER) += -
> lrte_power
>
> _LDLIBS-y += --whole-archive
>
> +ifeq ($(CONFIG_RTE_EXEC_ENV_LINUXAPP),y)
> +_LDLIBS-$(CONFIG_RTE_LIBRTE_KNI) += -lrte_kni
> +endif
> +
> _LDLIBS-$(CONFIG_RTE_LIBRTE_TIMER) += -lrte_timer
> _LDLIBS-$(CONFIG_RTE_LIBRTE_HASH) += -lrte_hash
> _LDLIBS-$(CONFIG_RTE_LIBRTE_VHOST) += -lrte_vhost
> @@ -114,6 +113,7 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += -
> lrte_pmd_enic
> _LDLIBS-$(CONFIG_RTE_LIBRTE_FM10K_PMD) += -lrte_pmd_fm10k
> _LDLIBS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += -lrte_pmd_i40e
> _LDLIBS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += -lrte_pmd_ixgbe
> +_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_KNI) += -lrte_pmd_kni
> _LDLIBS-$(CONFIG_RTE_LIBRTE_MLX4_PMD) += -lrte_pmd_mlx4 -
> libverbs
> _LDLIBS-$(CONFIG_RTE_LIBRTE_MLX5_PMD) += -lrte_pmd_mlx5 -
> libverbs
> _LDLIBS-$(CONFIG_RTE_LIBRTE_MPIPE_PMD) += -lrte_pmd_mpipe -lgxio
> --
> 2.7.4
^ permalink raw reply
* Re: [PATCH] ethdev: fix statistics description
From: Remy Horton @ 2016-11-03 2:00 UTC (permalink / raw)
To: Mcnamara, John, Dai, Wei, Thomas Monjalon, Ananyev, Konstantin,
Wu, Jingjing, Zhang, Helin, Curran, Greg, Van Haaren, Harry
Cc: dev@dpdk.org
In-Reply-To: <B27915DBBA3421428155699D51E4CFE2026488B9@IRSMSX103.ger.corp.intel.com>
On 02/11/2016 17:07, Mcnamara, John wrote:
[..]
> Perhaps we could an API that returns a struct, or otherwise, that
> indicated what stats are returned by a PMD. An application that
> required stats could call it once to establish what stats were
> available. It would have to be done in some way that wouldn't break
> ABI every time a new stat was added.
>
> Harry, Remy, how would this fit in with the existing stats scheme or
> the new metrics library.
At the moment xstats (rte_eth_xstats_get()) pulls stuff out of
rte_eth_stats and reports them unconditionally alongside all the
driver-specific xstats. This could change so that it only reports the
(legacy) stats the PMDs actually fills in.
Personally in the longer term I think xstats should get all the info it
requires directly rather than relying on the legacy stats for some of
its info, but that would involve pushing a lot of common code into the
PMDs..
..Remy
^ permalink raw reply
* Re: [PATCH v3] app/test: fix a segfault when lpm_perf_autotest is run more than 1 time
From: Dai, Wei @ 2016-11-03 3:28 UTC (permalink / raw)
To: Nikita Kozlov, dev@dpdk.org, Richardson, Bruce, Dai, Wei
In-Reply-To: <20161101115555.12867-1-nikita@elyzion.net>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Nikita Kozlov
> Sent: Tuesday, November 1, 2016 7:56 PM
> To: dev@dpdk.org
> Subject: [dpdk-dev] [PATCH v3] app/test: fix a segfault when lpm_perf_autotest
> is run more than 1 time
>
> num_route_entries need to be reseted.
>
> Fixes: 17d60f5b5eea ("app/test: remove large IPv4 LPM data file")
>
> Signed-off-by: Nikita Kozlov <nikita@elyzion.net>
Tested-by: Bruce Richardson <bruce.richardson@intel.com>
Tested-by: Wei Dai <wei.dai@intel.com>
Acked-by: Wei Dai <wei.dai@intel.com>
> ---
> app/test/test_lpm_perf.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/app/test/test_lpm_perf.c b/app/test/test_lpm_perf.c index
> 608e17a..e7e1281 100644
> --- a/app/test/test_lpm_perf.c
> +++ b/app/test/test_lpm_perf.c
> @@ -301,6 +301,7 @@ static void generate_large_route_rule_table(void)
> uint32_t ip_class;
> uint8_t depth;
>
> + num_route_entries = 0;
> memset(large_route_table, 0, sizeof(large_route_table));
>
> for (ip_class = IP_CLASS_A; ip_class <= IP_CLASS_C; ip_class++) {
> --
> 2.9.2
^ permalink raw reply
* Re: [RFC]Generic flow filtering API Sample Application
From: Jerin Jacob @ 2016-11-03 3:40 UTC (permalink / raw)
To: Zhao1, Wei; +Cc: dev@dpdk.org
In-Reply-To: <A2573D2ACFCADC41BB3BE09C6DE313CA01FE9D0F@PGSMSX103.gar.corp.intel.com>
On Wed, Nov 02, 2016 at 05:27:50AM +0000, Zhao1, Wei wrote:
> Hi All,
> Now we are planning for an sample application for Generic flow
> filtering API feature, and I have finished the RFC for this example app.
> Now Adrien Mazarguil has send v2 version of Generic flow
> filtering API, this sample application RFC is based on that.
>
> Thank you.
>
>
>
>
> Generic flow filtering API Sample Application
> ============================================
>
> The application is a simple example of generic flow filtering API using the DPDK.
> The application performs flow director/filtering/classification in packet processing.
>
> Overview
> --------
>
> The application demonstrates the use of generic flow director/filtering/classification API
> in the DPDK to implement packet forwarding.And this document focus on the guide line of writing rules configuration
> files and prompt commands usage. It also supply the definition of the available EAL options arguments which is useful
> in DPDK packet forwarding processing.
>
>
> Compiling the Application
> -------------------------
>
> To compile the application:
>
> #. Go to the sample application directory:
>
> .. code-block:: console
>
> export RTE_SDK=/path/to/rte_sdk
> cd ${RTE_SDK}/examples/gen_filter
Any specific reason to create a separate application for testing the generic
filter but not as a extension to testpmd?
>
^ permalink raw reply
* Re: [PATCH v4] vhost: Add indirect descriptors support to the TX path
From: Maxime Coquelin @ 2016-11-03 8:11 UTC (permalink / raw)
To: Wang, Zhihong, Yuanhan Liu
Cc: mst@redhat.com, dev@dpdk.org, vkaplans@redhat.com
In-Reply-To: <c1899521-2dee-75a4-4723-a8cf851a18d1@redhat.com>
On 11/02/2016 11:51 AM, Maxime Coquelin wrote:
>
>
> On 10/31/2016 11:01 AM, Wang, Zhihong wrote:
>>
>>
>>> -----Original Message-----
>>> From: Maxime Coquelin [mailto:maxime.coquelin@redhat.com]
>>> Sent: Friday, October 28, 2016 3:42 PM
>>> To: Wang, Zhihong <zhihong.wang@intel.com>; Yuanhan Liu
>>> <yuanhan.liu@linux.intel.com>
>>> Cc: stephen@networkplumber.org; Pierre Pfister (ppfister)
>>> <ppfister@cisco.com>; Xie, Huawei <huawei.xie@intel.com>; dev@dpdk.org;
>>> vkaplans@redhat.com; mst@redhat.com
>>> Subject: Re: [dpdk-dev] [PATCH v4] vhost: Add indirect descriptors
>>> support
>>> to the TX path
>>>
>>>
>>>
>>> On 10/28/2016 02:49 AM, Wang, Zhihong wrote:
>>>>
>>>>>> -----Original Message-----
>>>>>> From: Yuanhan Liu [mailto:yuanhan.liu@linux.intel.com]
>>>>>> Sent: Thursday, October 27, 2016 6:46 PM
>>>>>> To: Maxime Coquelin <maxime.coquelin@redhat.com>
>>>>>> Cc: Wang, Zhihong <zhihong.wang@intel.com>;
>>>>>> stephen@networkplumber.org; Pierre Pfister (ppfister)
>>>>>> <ppfister@cisco.com>; Xie, Huawei <huawei.xie@intel.com>;
>>> dev@dpdk.org;
>>>>>> vkaplans@redhat.com; mst@redhat.com
>>>>>> Subject: Re: [dpdk-dev] [PATCH v4] vhost: Add indirect descriptors
>>> support
>>>>>> to the TX path
>>>>>>
>>>>>> On Thu, Oct 27, 2016 at 12:35:11PM +0200, Maxime Coquelin wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 10/27/2016 12:33 PM, Yuanhan Liu wrote:
>>>>>>>>>> On Thu, Oct 27, 2016 at 11:10:34AM +0200, Maxime Coquelin
>>> wrote:
>>>>>>>>>>>> Hi Zhihong,
>>>>>>>>>>>>
>>>>>>>>>>>> On 10/27/2016 11:00 AM, Wang, Zhihong wrote:
>>>>>>>>>>>>>> Hi Maxime,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Seems indirect desc feature is causing serious performance
>>>>>>>>>>>>>> degradation on Haswell platform, about 20% drop for both
>>>>>>>>>>>>>> mrg=on and mrg=off (--txqflags=0xf00, non-vector version),
>>>>>>>>>>>>>> both iofwd and macfwd.
>>>>>>>>>>>> I tested PVP (with macswap on guest) and Txonly/Rxonly on an
>>> Ivy
>>>>>> Bridge
>>>>>>>>>>>> platform, and didn't faced such a drop.
>>>>>>>>>>
>>>>>>>>>> I was actually wondering that may be the cause. I tested it with
>>>>>>>>>> my IvyBridge server as well, I saw no drop.
>>>>>>>>>>
>>>>>>>>>> Maybe you should find a similar platform (Haswell) and have a
>>>>>>>>>> try?
>>>>>>>> Yes, that's why I asked Zhihong whether he could test Txonly in
>>>>>>>> guest
>>> to
>>>>>>>> see if issue is reproducible like this.
>>>>>>
>>>>>> I have no Haswell box, otherwise I could do a quick test for you.
>>>>>> IIRC,
>>>>>> he tried to disable the indirect_desc feature, then the performance
>>>>>> recovered. So, it's likely the indirect_desc is the culprit here.
>>>>>>
>>>>>>>> I will be easier for me to find an Haswell machine if it has not
>>>>>>>> to be
>>>>>>>> connected back to back to and HW/SW packet generator.
>>>> In fact simple loopback test will also do, without pktgen.
>>>>
>>>> Start testpmd in both host and guest, and do "start" in one
>>>> and "start tx_first 32" in another.
>>>>
>>>> Perf drop is about 24% in my test.
>>>>
>>>
>>> Thanks, I never tried this test.
>>> I managed to find an Haswell platform (Intel(R) Xeon(R) CPU E5-2699 v3
>>> @ 2.30GHz), and can reproduce the problem with the loop test you
>>> mention. I see a performance drop about 10% (8.94Mpps/8.08Mpps).
>>> Out of curiosity, what are the numbers you get with your setup?
>>
>> Hi Maxime,
>>
>> Let's align our test case to RC2, mrg=on, loopback, on Haswell.
>> My results below:
>> 1. indirect=1: 5.26 Mpps
>> 2. indirect=0: 6.54 Mpps
>>
>> It's about 24% drop.
> OK, so on my side, same setup on Haswell:
> 1. indirect=1: 7.44 Mpps
> 2. indirect=0: 8.18 Mpps
>
> Still 10% drop in my case with mrg=on.
>
> The strange thing with both of our figures is that this is below from
> what I obtain with my SandyBridge machine. The SB cpu freq is 4% higher,
> but that doesn't explain the gap between the measurements.
>
> I'm continuing the investigations on my side.
> Maybe we should fix a deadline, and decide do disable indirect in
> Virtio PMD if root cause not identified/fixed at some point?
>
> Yuanhan, what do you think?
I have done some measurements using perf, and know understand better
what happens.
With indirect descriptors, I can see a cache miss when fetching the
descriptors in the indirect table. Actually, this is expected, so
we prefetch the first desc as soon as possible, but still not soon
enough to make it transparent.
In direct descriptors case, the desc in the virtqueue seems to be
remain in the cache from its previous use, so we have a hit.
That said, in realistic use-case, I think we should not have a hit,
even with direct descriptors.
Indeed, the test case use testpmd on guest side with the forwarding set
in IO mode. It means the packet content is never accessed by the guest.
In my experiments, I am used to set the "macswap" forwarding mode, which
swaps src and dest MAC addresses in the packet. I find it more
realistic, because I don't see the point in sending packets to the guest
if it is not accessed (not even its header).
I tried again the test case, this time with setting the forwarding mode
to macswap in the guest. This time, I get same performance with both
direct and indirect (indirect even a little better with a small
optimization, consisting in prefetching the 2 first descs
systematically as we know there are contiguous).
Do you agree we should assume that the packet (header or/and buf) will
always be accessed by the guest application?
If so, do you agree we should keep indirect descs enabled, and maybe
update the test cases?
Thanks,
Maxime
^ permalink raw reply
* Re: [PATCH] ethdev: fix statistics description
From: Morten Brørup @ 2016-11-03 9:07 UTC (permalink / raw)
To: Remy Horton, Mcnamara, John, Dai, Wei, Thomas Monjalon,
Ananyev, Konstantin, Wu, Jingjing, Zhang, Helin, Curran, Greg,
Van Haaren, Harry
Cc: dev
In-Reply-To: <a93bfb85-490c-a9cc-7982-d9e879cf4120@intel.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Remy Horton
> Sent: Thursday, November 3, 2016 3:01 AM
>
> On 02/11/2016 17:07, Mcnamara, John wrote:
> [..]
> > Perhaps we could an API that returns a struct, or otherwise, that
> > indicated what stats are returned by a PMD. An application that
> > required stats could call it once to establish what stats were
> > available. It would have to be done in some way that wouldn't break
> > ABI every time a new stat was added.
> >
> > Harry, Remy, how would this fit in with the existing stats scheme or
> > the new metrics library.
>
> At the moment xstats (rte_eth_xstats_get()) pulls stuff out of
> rte_eth_stats and reports them unconditionally alongside all the
> driver-specific xstats. This could change so that it only reports the
> (legacy) stats the PMDs actually fills in.
>
> Personally in the longer term I think xstats should get all the info it
> requires directly rather than relying on the legacy stats for some of
> its info, but that would involve pushing a lot of common code into the
> PMDs..
>
> ..Remy
Adding eth_stats to eth_xstats or not is not important - it's not a synchronized snapshot of the entire counter set, just a question of calling one or two functions to obtain the values.
Regarding eth_xstats, I would dare to say that the NIC HW designers chose their statistics counters wisely, based on a combination of industry standards (e.g. common SNMP MIBs, such as the Interfaces MIB and etherStats) and customer feedback, so the hardware counters are probably useful to a DPDK application, and thus it makes sense to expose them directly. The application can transform them into industry standard counter sets (IF-MIB, etherStats, etc.) if required. DPDK could offer a common library for this transformation.
-Morten
^ permalink raw reply
* PCAP memory leak in freeing jumbo frames
From: Dror Birkman @ 2016-11-03 9:35 UTC (permalink / raw)
To: dev; +Cc: Nicolas Pernas Maradei, ferruh.yigit
Hi,
I have a huge memory leak when I release mbufs allocated
by eth_pcap_rx_jumbo().
I use rte_mempool_put_bulk() to release the mbufs.
To my horror I found out it puts back to the mempool only the head mbuf and
not its segments!
I know rte_pktmbuf_free() frees the mbuf and all it segments, but afaik it
is not thread safe.
What is the thread safe way to free mbufs (preferably in bulk) and their
segments?
TIA,
Dror
^ permalink raw reply
* [PATCH] lpm: fix freeing memory
From: Wei Dai @ 2016-11-03 10:15 UTC (permalink / raw)
To: dev, mb
The memory pointed by lpm->rules_tbl should also be freed
when memory malloc for tbl8 fails in rte_lpm_create_v1604( ).
And the memory pointed by lpm->tbl8 should also be freed
when the lpm object is freed in rte_lpm_free_v1604( ).
Fixes: f1f7261838b3 ("lpm: add a new config structure for IPv4")
Signed-off-by: Morten Brørup <mb@smartsharesystems.com>
Signed-off-by: Wei Dai <wei.dai@intel.com>
---
lib/librte_lpm/rte_lpm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/librte_lpm/rte_lpm.c b/lib/librte_lpm/rte_lpm.c
index ec67765..8c15c4c 100644
--- a/lib/librte_lpm/rte_lpm.c
+++ b/lib/librte_lpm/rte_lpm.c
@@ -321,6 +321,7 @@ rte_lpm_create_v1604(const char *name, int socket_id,
if (lpm->tbl8 == NULL) {
RTE_LOG(ERR, LPM, "LPM tbl8 memory allocation failed\n");
+ rte_free(lpm->rules_tbl);
rte_free(lpm);
lpm = NULL;
rte_free(te);
@@ -402,6 +403,7 @@ rte_lpm_free_v1604(struct rte_lpm *lpm)
rte_rwlock_write_unlock(RTE_EAL_TAILQ_RWLOCK);
+ rte_free(lpm->tbl8);
rte_free(lpm->rules_tbl);
rte_free(lpm);
rte_free(te);
--
2.7.4
^ permalink raw reply related
* Re: PCAP memory leak in freeing jumbo frames
From: Bruce Richardson @ 2016-11-03 10:23 UTC (permalink / raw)
To: Dror Birkman; +Cc: dev, Nicolas Pernas Maradei, ferruh.yigit
In-Reply-To: <CAMLkaUvupSKK0=5RHPVikVSXgHEioehRpSYpLLcSobOgR+USkA@mail.gmail.com>
On Thu, Nov 03, 2016 at 11:35:14AM +0200, Dror Birkman wrote:
> Hi,
>
> I have a huge memory leak when I release mbufs allocated
> by eth_pcap_rx_jumbo().
>
> I use rte_mempool_put_bulk() to release the mbufs.
> To my horror I found out it puts back to the mempool only the head mbuf and
> not its segments!
>
> I know rte_pktmbuf_free() frees the mbuf and all it segments, but afaik it
> is not thread safe.
>
> What is the thread safe way to free mbufs (preferably in bulk) and their
> segments?
>
I'm not aware of any thread-safety differences between mempool_put and
pktmbuf_free - which in the end just calls mempool_put for each segment.
For freeing mbufs with multiple segments, I think you'll have to use the
regular mbuf_free function, or write your own special bulk version.
/Bruce
^ permalink raw reply
* Re: [PATCH] doc: announce ABI changes in filtering support
From: Mcnamara, John @ 2016-11-03 11:42 UTC (permalink / raw)
To: Stroe, Laura, dev@dpdk.org
In-Reply-To: <C8045DE8B0CAD9439AF22540DABEA3481E2CE69D@IRSMSX102.ger.corp.intel.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Stroe, Laura
> Sent: Wednesday, November 2, 2016 3:12 PM
> To: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] doc: announce ABI changes in filtering
> support
>
> Self-Nack.
> After an internal review of ABI breakage announcements we found a way of
> achieving this with an ABI change.
>
Hi Laura,
I guess this should say *without* an ABI change. :-)
Thanks,
John
^ permalink raw reply
* [PATCH] examples/ipsec-secgw: fix buffer not null terminated
From: Fan Zhang @ 2016-11-03 12:12 UTC (permalink / raw)
To: dev
Fixes: 0d547ed03717 ("examples/ipsec-secgw: support configuration file")
Coverity issue: 137854
Signed-off-by: Fan Zhang <roy.fan.zhang@intel.com>
---
examples/ipsec-secgw/parser.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/examples/ipsec-secgw/parser.c b/examples/ipsec-secgw/parser.c
index 99bdfc5..e09a7c0 100644
--- a/examples/ipsec-secgw/parser.c
+++ b/examples/ipsec-secgw/parser.c
@@ -248,7 +248,7 @@ parse_ipv4_addr(const char *token, struct in_addr *ipv4, uint32_t *mask)
if (mask)
*mask = atoi(pch);
} else {
- strncpy(ip_str, token, sizeof(ip_str));
+ strncpy(ip_str, token, sizeof(ip_str) - 1);
if (mask)
*mask = 0;
}
--
2.5.5
^ permalink raw reply related
* [PATCH] examples/ipsec-secgw: fix buffer not terminated issue
From: Fan Zhang @ 2016-11-03 12:12 UTC (permalink / raw)
To: dev
In-Reply-To: <1478175163-229116-1-git-send-email-roy.fan.zhang@intel.com>
Fixes: 0d547ed03717 ("examples/ipsec-secgw: support configuration file")
Coverity issue: 137855
Signed-off-by: Fan Zhang <roy.fan.zhang@intel.com>
---
examples/ipsec-secgw/parser.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/examples/ipsec-secgw/parser.c b/examples/ipsec-secgw/parser.c
index 99bdfc5..ede08d8 100644
--- a/examples/ipsec-secgw/parser.c
+++ b/examples/ipsec-secgw/parser.c
@@ -277,7 +277,7 @@ parse_ipv6_addr(const char *token, struct in6_addr *ipv6, uint32_t *mask)
if (mask)
*mask = atoi(pch);
} else {
- strncpy(ip_str, token, sizeof(ip_str));
+ strncpy(ip_str, token, sizeof(ip_str) - 1);
if (mask)
*mask = 0;
}
--
2.5.5
^ permalink raw reply related
* [PATCH] examples/ipsec-secgw: fix copy into fixed size buffer issue
From: Fan Zhang @ 2016-11-03 12:12 UTC (permalink / raw)
To: dev
In-Reply-To: <1478175163-229116-1-git-send-email-roy.fan.zhang@intel.com>
Coverity issue: 137875
Fixes: 0d547ed0 ("examples/ipsec-secgw: support configuration
file")
Signed-off-by: Fan Zhang <roy.fan.zhang@intel.com>
---
examples/ipsec-secgw/sa.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/examples/ipsec-secgw/sa.c b/examples/ipsec-secgw/sa.c
index 9e2c8a9..c891be2 100644
--- a/examples/ipsec-secgw/sa.c
+++ b/examples/ipsec-secgw/sa.c
@@ -177,7 +177,7 @@ parse_key_string(const char *key_str, uint8_t *key)
pt_end = strchr(pt_start, ':');
if (pt_end == NULL)
- strncpy(sub_str, pt_start, strlen(pt_start));
+ strncpy(sub_str, pt_start, strlen(sub_str) - 1);
else {
if (pt_end - pt_start > 2)
return 0;
--
2.5.5
^ permalink raw reply related
* [PATCH] examples/ipsec-secgw: fix pointer to local outside scope
From: Fan Zhang @ 2016-11-03 12:12 UTC (permalink / raw)
To: dev
In-Reply-To: <1478175163-229116-1-git-send-email-roy.fan.zhang@intel.com>
Fixes: 0d547ed03717 ("examples/ipsec-secgw: support configuration file")
Coverity issue: 137871
Signed-off-by: Fan Zhang <roy.fan.zhang@intel.com>
---
examples/ipsec-secgw/parser.c | 124 +++++++++++++++++++++---------------------
1 file changed, 62 insertions(+), 62 deletions(-)
diff --git a/examples/ipsec-secgw/parser.c b/examples/ipsec-secgw/parser.c
index 99bdfc5..45473c7 100644
--- a/examples/ipsec-secgw/parser.c
+++ b/examples/ipsec-secgw/parser.c
@@ -503,86 +503,86 @@ parse_cfg_file(const char *cfg_filename)
do {
char oneline[1024];
-
+ char *pos;
get_s = fgets(oneline, 1024, f);
- if (get_s) {
- char *pos;
- line_num++;
+ if (!get_s)
+ break;
- if (strlen(oneline) > 1022) {
- rte_panic("%s:%u: error: the line "
- "contains more characters the "
- "parser can handle\n",
- cfg_filename, line_num);
- goto error_exit;
- }
+ line_num++;
- /* process comment char '#' */
- if (oneline[0] == '#')
- continue;
+ if (strlen(oneline) > 1022) {
+ rte_panic("%s:%u: error: the line "
+ "contains more characters the "
+ "parser can handle\n",
+ cfg_filename, line_num);
+ goto error_exit;
+ }
- pos = strchr(oneline, '#');
- if (pos != NULL)
- *pos = '\0';
-
- /* process line concatenator '\' */
- pos = strchr(oneline, 92);
- if (pos != NULL) {
- if (pos != oneline+strlen(oneline) - 2) {
- rte_panic("%s:%u: error: no "
- "character should exist "
- "after '\\' symbol\n",
- cfg_filename, line_num);
- goto error_exit;
- }
-
- *pos = '\0';
-
- if (strlen(oneline) + strlen(str) > 1022) {
- rte_panic("%s:%u: error: the "
- "concatenated line "
- "contains more characters "
- "the parser can handle\n",
- cfg_filename, line_num);
- goto error_exit;
- }
-
- strncpy(str + strlen(str), oneline,
- strlen(oneline));
+ /* process comment char '#' */
+ if (oneline[0] == '#')
+ continue;
- continue;
+ pos = strchr(oneline, '#');
+ if (pos != NULL)
+ *pos = '\0';
+
+ /* process line concatenator '\' */
+ pos = strchr(oneline, 92);
+ if (pos != NULL) {
+ if (pos != oneline+strlen(oneline) - 2) {
+ rte_panic("%s:%u: error: no "
+ "character should exist "
+ "after '\\' symbol\n",
+ cfg_filename, line_num);
+ goto error_exit;
}
- /* copy the line to str and process */
+ *pos = '\0';
+
if (strlen(oneline) + strlen(str) > 1022) {
- rte_panic("%s:%u: error: the line "
- "contains more characters the "
- "parser can handle\n",
+ rte_panic("%s:%u: error: the "
+ "concatenated line "
+ "contains more characters "
+ "the parser can handle\n",
cfg_filename, line_num);
goto error_exit;
}
+
strncpy(str + strlen(str), oneline,
strlen(oneline));
- str[strlen(str)] = '\n';
- if (cmdline_parse(cl, str) < 0) {
- rte_panic("%s:%u: error: parsing \"%s\" "
- "failed\n", cfg_filename,
- line_num, str);
- goto error_exit;
- }
+ continue;
+ }
- if (status.status < 0) {
- rte_panic("%s:%u: error: %s",
- cfg_filename, line_num,
- status.parse_msg);
- goto error_exit;
- }
+ /* copy the line to str and process */
+ if (strlen(oneline) + strlen(str) > 1022) {
+ rte_panic("%s:%u: error: the line "
+ "contains more characters the "
+ "parser can handle\n",
+ cfg_filename, line_num);
+ goto error_exit;
+ }
+ strncpy(str + strlen(str), oneline,
+ strlen(oneline));
+
+ str[strlen(str)] = '\n';
+ if (cmdline_parse(cl, str) < 0) {
+ rte_panic("%s:%u: error: parsing \"%s\" "
+ "failed\n", cfg_filename,
+ line_num, str);
+ goto error_exit;
+ }
- memset(str, 0, 1024);
+ if (status.status < 0) {
+ rte_panic("%s:%u: error: %s",
+ cfg_filename, line_num,
+ status.parse_msg);
+ goto error_exit;
}
- } while (get_s != NULL);
+
+ memset(str, 0, 1024);
+ } while (1);
cmdline_stdin_exit(cl);
fclose(f);
--
2.5.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox