Re: [dpdk-dev] [PATCH] mark experimental variables
On 12/2/19 6:20 PM, David Marchand wrote:
> So far, we did not pay attention to direct access to variables but they
> are part of the API/ABI too and should be clearly identified.
>
> Introduce a __rte_experimental_var tag and mark existing exported
> variables.
>
> Fixes: a4bcd61de82d ("buildtools: add script to check experimental API
> exports")
> Cc: sta...@dpdk.org
>
> Signed-off-by: David Marchand
Acked-by: Andrew Rybchenko
[dpdk-dev] [PATCH 1/2] net/i40e: set fixed flag for exact link speed
Setting exact link speed makes sense if auto-negotiation is
disabled. Fixed flag is required to disable auto-negotiation.
Signed-off-by: Guinan Sun
---
drivers/net/i40e/i40e_ethdev.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 5999c964b..631400fdc 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -2241,6 +2241,9 @@ i40e_apply_link_speed(struct rte_eth_dev *dev)
struct i40e_hw *hw = I40E_DEV_PRIVATE_TO_HW(dev->data->dev_private);
struct rte_eth_conf *conf = &dev->data->dev_conf;
+ abilities |= I40E_AQ_PHY_ENABLE_ATOMIC_LINK |
+I40E_AQ_PHY_LINK_ENABLED;
+
if (conf->link_speeds == ETH_LINK_SPEED_AUTONEG) {
conf->link_speeds = ETH_LINK_SPEED_40G |
ETH_LINK_SPEED_25G |
@@ -2248,11 +2251,12 @@ i40e_apply_link_speed(struct rte_eth_dev *dev)
ETH_LINK_SPEED_10G |
ETH_LINK_SPEED_1G |
ETH_LINK_SPEED_100M;
+
+ abilities |= I40E_AQ_PHY_AN_ENABLED;
+ } else {
+ abilities &= ~I40E_AQ_PHY_AN_ENABLED;
}
speed = i40e_parse_link_speeds(conf->link_speeds);
- abilities |= I40E_AQ_PHY_ENABLE_ATOMIC_LINK |
-I40E_AQ_PHY_AN_ENABLED |
-I40E_AQ_PHY_LINK_ENABLED;
return i40e_phy_conf_link(hw, abilities, speed, true);
}
@@ -2271,13 +2275,6 @@ i40e_dev_start(struct rte_eth_dev *dev)
hw->adapter_stopped = 0;
- if (dev->data->dev_conf.link_speeds & ETH_LINK_SPEED_FIXED) {
- PMD_INIT_LOG(ERR,
- "Invalid link_speeds for port %u, autonegotiation disabled",
- dev->data->port_id);
- return -EINVAL;
- }
-
rte_intr_disable(intr_handle);
if ((rte_intr_cap_multiple(intr_handle) ||
--
2.17.1
[dpdk-dev] [PATCH 0/2] drivers/net: set fixed flag for exact link speed
Setting exact link speed makes sense if auto-negotiation is disabled. Fixed flag is required to disable auto-negotiation. Guinan Sun (2): net/i40e: set fixed flag for exact link speed net/ixgbe: set fixed flag for exact link speed drivers/net/i40e/i40e_ethdev.c | 17 +++-- drivers/net/ixgbe/ixgbe_ethdev.c | 20 +++- 2 files changed, 14 insertions(+), 23 deletions(-) -- 2.17.1
[dpdk-dev] [PATCH 2/2] net/ixgbe: set fixed flag for exact link speed
Setting exact link speed makes sense if auto-negotiation is
disabled. Fixed flag is required to disable auto-negotiation.
Signed-off-by: Guinan Sun
---
drivers/net/ixgbe/ixgbe_ethdev.c | 20 +++-
1 file changed, 7 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 2c6fd0f13..e1ab1dcab 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -2558,17 +2558,6 @@ ixgbe_dev_start(struct rte_eth_dev *dev)
PMD_INIT_FUNC_TRACE();
- /* IXGBE devices don't support:
- *- half duplex (checked afterwards for valid speeds)
- *- fixed speed: TODO implement
- */
- if (dev->data->dev_conf.link_speeds & ETH_LINK_SPEED_FIXED) {
- PMD_INIT_LOG(ERR,
- "Invalid link_speeds for port %u, fix speed not supported",
- dev->data->port_id);
- return -EINVAL;
- }
-
/* Stop the link setup handler before resetting the HW. */
rte_eal_alarm_cancel(ixgbe_dev_setup_link_alarm_handler, dev);
@@ -2724,7 +2713,11 @@ ixgbe_dev_start(struct rte_eth_dev *dev)
}
link_speeds = &dev->data->dev_conf.link_speeds;
- if (*link_speeds & ~allowed_speeds) {
+
+ /* Ignore??autoneg flag??bit??and check??the validity??of??
+* link_speed??
+*/
+ if (((*link_speeds) >> 1) & ~(allowed_speeds >> 1)) {
PMD_INIT_LOG(ERR, "Invalid link setting");
goto error;
}
@@ -4133,7 +4126,8 @@ ixgbe_dev_link_update_share(struct rte_eth_dev *dev,
link.link_status = ETH_LINK_DOWN;
link.link_speed = ETH_SPEED_NUM_NONE;
link.link_duplex = ETH_LINK_HALF_DUPLEX;
- link.link_autoneg = ETH_LINK_AUTONEG;
+ link.link_autoneg = !(dev->data->dev_conf.link_speeds &
+ ETH_LINK_SPEED_FIXED);
hw->mac.get_link_status = true;
--
2.17.1
Re: [dpdk-dev] [PATCH] kernel/linux: fix kernel dir for meson
On Tue, Dec 03, 2019 at 01:33:19PM +0800, Ye Xiaolong wrote: > On 12/02, Bruce Richardson wrote: > >On Mon, Dec 02, 2019 at 07:34:54PM +0800, Ye Xiaolong wrote: > >> On 12/02, Igor Ryzhov wrote: > >> >We should at least install it into /lib/modules/kernel-version. For > >> >convenience, dpdk modules are installed into > >> >/lib/modules/kernel-version/extra/dpdk. > >> >In the cross-compilation case, you can use DEST_DIR to set some prefix. > >> > > >> >I don't really see the issue here. The description clearly says that > >> >headers must be in $kernel_dir/build which is usually a symlink > >> >to /usr/src/linux-headers-kernel-version. > >> >Just set kernel_dir correctly and there won't be compilation failure. > >> > >> I think for cross-compilation case, user should be allowed to specify any > >> kernel > >> src dir (it doesn't have to be /lib/modules/kernel-version) in his local > >> system > >> as kernel_dir that doesn't contain the build dir, in this case, current > >> meson > >> build will skip kernel module compilation. > >> > > > >I don't think we can take this change as the default, since the previous > >fix was put in for good reason. > > > >However, perhaps we can attempt to support both, using the checks below for > >"make kernelversion" in kernel/linux/meson.build. We can attempt using the > >directory with /build (as now) and then if that fails attempt without it (or > >vice versa). > > After a second thought, I think it'd be better that we unify the meaning of > kernel_dir for both cases, it should be aligned with make's RTE_KERNELDIR > variable that specify the directory contains kernel src code (or header), then > we don't need to distinguish these 2 cases in check (make kernelversion) > phase, > we just need to assign different install dirs, > > For normal case: > > kernel_dir=/lib/modules//build > install_dir=/lib/modules//extra/dpdk > > For cross compilation case: > > kernel_dir= > install_dir=/extra/dpdk > > What do you think (I've sent v2 according to above description)? > The downside of what you propose is that it will break any builds which are already working by passing in the base kerneldir folder as parameter. That case needs to be kept working, so you cannot force the user to pass in the path with /build on the end. /Bruce
Re: [dpdk-dev] [PATCH] version: 20.02-rc0
02/12/2019 16:29, David Marchand: > On Mon, Dec 2, 2019 at 3:57 PM Thomas Monjalon wrote: > > > > Start a new release cycle with empty release notes. > > > > Signed-off-by: Thomas Monjalon > > > > --- a/VERSION > > +++ b/VERSION > > @@ -1 +1 @@ > > -19.11.0 > > +20.02-rc0 > > 20.02.0-rc0 ? > > The rest lgtm. Applied with this change.
Re: [dpdk-dev] [PATCH v2] kernel/linux: fix kernel dir for meson
On Tue, Dec 03, 2019 at 01:29:17PM +0800, Xiaolong Ye wrote:
> kernel_dir option in meson build is equivalent to RTE_KERNELDIR in make
> system, for cross-compilation case, users would specify it as local
> kernel src dir like
>
> //target-arm_glibc/linux-arm/linux-4.19.81/
>
> Current meson build would fail to compile kernel module if user specify
> kernel_dir as above, this patch fixes this issue.
>
> Fixes: 317832f97c16 ("kernel/linux: fix modules install path")
> Cc: sta...@dpdk.org
> Cc: iryz...@nfware.com
>
> Signed-off-by: Xiaolong Ye
> ---
>
> V2 changes:
>
> 1. handle both normal and cross-compilation cases
>
We need to handle both, but they need to be handled without breaking the
currently working case where we pass in /lib/modules/$(uname -r)/ as the
kerneldir path.
/Bruce
Re: [dpdk-dev] [PATCH] net/pcap: truncate packet if it is too large
On 11/8/2019 2:33 AM, Zhike Wang wrote:
> From: Zhike Wang
>
> Previously large packet would be dropped, instead now it is better to keep it
> via truncating it.
Looks reasonable, thanks.
cc'ing Cian too, since he did some pcap work recently.
>
> Signed-off-by: Zhike Wang
> ---
> drivers/net/pcap/rte_eth_pcap.c | 16 +++-
> 1 file changed, 7 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/pcap/rte_eth_pcap.c b/drivers/net/pcap/rte_eth_pcap.c
> index 5186d8f..4614239 100644
> --- a/drivers/net/pcap/rte_eth_pcap.c
> +++ b/drivers/net/pcap/rte_eth_pcap.c
> @@ -313,7 +313,7 @@ struct pmd_devargs_all {
> struct pcap_pkthdr header;
> pcap_dumper_t *dumper;
> unsigned char temp_data[RTE_ETH_PCAP_SNAPLEN];
> - size_t len;
> + size_t len, caplen;
>
> pp = rte_eth_devices[dumper_q->port_id].process_private;
> dumper = pp->tx_dumper[dumper_q->queue_id];
> @@ -328,25 +328,23 @@ struct pmd_devargs_all {
> len = rte_pktmbuf_pkt_len(mbuf);
> if (unlikely(!rte_pktmbuf_is_contiguous(mbuf) &&
> len > sizeof(temp_data))) {
> - PMD_LOG(ERR,
> - "Dropping multi segment PCAP packet. Size (%zd)
> > max size (%zd).",
> - len, sizeof(temp_data));
> - rte_pktmbuf_free(mbuf);
> - continue;
> + caplen = sizeof(temp_data);
> + } else {
> + caplen = len;
No strong opinion, but what do you think removing the else leg by assigning the
'caplen' by default to 'len':
len = caplen = rte_pktmbuf_pkt_len(mbuf);
> }
>
> calculate_timestamp(&header.ts);
> header.len = len;
> - header.caplen = header.len;
> + header.caplen = caplen;
> /* rte_pktmbuf_read() returns a pointer to the data directly
>* in the mbuf (when the mbuf is contiguous) or, otherwise,
>* a pointer to temp_data after copying into it.
>*/
> pcap_dump((u_char *)dumper, &header,
> - rte_pktmbuf_read(mbuf, 0, len, temp_data));
> + rte_pktmbuf_read(mbuf, 0, caplen, temp_data));
>
> num_tx++;
> - tx_bytes += len;
> + tx_bytes += caplen;
> rte_pktmbuf_free(mbuf);
> }
>
>
Re: [dpdk-dev] [dpdk-stable] [PATCH] net/bonding: do not inherit slave device configuration
On 11/19/2019 12:40 PM, Andrew Rybchenko wrote:
> On 11/19/19 3:18 PM, Ferruh Yigit wrote:
>> On 11/19/2019 9:03 AM, Andrew Rybchenko wrote:
>>> Bonding device should control bonded devices configuration.
>>>
>>> Also avoid usage of slave's data->dev_conf.
>>>
>>> Fixes: 2efb58cbab6e ("bond: new link bonding library")
>>> Cc: sta...@dpdk.org
>>>
>>> Signed-off-by: Andrew Rybchenko
>>> ---
>>> drivers/net/bonding/rte_eth_bond_pmd.c | 24
>>> 1 file changed, 12 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/drivers/net/bonding/rte_eth_bond_pmd.c
>>> b/drivers/net/bonding/rte_eth_bond_pmd.c
>>> index 707a0f3cdd..4f0e83205d 100644
>>> --- a/drivers/net/bonding/rte_eth_bond_pmd.c
>>> +++ b/drivers/net/bonding/rte_eth_bond_pmd.c
>>> @@ -1679,6 +1679,7 @@ int
>>> slave_configure(struct rte_eth_dev *bonded_eth_dev,
>>> struct rte_eth_dev *slave_eth_dev)
>>> {
>>> + struct rte_eth_conf dev_conf;
>>> struct bond_rx_queue *bd_rx_q;
>>> struct bond_tx_queue *bd_tx_q;
>>> uint16_t nb_rx_queues;
>>> @@ -1693,34 +1694,34 @@ slave_configure(struct rte_eth_dev *bonded_eth_dev,
>>> /* Stop slave */
>>> rte_eth_dev_stop(slave_eth_dev->data->port_id);
>>>
>>> + memset(&dev_conf, 0, sizeof(dev_conf));
>>> +
>>> /* Enable interrupts on slave device if supported */
>>> if (slave_eth_dev->data->dev_flags & RTE_ETH_DEV_INTR_LSC)
>>> - slave_eth_dev->data->dev_conf.intr_conf.lsc = 1;
>>> + dev_conf.intr_conf.lsc = 1;
>> I assume the original intention is making incremental changes to the existing
>> slave configuration, if so we should copy the
>> 'slave_eth_dev->data->dev_conf' to
>> 'dev_conf' before start updating it.
>
> The problem is that I don't understand how incremental changes
> happen. It simply looks wrong or I don't understand something.
> It looks like it is the only place in bonding where slave configuration
> is done.
>
Hi Chas, Declan,
Can you please check the patch, and if possible comment on the initial intention
of the code?
Thanks,
ferruh
Re: [dpdk-dev] [PATCH v3 0/7] Add ABI compatibility checks to the meson build
On Fri, Nov 29, 2019 at 10:09 PM Kevin Laatz wrote:
>
> With the recent changes made to stabilize ABI versioning in DPDK, it will
> become increasingly important to check patches for ABI compatibility. We
> propose adding the ABI compatibility checking to be done as part of the
> build.
>
> The advantages to adding the ABI compatibility checking to the build are
> two-fold. Firstly, developers can easily check their patches to make sure
> they don’t break the ABI without adding any extra steps. Secondly, it
> makes the integration into existing CI seamless since there are no extra
> scripts to make the CI run. The build will run as usual and if an
> incompatibility is detected in the ABI, the build will fail and show the
> incompatibility. As an added bonus, enabling the ABI compatibility checks
> does not impact the build speed.
>
> The proposed solution works as follows:
> 1. Generate the ABI dump of the baseline. This can be done with the new
>script added in this RFC. This step will only need to be done when the
>ABI version changes (so once a year) and can be added to master so it
>exists by default. This step can be skipped if the dump files for the
>baseline already exist.
> 2. Build with meson. If there is an ABI incompatibility, the build will
>fail and print the incompatibility information.
>
> The patches accompanying this RFC add the ABI dump file generating script,
> the meson option required to enable/disable the checks, and the required
> meson changes to run the compatibility checks during the build.
Global comments:
- why are patch 1 and 2 in this series, is this really needed?
- please squash patches 3, 4, 5 and 6, reading them separately is a
pain and they are quite small,
- if Windows does not support the ABI check, enforce this earlier in
meson and refuse enabling it rather than silently ignoring it,
- I would not enable this check by default
- this is a developer option, people just building the dpdk don't
care about it,
- can we have something like a tristate "auto" (default, triggers
the check if abidiff is installed), "disabled" and "enabled" (not
having abidiff installed triggers an error) ?
- please update the travis packages so that we can run those checks
for developers submitting patches
- I don't think you tested this series with
devtools/test-meson-builds.sh, please do. It fails with a custom build
directory and in the dpdk tree too:
Build targets in project: 1019
WARNING: Project specifies a minimum meson_version '>= 0.47.1' but
uses features which were added in newer versions:
* 0.48.0: {'console arg in custom_target'}
* 0.50.0: {'install arg in configure_file'}
Found ninja-1.9.0 at /usr/bin/ninja
ninja -C /home/dmarchan/builds/build-gcc-static
ninja: Entering directory `/home/dmarchan/builds/build-gcc-static'
[48/2291] Generating librte_kvargs.abi_chk with a meson_exe.py custom command.
FAILED: lib/librte_kvargs.abi_chk
/usr/bin/meson --internal exe
/home/dmarchan/builds/build-gcc-static/meson-private/meson_exe_abidiff_6511538ddd95d9672028017110fa45c67f01f7be.dat
file /home/dmarchan/dpdk/lib/abi/librte_kvargs.dump does not exist
[77/2291] Compiling C object
'lib/76b5a35@@rte_mbuf@sta/librte_mbuf_rte_mbuf.c.o'.
ninja: build stopped: subcommand failed.
--
David Marchand
[dpdk-dev] [PATCH v3] build: add dockerfile for building docker image
Adding a Dockerfile with Ubuntu bionic base image to build dpdk as shared
library. This docker image could be used as base image to build and run
dpdk applications in containers.
Signed-off-by: Abdul Halim
---
v2:
* renamed Dockerfile name from Dockerfile.ubuntu to Dockerfile.bionic
* added call to ldconfig to update cache of libraries to include newly
installed DPDK libs
---
v3:
* added example use-case of dpdk dockerfile in extras/README.md
---
extras/Dockerfile.bionic | 40 +
extras/README.md | 52
2 files changed, 92 insertions(+)
create mode 100644 extras/Dockerfile.bionic
create mode 100644 extras/README.md
diff --git a/extras/Dockerfile.bionic b/extras/Dockerfile.bionic
new file mode 100644
index 000..f83b720
--- /dev/null
+++ b/extras/Dockerfile.bionic
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(c) 2019 Intel Corporation
+FROM ubuntu:bionic
+
+# install requirements for getting and building DPDK
+# including dependencies for DPDK features
+RUN apt-get update && apt-get install -y \
+build-essential \
+pkg-config \
+python3 \
+python3-pip \
+ninja-build \
+libjansson-dev \
+libbsd-dev \
+libnuma-dev \
+libssl-dev \
+zlib1g-dev \
+libpcap-dev \
+libibverbs-dev \
+&& pip3 install meson \
+&& apt-get clean && rm -rf /var/lib/apt/lists/*
+
+ADD . /tmp/dpdk
+
+WORKDIR /tmp/dpdk
+
+RUN meson build \
+-Ddefault_library=shared \
+-Dmachine=default \
+-Dper_library_versions=false \
+&& ninja -C build install \
+&& ldconfig \
+&& cd /; rm -rf /tmp/dpdk
+
+WORKDIR /
+
+# Installed DPDK Shared library location:
+# lib dir : /usr/local/lib/
+# include : /usr/local/include/
+# pkgconfig file: /usr/local/lib/x86_64-linux-gnu/pkgconfig/libdpdk.pc
diff --git a/extras/README.md b/extras/README.md
new file mode 100644
index 000..f38d7f1
--- /dev/null
+++ b/extras/README.md
@@ -0,0 +1,52 @@
+# Build DPDK Docker image
+
+To build a docker image run the following command from dpdk root directory.
+
+```
+DOCKER_TAG="dpdk"
+docker build -t ${DOCKER_TAG} -f extras/Dockerfile.bionic .
+```
+
+# Example of how to use this dpdk library image
+
+The following steps shows how to use the dpdk shared library container to build
+and run a dpdk application without having to build dpdk library for each
+application.
+
+## Create a dpdk sample app docker file with 'dpdk' as the base image
+
+Create a docker file to build the dpdk helloworld application. Since, we are
+creating a docker file for dpdk helloworld app we need to add the dpdk source
+files, thus create the following docker file in dpdk root directory.
+
+```
+cat << EOF > Dockerfile.dpdkSampleApp
+FROM dpdk
+
+ADD . /opt/dpdk
+
+WORKDIR /opt/dpdk/examples/helloworld
+RUN make && cp build/helloworld-shared /usr/local/bin/helloworld
+EOF
+```
+
+## Build sample app docker image
+
+```
+DOCKERAPP_TAG="dpdk-helloworld"
+docker build -t ${DOCKERAPP_TAG} -f Dockerfile.dpdkSampleApp .
+```
+
+This sample app now can be run like any other applicaiton in a docker
container.
+
+```
+$ docker run --rm -it -v /dev/hugepages:/dev/hugepages dpdk-helloworld
+```
+
+## Running the sample app
+Once inside the container run helloword binary
+
+```
+$ root@11233ed2e69c # helloworld
+```
+
--
1.8.3.1
--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
Re: [dpdk-dev] [PATCH] app/testpmd: show mac addresses added to a port
On 11/25/2019 8:27 AM, Kalesh A P wrote: > From: Kalesh AP > > Patch adds a runtime function to display the unicast and > multicast MAC addresses added to a port. > > Syntax: > show port (port_id) macs|mcast_macs > > Usage: > testpmd> show port 0 macs > Number of MAC address added: 1 > B0:26:28:7F:F5:C1 > testpmd> > testpmd> show port 0 mcast_macs > Number of Multicast MAC address added: 0 > testpmd> > testpmd> mac_addr add 0 B0:26:28:7F:22:33 > testpmd> mac_addr add 0 B0:26:28:7F:22:34 > testpmd> show port 0 macs > Number of MAC address added: 3 > B0:26:28:7F:F5:C1 > B0:26:28:7F:22:33 > B0:26:28:7F:22:34 > testpmd> > testpmd> mac_addr remove 0 B0:26:28:7F:22:33 > testpmd> show port 0 macs > Number of MAC address added: 2 > B0:26:28:7F:F5:C1 > B0:26:28:7F:22:34 > > Signed-off-by: Kalesh AP > Reviewed-by: Ajit Khaparde Reviewed-by: Ferruh Yigit > @@ -487,6 +487,21 @@ set packet types classification for a specific port:: > > testpmd> set port (port_id) ptypes_mask (mask) > > +show port mac addresses info > +~~ Causing warning [1], will fix while merging. [1] WARNING: Title underline too short. > + > +Show mac addresses added for a specific port:: > + > + testpmd> show port (port_id) macs > + > + > +show port mac addresses info > +~~ 's/mac addresses/multicast mac addresses', again I can fix while merging. > + > +Show multicast mac addresses added for a specific port:: > + > + testpmd> show port (port_id) mcast_macs > + > show device info > > >
Re: [dpdk-dev] [PATCH] app/testpmd: show mac addresses added to a port
On 12/3/2019 11:59 AM, Ferruh Yigit wrote: > On 11/25/2019 8:27 AM, Kalesh A P wrote: >> From: Kalesh AP >> >> Patch adds a runtime function to display the unicast and >> multicast MAC addresses added to a port. >> >> Syntax: >> show port (port_id) macs|mcast_macs >> >> Usage: >> testpmd> show port 0 macs >> Number of MAC address added: 1 >> B0:26:28:7F:F5:C1 >> testpmd> >> testpmd> show port 0 mcast_macs >> Number of Multicast MAC address added: 0 >> testpmd> >> testpmd> mac_addr add 0 B0:26:28:7F:22:33 >> testpmd> mac_addr add 0 B0:26:28:7F:22:34 >> testpmd> show port 0 macs >> Number of MAC address added: 3 >> B0:26:28:7F:F5:C1 >> B0:26:28:7F:22:33 >> B0:26:28:7F:22:34 >> testpmd> >> testpmd> mac_addr remove 0 B0:26:28:7F:22:33 >> testpmd> show port 0 macs >> Number of MAC address added: 2 >> B0:26:28:7F:F5:C1 >> B0:26:28:7F:22:34 >> >> Signed-off-by: Kalesh AP >> Reviewed-by: Ajit Khaparde > > Reviewed-by: Ferruh Yigit Applied to dpdk-next-net/master, thanks. (fixed doc warnings while merging.)
Re: [dpdk-dev] [PATCH v2] kernel/linux: fix kernel dir for meson
On 12/03, Bruce Richardson wrote:
>On Tue, Dec 03, 2019 at 01:29:17PM +0800, Xiaolong Ye wrote:
>> kernel_dir option in meson build is equivalent to RTE_KERNELDIR in make
>> system, for cross-compilation case, users would specify it as local
>> kernel src dir like
>>
>> //target-arm_glibc/linux-arm/linux-4.19.81/
>>
>> Current meson build would fail to compile kernel module if user specify
>> kernel_dir as above, this patch fixes this issue.
>>
>> Fixes: 317832f97c16 ("kernel/linux: fix modules install path")
>> Cc: sta...@dpdk.org
>> Cc: iryz...@nfware.com
>>
>> Signed-off-by: Xiaolong Ye
>> ---
>>
>> V2 changes:
>>
>> 1. handle both normal and cross-compilation cases
>>
>We need to handle both, but they need to be handled without breaking the
>currently working case where we pass in /lib/modules/$(uname -r)/ as the
>kerneldir path.
So you mean we should allow user to specify both /lib/modules/$(uname -r) and
/lib/modules/$(uname -r)/build as kernel_dir for normal case?
Thanks,
Xiaolong
>
>/Bruce
Re: [dpdk-dev] [PATCH 2/9] net/hns3: get link state change through mailbox
On 12/2/2019 2:51 AM, Wei Hu (Xavier) wrote:
> From: Hongbo Zheng
>
> When link down occurs, firmware adds the function of sending message
> to PF driver through mailbox, hns3 PMD driver can recognize link state
> change faster through the message.
Hi Xavier,
As far as I can see the 'link_update' dev_ops (hns3_dev_link_update()), is just
copying data from internal structure to "struct rte_eth_link". And you have
timers set to regularly (ever second?) update the internal structure for link
status.
Instead, unless you are not using or need those status internally, you can pull
the internal link status in the 'hns3_dev_link_update()', this way it can be
possible to get rid of the timers. Also in current implementation, when used
asked for the link status, it can be outdated regarding the status of the
timers.
In this patch, interrupt seems used to update the internal link status, this
fixes the problem above that user is getting out of date link status. But
instead of this, what do you think updating "struct rte_eth_link" too in the
interrupt handler and advertising 'RTE_ETH_DEV_INTR_LSC' capability ("Link
status event" feature in .ini file), so user can enable the lsc interrupt
('dev_conf.intr_conf.lsc') and gets the link status quicker because of the
support in the API ('rte_eth_link_get')?
Thanks,
ferruh
>
> Signed-off-by: Hongbo Zheng
> Signed-off-by: Wei Hu (Xavier)
> ---
> drivers/net/hns3/hns3_ethdev.c | 8 ++--
> drivers/net/hns3/hns3_ethdev.h | 1 +
> drivers/net/hns3/hns3_mbx.c| 37 ++
> drivers/net/hns3/hns3_mbx.h| 8
> 4 files changed, 52 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/hns3/hns3_ethdev.c b/drivers/net/hns3/hns3_ethdev.c
> index bf0ab458f..3c591be51 100644
> --- a/drivers/net/hns3/hns3_ethdev.c
> +++ b/drivers/net/hns3/hns3_ethdev.c
> @@ -218,6 +218,8 @@ hns3_interrupt_handler(void *param)
> hns3_schedule_reset(hns);
> } else if (event_cause == HNS3_VECTOR0_EVENT_RST)
> hns3_schedule_reset(hns);
> + else if (event_cause == HNS3_VECTOR0_EVENT_MBX)
> + hns3_dev_handle_mbx_msg(hw);
> else
> hns3_err(hw, "Received unknown event");
>
> @@ -3806,14 +3808,16 @@ hns3_get_mac_link_status(struct hns3_hw *hw)
> return !!link_status;
> }
>
> -static void
> +void
> hns3_update_link_status(struct hns3_hw *hw)
> {
> int state;
>
> state = hns3_get_mac_link_status(hw);
> - if (state != hw->mac.link_status)
> + if (state != hw->mac.link_status) {
> hw->mac.link_status = state;
> + hns3_warn(hw, "Link status change to %s!", state ? "up" :
> "down");
> + }
> }
>
> static void
> diff --git a/drivers/net/hns3/hns3_ethdev.h b/drivers/net/hns3/hns3_ethdev.h
> index e9a3fe410..004cd75a9 100644
> --- a/drivers/net/hns3/hns3_ethdev.h
> +++ b/drivers/net/hns3/hns3_ethdev.h
> @@ -631,6 +631,7 @@ int hns3_dev_filter_ctrl(struct rte_eth_dev *dev,
>enum rte_filter_op filter_op, void *arg);
> bool hns3_is_reset_pending(struct hns3_adapter *hns);
> bool hns3vf_is_reset_pending(struct hns3_adapter *hns);
> +void hns3_update_link_status(struct hns3_hw *hw);
>
> static inline bool
> is_reset_pending(struct hns3_adapter *hns)
> diff --git a/drivers/net/hns3/hns3_mbx.c b/drivers/net/hns3/hns3_mbx.c
> index c1647af4b..26807bc4b 100644
> --- a/drivers/net/hns3/hns3_mbx.c
> +++ b/drivers/net/hns3/hns3_mbx.c
> @@ -282,6 +282,40 @@ hns3_update_resp_position(struct hns3_hw *hw, uint32_t
> resp_msg)
> resp->tail = tail;
> }
>
> +static void
> +hns3_link_fail_parse(struct hns3_hw *hw, uint8_t link_fail_code)
> +{
> + switch (link_fail_code) {
> + case HNS3_MBX_LF_NORMAL:
> + break;
> + case HNS3_MBX_LF_REF_CLOCK_LOST:
> + hns3_warn(hw, "Reference clock lost!");
> + break;
> + case HNS3_MBX_LF_XSFP_TX_DISABLE:
> + hns3_warn(hw, "SFP tx is disabled!");
> + break;
> + case HNS3_MBX_LF_XSFP_ABSENT:
> + hns3_warn(hw, "SFP is absent!");
> + break;
> + default:
> + hns3_warn(hw, "Unknown fail code:%u!", link_fail_code);
> + break;
> + }
> +}
> +
> +static void
> +hns3_handle_link_change_event(struct hns3_hw *hw,
> + struct hns3_mbx_pf_to_vf_cmd *req)
> +{
> +#define LINK_STATUS_OFFSET 1
> +#define LINK_FAIL_CODE_OFFSET 2
> +
> + if (!req->msg[LINK_STATUS_OFFSET])
> + hns3_link_fail_parse(hw, req->msg[LINK_FAIL_CODE_OFFSET]);
> +
> + hns3_update_link_status(hw);
> +}
> +
> void
> hns3_dev_handle_mbx_msg(struct hns3_hw *hw)
> {
> @@ -335,6 +369,9 @@ hns3_dev_handle_mbx_msg(struct hns3_hw *hw)
>
> hns3_mbx_handler(hw);
> break;
> + case HNS3_MBX_PUSH_LINK_STATUS:
> + hns3_handle_link_change_event(hw, req);
> +
Re: [dpdk-dev] [PATCH 2/9] net/hns3: get link state change through mailbox
On 12/3/2019 1:16 PM, Ferruh Yigit wrote:
> On 12/2/2019 2:51 AM, Wei Hu (Xavier) wrote:
>> From: Hongbo Zheng
>>
>> When link down occurs, firmware adds the function of sending message
>> to PF driver through mailbox, hns3 PMD driver can recognize link state
>> change faster through the message.
>
> Hi Xavier,
>
> As far as I can see the 'link_update' dev_ops (hns3_dev_link_update()), is
> just
> copying data from internal structure to "struct rte_eth_link". And you have
> timers set to regularly (ever second?) update the internal structure for link
> status.
>
> Instead, unless you are not using or need those status internally, you can
> pull
> the internal link status in the 'hns3_dev_link_update()', this way it can be
> possible to get rid of the timers. Also in current implementation, when used
> asked for the link status, it can be outdated regarding the status of the
> timers.
>
>
> In this patch, interrupt seems used to update the internal link status, this
> fixes the problem above that user is getting out of date link status. But
> instead of this, what do you think updating "struct rte_eth_link" too in the
> interrupt handler and advertising 'RTE_ETH_DEV_INTR_LSC' capability ("Link
> status event" feature in .ini file), so user can enable the lsc interrupt
> ('dev_conf.intr_conf.lsc') and gets the link status quicker because of the
> support in the API ('rte_eth_link_get')?
>
> Thanks,
> ferruh
'Wei Hu (Xavier) ' email address is failing, not sure what
it is, adding the @huawei.com addresses.
>
>
>>
>> Signed-off-by: Hongbo Zheng
>> Signed-off-by: Wei Hu (Xavier)
>> ---
>> drivers/net/hns3/hns3_ethdev.c | 8 ++--
>> drivers/net/hns3/hns3_ethdev.h | 1 +
>> drivers/net/hns3/hns3_mbx.c| 37 ++
>> drivers/net/hns3/hns3_mbx.h| 8
>> 4 files changed, 52 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/hns3/hns3_ethdev.c b/drivers/net/hns3/hns3_ethdev.c
>> index bf0ab458f..3c591be51 100644
>> --- a/drivers/net/hns3/hns3_ethdev.c
>> +++ b/drivers/net/hns3/hns3_ethdev.c
>> @@ -218,6 +218,8 @@ hns3_interrupt_handler(void *param)
>> hns3_schedule_reset(hns);
>> } else if (event_cause == HNS3_VECTOR0_EVENT_RST)
>> hns3_schedule_reset(hns);
>> +else if (event_cause == HNS3_VECTOR0_EVENT_MBX)
>> +hns3_dev_handle_mbx_msg(hw);
>> else
>> hns3_err(hw, "Received unknown event");
>>
>> @@ -3806,14 +3808,16 @@ hns3_get_mac_link_status(struct hns3_hw *hw)
>> return !!link_status;
>> }
>>
>> -static void
>> +void
>> hns3_update_link_status(struct hns3_hw *hw)
>> {
>> int state;
>>
>> state = hns3_get_mac_link_status(hw);
>> -if (state != hw->mac.link_status)
>> +if (state != hw->mac.link_status) {
>> hw->mac.link_status = state;
>> +hns3_warn(hw, "Link status change to %s!", state ? "up" :
>> "down");
>> +}
>> }
>>
>> static void
>> diff --git a/drivers/net/hns3/hns3_ethdev.h b/drivers/net/hns3/hns3_ethdev.h
>> index e9a3fe410..004cd75a9 100644
>> --- a/drivers/net/hns3/hns3_ethdev.h
>> +++ b/drivers/net/hns3/hns3_ethdev.h
>> @@ -631,6 +631,7 @@ int hns3_dev_filter_ctrl(struct rte_eth_dev *dev,
>> enum rte_filter_op filter_op, void *arg);
>> bool hns3_is_reset_pending(struct hns3_adapter *hns);
>> bool hns3vf_is_reset_pending(struct hns3_adapter *hns);
>> +void hns3_update_link_status(struct hns3_hw *hw);
>>
>> static inline bool
>> is_reset_pending(struct hns3_adapter *hns)
>> diff --git a/drivers/net/hns3/hns3_mbx.c b/drivers/net/hns3/hns3_mbx.c
>> index c1647af4b..26807bc4b 100644
>> --- a/drivers/net/hns3/hns3_mbx.c
>> +++ b/drivers/net/hns3/hns3_mbx.c
>> @@ -282,6 +282,40 @@ hns3_update_resp_position(struct hns3_hw *hw, uint32_t
>> resp_msg)
>> resp->tail = tail;
>> }
>>
>> +static void
>> +hns3_link_fail_parse(struct hns3_hw *hw, uint8_t link_fail_code)
>> +{
>> +switch (link_fail_code) {
>> +case HNS3_MBX_LF_NORMAL:
>> +break;
>> +case HNS3_MBX_LF_REF_CLOCK_LOST:
>> +hns3_warn(hw, "Reference clock lost!");
>> +break;
>> +case HNS3_MBX_LF_XSFP_TX_DISABLE:
>> +hns3_warn(hw, "SFP tx is disabled!");
>> +break;
>> +case HNS3_MBX_LF_XSFP_ABSENT:
>> +hns3_warn(hw, "SFP is absent!");
>> +break;
>> +default:
>> +hns3_warn(hw, "Unknown fail code:%u!", link_fail_code);
>> +break;
>> +}
>> +}
>> +
>> +static void
>> +hns3_handle_link_change_event(struct hns3_hw *hw,
>> + struct hns3_mbx_pf_to_vf_cmd *req)
>> +{
>> +#define LINK_STATUS_OFFSET 1
>> +#define LINK_FAIL_CODE_OFFSET 2
>> +
>> +if (!req->msg[LINK_STATUS_OFFSET])
>> +hns3_link_fail_parse(hw, req->msg[LINK_FAIL_CODE_OFFSET]);
>> +
>> +hns3_update_link_status(hw);
>> +}
>> +
>> void
>> hns3_dev_handle_mbx_msg(struct hns3_hw *hw)
>>
Re: [dpdk-dev] [PATCH v2] kernel/linux: fix kernel dir for meson
On Tue, Dec 03, 2019 at 08:33:22PM +0800, Ye Xiaolong wrote:
> On 12/03, Bruce Richardson wrote:
> >On Tue, Dec 03, 2019 at 01:29:17PM +0800, Xiaolong Ye wrote:
> >> kernel_dir option in meson build is equivalent to RTE_KERNELDIR in make
> >> system, for cross-compilation case, users would specify it as local
> >> kernel src dir like
> >>
> >> //target-arm_glibc/linux-arm/linux-4.19.81/
> >>
> >> Current meson build would fail to compile kernel module if user specify
> >> kernel_dir as above, this patch fixes this issue.
> >>
> >> Fixes: 317832f97c16 ("kernel/linux: fix modules install path")
> >> Cc: sta...@dpdk.org
> >> Cc: iryz...@nfware.com
> >>
> >> Signed-off-by: Xiaolong Ye
> >> ---
> >>
> >> V2 changes:
> >>
> >> 1. handle both normal and cross-compilation cases
> >>
> >We need to handle both, but they need to be handled without breaking the
> >currently working case where we pass in /lib/modules/$(uname -r)/ as the
> >kerneldir path.
>
> So you mean we should allow user to specify both /lib/modules/$(uname -r) and
> /lib/modules/$(uname -r)/build as kernel_dir for normal case?
>
That is up to you, but we need to still allow the former case so as to
avoid breaking backward compatibility for existing build setups. Therefore
I suggest supporting both is recommended.
/Bruce
Re: [dpdk-dev] [PATCH v2] kernel/linux: fix kernel dir for meson
On 12/03, Bruce Richardson wrote:
>On Tue, Dec 03, 2019 at 08:33:22PM +0800, Ye Xiaolong wrote:
>> On 12/03, Bruce Richardson wrote:
>> >On Tue, Dec 03, 2019 at 01:29:17PM +0800, Xiaolong Ye wrote:
>> >> kernel_dir option in meson build is equivalent to RTE_KERNELDIR in make
>> >> system, for cross-compilation case, users would specify it as local
>> >> kernel src dir like
>> >>
>> >> //target-arm_glibc/linux-arm/linux-4.19.81/
>> >>
>> >> Current meson build would fail to compile kernel module if user specify
>> >> kernel_dir as above, this patch fixes this issue.
>> >>
>> >> Fixes: 317832f97c16 ("kernel/linux: fix modules install path")
>> >> Cc: sta...@dpdk.org
>> >> Cc: iryz...@nfware.com
>> >>
>> >> Signed-off-by: Xiaolong Ye
>> >> ---
>> >>
>> >> V2 changes:
>> >>
>> >> 1. handle both normal and cross-compilation cases
>> >>
>> >We need to handle both, but they need to be handled without breaking the
>> >currently working case where we pass in /lib/modules/$(uname -r)/ as the
>> >kerneldir path.
>>
>> So you mean we should allow user to specify both /lib/modules/$(uname -r) and
>> /lib/modules/$(uname -r)/build as kernel_dir for normal case?
>>
>That is up to you, but we need to still allow the former case so as to
>avoid breaking backward compatibility for existing build setups. Therefore
>I suggest supporting both is recommended.
Make sense, I'll try a new version.
Thanks,
Xiaolong
>
>/Bruce
Re: [dpdk-dev] [PATCH] service: don't walk out of bounds when checking services
David Marchand writes:
> On Tue, Nov 26, 2019 at 3:56 PM Aaron Conole wrote:
>>
>> The service_valid call is used without properly bounds checking the
>> input parameter. Almost all instances of the service_valid call are
>> inside a for() loop that prevents excessive walks, but some of the
>> public APIs don't bounds check and will pass invalid arguments.
>>
>> Prevent this by using SERVICE_GET_OR_ERR_RET where it makes sense,
>> and adding a bounds check to one service_valid() use.
>>
>> Fixes: 8d39d3e237c2 ("service: fix race in service on app lcore function")
>> Fixes: e9139a32f6e8 ("service: add function to run on app lcore")
>> Fixes: e30dd31847d2 ("service: add mechanism for quiescing")
>> Signed-off-by: Aaron Conole
>> ---
>> lib/librte_eal/common/rte_service.c | 23 +++
>> 1 file changed, 11 insertions(+), 12 deletions(-)
>>
>> diff --git a/lib/librte_eal/common/rte_service.c
>> b/lib/librte_eal/common/rte_service.c
>> index 79235c03f8..73de7bbade 100644
>> --- a/lib/librte_eal/common/rte_service.c
>> +++ b/lib/librte_eal/common/rte_service.c
>> @@ -345,11 +345,12 @@ rte_service_runner_do_callback(struct
>> rte_service_spec_impl *s,
>>
>>
>> static inline int32_t
>> -service_run(uint32_t i, struct core_state *cs, uint64_t service_mask)
>> +service_run(uint32_t i, struct core_state *cs, uint64_t service_mask,
>> + struct rte_service_spec_impl *s)
>> {
>> - if (!service_valid(i))
>> - return -EINVAL;
>> - struct rte_service_spec_impl *s = &rte_services[i];
>> + if (!s)
>> + SERVICE_VALID_GET_OR_ERR_RET(i, s, -EINVAL);
>> +
>
> No need to check the service if we ensure that the passed index is valid.
> See below.
Okay. I will document that then ;)
>
>> if (s->comp_runstate != RUNSTATE_RUNNING ||
>> s->app_runstate != RUNSTATE_RUNNING ||
>> !(service_mask & (UINT64_C(1) << i))) {
>> @@ -383,7 +384,7 @@ rte_service_may_be_active(uint32_t id)
>> int32_t lcore_count = rte_service_lcore_list(ids, RTE_MAX_LCORE);
>> int i;
>>
>> - if (!service_valid(id))
>> + if (id >= RTE_SERVICE_NUM_MAX || !service_valid(id))
>> return -EINVAL;
>>
>> for (i = 0; i < lcore_count; i++) {
>> @@ -397,12 +398,10 @@ rte_service_may_be_active(uint32_t id)
>> int32_t
>> rte_service_run_iter_on_app_lcore(uint32_t id, uint32_t serialize_mt_unsafe)
>> {
>> - /* run service on calling core, using all-ones as the service mask */
>> - if (!service_valid(id))
>> - return -EINVAL;
>> -
>> struct core_state *cs = &lcore_states[rte_lcore_id()];
>> - struct rte_service_spec_impl *s = &rte_services[id];
>> + struct rte_service_spec_impl *s;
>> +
>> + SERVICE_VALID_GET_OR_ERR_RET(id, s, -EINVAL);
>>
>> /* Atomically add this core to the mapped cores first, then examine
>> if
>> * we can run the service. This avoids a race condition between
>> @@ -418,7 +417,7 @@ rte_service_run_iter_on_app_lcore(uint32_t id, uint32_t
>> serialize_mt_unsafe)
>> return -EBUSY;
>> }
>>
>> - int ret = service_run(id, cs, UINT64_MAX);
>> + int ret = service_run(id, cs, UINT64_MAX, s);
>>
>> if (serialize_mt_unsafe)
>> rte_atomic32_dec(&s->num_mapped_cores);
>> @@ -439,7 +438,7 @@ rte_service_runner_func(void *arg)
>>
>> for (i = 0; i < RTE_SERVICE_NUM_MAX; i++) {
>> /* return value ignored as no change to code flow */
>
> if (!service_valid(idx))
> continue;
>
> Plus, if we add this check here, thenall loops in this file are consistent.
> WDYT?
Agreed - it's better. Okay.
Re: [dpdk-dev] [PATCH] mark experimental variables
On Mon, Dec 02, 2019 at 04:20:29PM +0100, David Marchand wrote:
> So far, we did not pay attention to direct access to variables but they
> are part of the API/ABI too and should be clearly identified.
>
> Introduce a __rte_experimental_var tag and mark existing exported
> variables.
>
> Fixes: a4bcd61de82d ("buildtools: add script to check experimental API
> exports")
> Cc: sta...@dpdk.org
>
> Signed-off-by: David Marchand
> ---
> Changelog since RFC:
> - s/resp\./or/ in documentation,
> - caught more variables by looking at the *COM* section,
>
> ---
> buildtools/check-experimental-syms.sh | 17 +++--
> devtools/checkpatches.sh | 16
> doc/guides/contributing/abi_policy.rst | 7 ---
> drivers/net/ice/rte_pmd_ice.h | 8
> lib/librte_bbdev/rte_bbdev.h | 1 +
> lib/librte_cryptodev/rte_crypto_asym.h | 3 +++
> lib/librte_eal/common/include/rte_compat.h | 5 +
> lib/librte_ethdev/rte_flow.h | 17 +
> lib/librte_port/rte_port_eventdev.h| 5 +
> lib/librte_rcu/rte_rcu_qsbr.h | 1 +
> 10 files changed, 71 insertions(+), 9 deletions(-)
>
> diff --git a/buildtools/check-experimental-syms.sh
> b/buildtools/check-experimental-syms.sh
> index f3603e5ba..f3a2f92fb 100755
> --- a/buildtools/check-experimental-syms.sh
> +++ b/buildtools/check-experimental-syms.sh
> @@ -34,13 +34,26 @@ do
> Please add __rte_experimental to the definition of $SYM
> END_OF_MESSAGE
> ret=1
> + elif grep -qe "\(\.data\|\*COM\*\).*[[:space:]]$SYM$" $DUMPFILE &&
> + ! grep -q "\.data\.experimental.*[[:space:]]$SYM$" $DUMPFILE
> + then
> + cat >&2 <<- END_OF_MESSAGE
> + $SYM is not flagged as experimental
> + but is listed in version map
> + Please add __rte_experimental_var to the definition of $SYM
> + END_OF_MESSAGE
> + ret=1
> fi
> done
>
> # Filter out symbols suffixed with a . for icc
> for SYM in `awk '{
> - if ($2 != "l" && $4 == ".text.experimental" && !($NF ~ /\.$/)) {
> - print $NF
> + if ($2 == "l" || $NF ~ /\.$/) {
> + next;
> + }
> + if ($4 == ".text.experimental" ||
> + $4 == ".data.experimental") {
> + print $NF;
> }
> }' $DUMPFILE`
> do
> diff --git a/devtools/checkpatches.sh b/devtools/checkpatches.sh
> index b16bace92..92b0ae40a 100755
> --- a/devtools/checkpatches.sh
> +++ b/devtools/checkpatches.sh
> @@ -90,11 +90,19 @@ check_experimental_tags() { #
> "headers ("current_file")";
> ret = 1;
> }
> - if ($1 != "+__rte_experimental" || $2 != "") {
> +
> + if (NF == 1 && ($1 == "+__rte_experimental" ||
> + $1 == "+__rte_experimental_var")) {
> + next;
> + }
> + if ($0 ~ "__rte_experimental_var") {
> + print "__rte_experimental_var must appear alone on the
> line" \
> + " immediately preceding the type of a
> variable.";
> + } else {
> print "__rte_experimental must appear alone on the
> line" \
> - " immediately preceding the return type of a
> function."
> - ret = 1;
> + " immediately preceding the return type of a
> function.";
> }
> + ret = 1;
> }
> END {
> exit ret;
> @@ -178,7 +186,7 @@ check () { #
> ret=1
> fi
>
> - ! $verbose || printf '\nChecking __rte_experimental tags:\n'
> + ! $verbose || printf '\nChecking __rte_experimental* tags:\n'
> report=$(check_experimental_tags "$tmpinput")
> if [ $? -ne 0 ] ; then
> $headline_printed || print_headline "$3"
> diff --git a/doc/guides/contributing/abi_policy.rst
> b/doc/guides/contributing/abi_policy.rst
> index 05ca95980..f933234d6 100644
> --- a/doc/guides/contributing/abi_policy.rst
> +++ b/doc/guides/contributing/abi_policy.rst
> @@ -300,9 +300,10 @@ Note that marking an API as experimental is a multi step
> process.
> To mark an API as experimental, the symbols which are desired to be exported
> must be placed in an EXPERIMENTAL version block in the corresponding
> libraries'
> version map script.
> -Secondly, the corresponding prototypes of those exported functions (in the
> -development header files), must be marked with the ``__rte_experimental`` tag
> -(see ``rte_compat.h``).
> +Secondly, the corresponding prototypes of those exported functions (or
> +variables) must be marked with the ``__rte_experimental`` (or
> +``__rte_experimental_var``) tag in the development header files (see
> +``rte_compat.h``).
> The DPDK build makefiles perform a check to e
Re: [dpdk-dev] [PATCH v3 0/7] Add ABI compatibility checks to the meson build
On 03/12/2019 11:03, David Marchand wrote:
On Fri, Nov 29, 2019 at 10:09 PM Kevin Laatz wrote:
With the recent changes made to stabilize ABI versioning in DPDK, it will
become increasingly important to check patches for ABI compatibility. We
propose adding the ABI compatibility checking to be done as part of the
build.
The advantages to adding the ABI compatibility checking to the build are
two-fold. Firstly, developers can easily check their patches to make sure
they don’t break the ABI without adding any extra steps. Secondly, it
makes the integration into existing CI seamless since there are no extra
scripts to make the CI run. The build will run as usual and if an
incompatibility is detected in the ABI, the build will fail and show the
incompatibility. As an added bonus, enabling the ABI compatibility checks
does not impact the build speed.
The proposed solution works as follows:
1. Generate the ABI dump of the baseline. This can be done with the new
script added in this RFC. This step will only need to be done when the
ABI version changes (so once a year) and can be added to master so it
exists by default. This step can be skipped if the dump files for the
baseline already exist.
2. Build with meson. If there is an ABI incompatibility, the build will
fail and print the incompatibility information.
The patches accompanying this RFC add the ABI dump file generating script,
the meson option required to enable/disable the checks, and the required
meson changes to run the compatibility checks during the build.
Global comments:
- why are patch 1 and 2 in this series, is this really needed?
Not if we make this an 'auto' option. It would have needed debug info to
do the ABI check.
- please squash patches 3, 4, 5 and 6, reading them separately is a
pain and they are quite small,
Will do
- if Windows does not support the ABI check, enforce this earlier in
meson and refuse enabling it rather than silently ignoring it,
Makes sense, will look into this.
- I would not enable this check by default
- this is a developer option, people just building the dpdk don't
care about it,
- can we have something like a tristate "auto" (default, triggers
the check if abidiff is installed), "disabled" and "enabled" (not
having abidiff installed triggers an error) ?
Seems reasonable, will change.
- please update the travis packages so that we can run those checks
for developers submitting patches
Will do.
- I don't think you tested this series with
devtools/test-meson-builds.sh, please do. It fails with a custom build
directory and in the dpdk tree too:
Build targets in project: 1019
WARNING: Project specifies a minimum meson_version '>= 0.47.1' but
uses features which were added in newer versions:
* 0.48.0: {'console arg in custom_target'}
* 0.50.0: {'install arg in configure_file'}
Found ninja-1.9.0 at /usr/bin/ninja
ninja -C /home/dmarchan/builds/build-gcc-static
ninja: Entering directory `/home/dmarchan/builds/build-gcc-static'
[48/2291] Generating librte_kvargs.abi_chk with a meson_exe.py custom command.
FAILED: lib/librte_kvargs.abi_chk
/usr/bin/meson --internal exe
/home/dmarchan/builds/build-gcc-static/meson-private/meson_exe_abidiff_6511538ddd95d9672028017110fa45c67f01f7be.dat
file /home/dmarchan/dpdk/lib/abi/librte_kvargs.dump does not exist
[77/2291] Compiling C object
'lib/76b5a35@@rte_mbuf@sta/librte_mbuf_rte_mbuf.c.o'.
ninja: build stopped: subcommand failed.
This is failing as the .dump files have not been created yet. They can
be generated with devtools/gen-abi-dump.sh . This will
generate a .dump file for each shared object in the builddir drivers and
lib folders.
/Kevin
Re: [dpdk-dev] [PATCH v4 1/7] bus/fslmc: change to dynamic logging
On 4/2/2018 3:05 PM, Shreyansh Jain wrote:
> Signed-off-by: Shreyansh Jain
> Acked-by: Hemant Agrawal
<...>
> diff --git a/drivers/bus/fslmc/fslmc_bus.c b/drivers/bus/fslmc/fslmc_bus.c
> index 5ee0beb85..4d29b53b1 100644
> --- a/drivers/bus/fslmc/fslmc_bus.c
> +++ b/drivers/bus/fslmc/fslmc_bus.c
> @@ -18,9 +18,9 @@
>
> #include
> #include
> +#include "fslmc_logs.h"
>
> -#define FSLMC_BUS_LOG(level, fmt, args...) \
> - RTE_LOG(level, EAL, fmt "\n", ##args)
> +int dpaa2_logtype_bus;
>
> #define VFIO_IOMMU_GROUP_PATH "/sys/kernel/iommu_groups"
>
> @@ -93,6 +93,25 @@ insert_in_device_list(struct rte_dpaa2_device *newdev)
> TAILQ_INSERT_TAIL(&rte_fslmc_bus.device_list, newdev, next);
> }
>
> +static void
> +dump_device_list(void)
> +{
> + struct rte_dpaa2_device *dev;
> + uint32_t global_log_level;
> + int local_log_level;
> +
> + /* Only if the log level has been set to Debugging, print list */
> + global_log_level = rte_log_get_global_level();
> + local_log_level = rte_log_get_level(dpaa2_logtype_bus);
> + if (global_log_level == RTE_LOG_DEBUG ||
> + global_log_level == RTE_LOG_DEBUG) {
> + DPAA2_BUS_DEBUG("List of devices scanned on bus:");
> + TAILQ_FOREACH(dev, &rte_fslmc_bus.device_list, next) {
> + DPAA2_BUS_DEBUG("%s", dev->device.name);
> + }
> + }
> +}
Hi Hemant, Shreyansh,
This is old code but I saw it while checking something else, is
'global_log_level' & 'global_log_level' checks required?
Won't 'DPAA2_BUS_DEBUG' macro do it already?
Thanks,
ferruh
[dpdk-dev] [PATCH v3] kernel/linux: fix kernel dir for meson
kernel_dir option in meson build is equivalent to RTE_KERNELDIR in make
system, for cross-compilation case, users would specify it as local
kernel src dir like
//target-arm_glibc/linux-arm/linux-4.19.81/
Current meson build would fail to compile kernel module if user specify
kernel_dir as above, this patch fixes this issue.
After this change, for normal build case, user can specify
/lib/modules/ or /lib/modules//build as
kernel_dir. For cross compilation case, user can specify any directory
that contains kernel source code as the kernel_dir.
Fixes: 317832f97c16 ("kernel/linux: fix modules install path")
Cc: sta...@dpdk.org
Cc: iryz...@nfware.com
Signed-off-by: Xiaolong Ye
---
V3 changes:
1. support setting both /lib/modules/ and
/lib/modules//build as kernel_dir to keep backward
compatibility
V2 changes:
1. handle both normal and cross-compilation cases
kernel/linux/igb_uio/meson.build | 4 ++--
kernel/linux/kni/meson.build | 4 ++--
kernel/linux/meson.build | 19 +++
meson_options.txt| 2 +-
4 files changed, 20 insertions(+), 9 deletions(-)
diff --git a/kernel/linux/igb_uio/meson.build b/kernel/linux/igb_uio/meson.build
index fac404f07..63990372e 100644
--- a/kernel/linux/igb_uio/meson.build
+++ b/kernel/linux/igb_uio/meson.build
@@ -8,7 +8,7 @@ mkfile = custom_target('igb_uio_makefile',
custom_target('igb_uio',
input: ['igb_uio.c', 'Kbuild'],
output: 'igb_uio.ko',
- command: ['make', '-C', kernel_dir + '/build',
+ command: ['make', '-C', kernel_dir,
'M=' + meson.current_build_dir(),
'src=' + meson.current_source_dir(),
'EXTRA_CFLAGS=-I' + meson.current_source_dir() +
@@ -16,5 +16,5 @@ custom_target('igb_uio',
'modules'],
depends: mkfile,
install: true,
- install_dir: kernel_dir + '/extra/dpdk',
+ install_dir: install_base + '/extra/dpdk',
build_by_default: get_option('enable_kmods'))
diff --git a/kernel/linux/kni/meson.build b/kernel/linux/kni/meson.build
index 955eec949..04c817e8a 100644
--- a/kernel/linux/kni/meson.build
+++ b/kernel/linux/kni/meson.build
@@ -13,7 +13,7 @@ kni_sources = files(
custom_target('rte_kni',
input: kni_sources,
output: 'rte_kni.ko',
- command: ['make', '-j4', '-C', kernel_dir + '/build',
+ command: ['make', '-j4', '-C', kernel_dir,
'M=' + meson.current_build_dir(),
'src=' + meson.current_source_dir(),
'MODULE_CFLAGS=-include ' + meson.source_root() +
'/config/rte_config.h' +
@@ -25,5 +25,5 @@ custom_target('rte_kni',
depends: kni_mkfile,
console: true,
install: true,
- install_dir: kernel_dir + '/extra/dpdk',
+ install_dir: install_base + '/extra/dpdk',
build_by_default: get_option('enable_kmods'))
diff --git a/kernel/linux/meson.build b/kernel/linux/meson.build
index 1796cc686..0568ed7e1 100644
--- a/kernel/linux/meson.build
+++ b/kernel/linux/meson.build
@@ -13,15 +13,26 @@ kernel_dir = get_option('kernel_dir')
if kernel_dir == ''
# use default path for native builds
kernel_version = run_command('uname', '-r').stdout().strip()
- kernel_dir = '/lib/modules/' + kernel_version
+ kernel_dir = '/lib/modules/' + kernel_version + '/build'
endif
# test running make in kernel directory, using "make kernelversion"
-make_returncode = run_command('make', '-sC', kernel_dir + '/build',
+make_returncode = run_command('make', '-sC', kernel_dir,
'kernelversion').returncode()
if make_returncode != 0
- warning('Cannot compile kernel modules as requested - are kernel
headers installed?')
- subdir_done()
+ kernel_dir = kernel_dir + '/build'
+ make_returncode = run_command('make', '-sC', kernel_dir,
+ 'kernelversion').returncode()
+ if make_returncode != 0
+ warning('Cannot compile kernel modules as requested - are
kernel headers installed?')
+ subdir_done()
+ endif
+endif
+
+if kernel_dir.endswith('build') or kernel_dir.endswith('build/')
+ install_base = kernel_dir.split('build')[0]
+else
+ install_base = kernel_dir
endif
# DO ACTUAL MODULE BUILDING
diff --git a/meson_options.txt b/meson_options.txt
index bc369d06c..7eba3b720 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -17,7 +17,7 @@ option('ibverbs_link', type: 'combo', choices : ['shared',
'dlopen'], value: 'sh
option('include_subdir_arch', type: 'string', value: '',
description: 'subdirectory where to install arch-dependent headers')
option('kernel_dir', type: 'string', value: '',
- description: 'Path to the kernel for building kernel modules. Headers
must be in $kernel_dir/build. Modules will be installed in
$DEST_DIR/$kernel_dir/extra/dpdk.')
+ description: 'Path to the kernel for building kernel modules. Modules
will be installed in $DE
[dpdk-dev] [PATCH v2] service: don't walk out of bounds when checking services
The service_valid call is used without properly bounds checking the
input parameter. Almost all instances of the service_valid call are
inside a for() loop that prevents excessive walks, but some of the
public APIs don't bounds check and will pass invalid arguments.
Prevent this by using SERVICE_GET_OR_ERR_RET where it makes sense,
and adding a bounds check to one service_valid() use.
Fixes: 8d39d3e237c2 ("service: fix race in service on app lcore function")
Fixes: e9139a32f6e8 ("service: add function to run on app lcore")
Fixes: e30dd31847d2 ("service: add mechanism for quiescing")
Signed-off-by: Aaron Conole
---
v2:
- make for() loop consistent and service_run() always require a valid 's'
pointer
- introduce service_get() for a future patch to clean up the
bare references to 'rte_services[i]'
- remove some useless 'inline' specifiers on functions (they aren't
needed in .c files). a future patch can clean up the others.
lib/librte_eal/common/rte_service.c | 32 ++---
1 file changed, 20 insertions(+), 12 deletions(-)
diff --git a/lib/librte_eal/common/rte_service.c
b/lib/librte_eal/common/rte_service.c
index 79235c03f8..7e537b8cd2 100644
--- a/lib/librte_eal/common/rte_service.c
+++ b/lib/librte_eal/common/rte_service.c
@@ -137,6 +137,12 @@ service_valid(uint32_t id)
return !!(rte_services[id].internal_flags & SERVICE_F_REGISTERED);
}
+static struct rte_service_spec_impl *
+service_get(uint32_t id)
+{
+ return &rte_services[id];
+}
+
/* validate ID and retrieve service pointer, or return error value */
#define SERVICE_VALID_GET_OR_ERR_RET(id, service, retval) do { \
if (id >= RTE_SERVICE_NUM_MAX || !service_valid(id))\
@@ -344,12 +350,14 @@ rte_service_runner_do_callback(struct
rte_service_spec_impl *s,
}
-static inline int32_t
-service_run(uint32_t i, struct core_state *cs, uint64_t service_mask)
+/* Expects the service 's' is valid. */
+static int32_t
+service_run(uint32_t i, struct core_state *cs, uint64_t service_mask,
+ struct rte_service_spec_impl *s)
{
- if (!service_valid(i))
+ if (!s)
return -EINVAL;
- struct rte_service_spec_impl *s = &rte_services[i];
+
if (s->comp_runstate != RUNSTATE_RUNNING ||
s->app_runstate != RUNSTATE_RUNNING ||
!(service_mask & (UINT64_C(1) << i))) {
@@ -383,7 +391,7 @@ rte_service_may_be_active(uint32_t id)
int32_t lcore_count = rte_service_lcore_list(ids, RTE_MAX_LCORE);
int i;
- if (!service_valid(id))
+ if (id >= RTE_SERVICE_NUM_MAX || !service_valid(id))
return -EINVAL;
for (i = 0; i < lcore_count; i++) {
@@ -397,12 +405,10 @@ rte_service_may_be_active(uint32_t id)
int32_t
rte_service_run_iter_on_app_lcore(uint32_t id, uint32_t serialize_mt_unsafe)
{
- /* run service on calling core, using all-ones as the service mask */
- if (!service_valid(id))
- return -EINVAL;
-
struct core_state *cs = &lcore_states[rte_lcore_id()];
- struct rte_service_spec_impl *s = &rte_services[id];
+ struct rte_service_spec_impl *s;
+
+ SERVICE_VALID_GET_OR_ERR_RET(id, s, -EINVAL);
/* Atomically add this core to the mapped cores first, then examine if
* we can run the service. This avoids a race condition between
@@ -418,7 +424,7 @@ rte_service_run_iter_on_app_lcore(uint32_t id, uint32_t
serialize_mt_unsafe)
return -EBUSY;
}
- int ret = service_run(id, cs, UINT64_MAX);
+ int ret = service_run(id, cs, UINT64_MAX, s);
if (serialize_mt_unsafe)
rte_atomic32_dec(&s->num_mapped_cores);
@@ -438,8 +444,10 @@ rte_service_runner_func(void *arg)
const uint64_t service_mask = cs->service_mask;
for (i = 0; i < RTE_SERVICE_NUM_MAX; i++) {
+ if (!service_valid(i))
+ continue;
/* return value ignored as no change to code flow */
- service_run(i, cs, service_mask);
+ service_run(i, cs, service_mask, service_get(i));
}
cs->loops++;
--
2.21.0
Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow action on VLAN header
Hello Matan and Slava, Thanks for your quick response. How about the following? BR, Hideyuki Yamashita NTT TechnoCross > Hello Matan and Slava, > > Thanks for your quick response. > > 1. What you were saying is correct. > When I create flow with dst mac 10:22:33:44:55:66 instead of > 11:22:33:44:55:66, received packets are queued to specified queue. > > Thanks for your advice! > > Q1. What is the problem with broadcast/multicast address? > Q2. What is the bug number on Bugzilla of DPDK? > Q3. What is the default behavior of unmatched packets? > Discard packet or queue those to default queue(e.g. queue=0)? > > When I tested packet distribution with vlan id, unmatched packets > looked discarded.. > I would like to know what is the default handling. > > Thanks! > > Best Regards, > Hideyuki Yamashita > NTT TechnoCross > > > > Hi > > > > This bit on in dst mac address = "01:00:00:00:00:00" means the packets is > > L2 multicast packet. > > > > When you run Testpmd application the multicast configuration is forwarded > > to the device by default. > > > > So, you have 2 rules: > > The default which try to match on the above dst mac bit and to do RSS > > action for all the queues. > > Your rule which try to match on dst mac 11:22:33:44:55:66 (the multicast > > bit is on) and more and to send it to queue 1. > > > > So, your flow is sub flow of the default flow. > > > > Since the current behavior in our driver is to put all the multicast rules > > in the same priority - the behavior for the case is unpredictable: > > 1. you can get the packet twice for the 2 rules. > > 2. you can get the packet onl for the default RSS action. > > 3. you can get the packet only on queue 1 as in your rule. > > > > Unfortunately, here, you got option 1 I think (you get the packet twice in > > your application). > > > > This behavior in our driver to put the 2 rules in same behavior is in > > discussion by us - maybe it will be changed later. > > > > To workaround the issue: > > 1. do not configure the default rules (run with --flow-isolate-all in > > testpmd cmdline). > > 2. do not configure 2 different multicast rules (even with different > > priorities). > > > > Enjoy, let me know if you need more help > > > > Matan > > > > From: Hideyuki Yamashita > > > Hi Slava, > > > > > > > > > Thanks for your response. > > > > > > 1. Is the bug number is the follwoing? > > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs. > > > dpdk.org%2Fshow_bug.cgi%3Fid%3D96&data=02%7C01%7Cmatan%40 > > > mellanox.com%7Ce10ce5ee0f8f4350c6a508d76bee3a97%7Ca652971c7d2e4d > > > 9ba6a4d149256f461b%7C0%7C0%7C637096543244123210&sdata=V3V21 > > > gwJExHt7mkg0sAEwW%2FLTCIbJEkHznNtUCVkN%2BA%3D&reserved=0 > > > > > > 2.I've sent packets using scapy with the follwing script and I think it > > > is unicast > > > ICMP. > > > How did you thought the packets are broadcast/muticast? > > > Note that I am not familiar with log of testpmd. > > > > > > -- > > > from scapy.all import * > > > > > > vlan_vid = 100 > > > vlan_prio = 0 > > > vlan_id = 0 > > > vlan_flg = True > > > src_mac = "CC:CC:CC:CC:CC:CC" > > > dst_mac = "11:22:33:44:55:66" > > > dst_ip = "192.168.200.101" > > > iface = "p7p1" > > > pps = 5 > > > loop = 5 > > > > > > def icmp_send(): > > > ls(Dot1Q) > > > if vlan_flg: > > > pkt = Ether(dst=dst_mac, src=src_mac)/Dot1Q(vlan=vlan_vid, > > > prio=vlan_prio, id=vlan_id)/IP(dst=dst_ip)/ICMP() > > > else: > > > pkt = Ether(dst=dst_mac, src=src_mac)/IP(dst=dst_ip)/ICMP() > > > pkt.show() > > > sendpfast(pkt, iface=iface, pps=pps, loop=loop, file_cache=True) > > > > > > icmp_send() > > > - > > > > > > Thanks! > > > > > > BR, > > > Hideyuki Yamashita > > > NTT TechnoCross > > > > > > > Hi, Hideyuki > > > > > > > > The frame in your report is broadcast/multicast. Please, try unicast > > > > one. > > > > For broadcast we have the ticket, currently issue is under > > > > investigation. > > > > Anyway, thanks for reporting. > > > > > > > > With best regards, Slava > > > > > > > > > -Original Message- > > > > > From: Hideyuki Yamashita > > > > > Sent: Thursday, November 14, 2019 7:02 > > > > > To: dev@dpdk.org > > > > > Cc: Slava Ovsiienko > > > > > Subject: Re: [dpdk-dev] [PATCH 0/7] net/mlx5: support for flow > > > > > action on VLAN header > > > > > > > > > > Hello Slava, > > > > > > > > > > As I reported to you, creating flow was successful with Connect-X5. > > > > > However when I sent packets to the NIC from outer side of the host, > > > > > I have problem. > > > > > > > > > > > > > > > [Case 1] > > > > > Packet distribution on multi-queue based on dst MAC address. > > > > > > > > > > NIC config: > > > > > 04:00.0 Mellanox Connect-X5 > > > > > 0.5.00.0 Intel XXV710 > > > > > > > > > > t
[dpdk-dev] [PATCH v2] vhost: add config change slave msg support
This msg is used to notify qemu that should get the config of backend.
For example, vhost-user-blk uses this msg to notify guest os the
compacity of backend has changed.
Signed-off-by: Li Feng
---
v2:
* Fix a little log typo.
lib/librte_vhost/vhost_user.c | 31 +++
lib/librte_vhost/vhost_user.h | 2 ++
2 files changed, 33 insertions(+)
diff --git a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c
index 0cfb8b792..10f2e47d5 100644
--- a/lib/librte_vhost/vhost_user.c
+++ b/lib/librte_vhost/vhost_user.c
@@ -2840,6 +2840,37 @@ vhost_user_iotlb_miss(struct virtio_net *dev, uint64_t
iova, uint8_t perm)
return 0;
}
+static int
+vhost_user_slave_config_change(struct virtio_net *dev)
+{
+ int ret;
+ struct VhostUserMsg msg = {
+ .request.slave = VHOST_USER_SLAVE_CONFIG_CHANGE_MSG,
+ .flags = VHOST_USER_VERSION,
+ .size = 0,
+ };
+
+ ret = send_vhost_message(dev->slave_req_fd, &msg);
+ if (ret < 0) {
+ RTE_LOG(ERR, VHOST_CONFIG,
+ "Failed to send config change (%d)\n",
+ ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+int
+rte_vhost_user_slave_config_change(int vid)
+{
+ struct virtio_net *dev;
+ dev = get_device(vid);
+ if (!dev)
+ return -ENODEV;
+ return vhost_user_slave_config_change(dev);
+}
+
static int vhost_user_slave_set_vring_host_notifier(struct virtio_net *dev,
int index, int fd,
uint64_t offset,
diff --git a/lib/librte_vhost/vhost_user.h b/lib/librte_vhost/vhost_user.h
index 6563f7315..5c1bb2138 100644
--- a/lib/librte_vhost/vhost_user.h
+++ b/lib/librte_vhost/vhost_user.h
@@ -62,6 +62,7 @@ typedef enum VhostUserRequest {
typedef enum VhostUserSlaveRequest {
VHOST_USER_SLAVE_NONE = 0,
VHOST_USER_SLAVE_IOTLB_MSG = 1,
+ VHOST_USER_SLAVE_CONFIG_CHANGE_MSG = 2,
VHOST_USER_SLAVE_VRING_HOST_NOTIFIER_MSG = 3,
VHOST_USER_SLAVE_MAX
} VhostUserSlaveRequest;
@@ -158,6 +159,7 @@ typedef struct VhostUserMsg {
/* vhost_user.c */
int vhost_user_msg_handler(int vid, int fd);
int vhost_user_iotlb_miss(struct virtio_net *dev, uint64_t iova, uint8_t perm);
+int rte_vhost_user_slave_config_change(int vid);
/* socket.c */
int read_fd_message(int sockfd, char *buf, int buflen, int *fds, int max_fds,
--
2.11.0
--
The SmartX email address is only for business purpose. Any sent message
that is not related to the business is not authorized or permitted by
SmartX.
本邮箱为北京志凌海纳科技有限公司（SmartX）工作邮箱. 如本邮箱发出的邮件与工作无关,该邮件未得到本公司任何的明示或默示的授权.
[dpdk-dev] [PATCH v2] vhost: add config change slave msg support
This msg is used to notify qemu that should get the config of backend.
For example, vhost-user-blk uses this msg to notify guest os the
compacity of backend has changed.
Signed-off-by: Li Feng
---
v2:
* Fix a little log typo.
lib/librte_vhost/vhost_user.c | 31 +++
lib/librte_vhost/vhost_user.h | 2 ++
2 files changed, 33 insertions(+)
diff --git a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c
index 0cfb8b792..10f2e47d5 100644
--- a/lib/librte_vhost/vhost_user.c
+++ b/lib/librte_vhost/vhost_user.c
@@ -2840,6 +2840,37 @@ vhost_user_iotlb_miss(struct virtio_net *dev, uint64_t
iova, uint8_t perm)
return 0;
}
+static int
+vhost_user_slave_config_change(struct virtio_net *dev)
+{
+ int ret;
+ struct VhostUserMsg msg = {
+ .request.slave = VHOST_USER_SLAVE_CONFIG_CHANGE_MSG,
+ .flags = VHOST_USER_VERSION,
+ .size = 0,
+ };
+
+ ret = send_vhost_message(dev->slave_req_fd, &msg);
+ if (ret < 0) {
+ RTE_LOG(ERR, VHOST_CONFIG,
+ "Failed to send config change (%d)\n",
+ ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+int
+rte_vhost_user_slave_config_change(int vid)
+{
+ struct virtio_net *dev;
+ dev = get_device(vid);
+ if (!dev)
+ return -ENODEV;
+ return vhost_user_slave_config_change(dev);
+}
+
static int vhost_user_slave_set_vring_host_notifier(struct virtio_net *dev,
int index, int fd,
uint64_t offset,
diff --git a/lib/librte_vhost/vhost_user.h b/lib/librte_vhost/vhost_user.h
index 6563f7315..5c1bb2138 100644
--- a/lib/librte_vhost/vhost_user.h
+++ b/lib/librte_vhost/vhost_user.h
@@ -62,6 +62,7 @@ typedef enum VhostUserRequest {
typedef enum VhostUserSlaveRequest {
VHOST_USER_SLAVE_NONE = 0,
VHOST_USER_SLAVE_IOTLB_MSG = 1,
+ VHOST_USER_SLAVE_CONFIG_CHANGE_MSG = 2,
VHOST_USER_SLAVE_VRING_HOST_NOTIFIER_MSG = 3,
VHOST_USER_SLAVE_MAX
} VhostUserSlaveRequest;
@@ -158,6 +159,7 @@ typedef struct VhostUserMsg {
/* vhost_user.c */
int vhost_user_msg_handler(int vid, int fd);
int vhost_user_iotlb_miss(struct virtio_net *dev, uint64_t iova, uint8_t perm);
+int rte_vhost_user_slave_config_change(int vid);
/* socket.c */
int read_fd_message(int sockfd, char *buf, int buflen, int *fds, int max_fds,
--
2.11.0
--
The SmartX email address is only for business purpose. Any sent message
that is not related to the business is not authorized or permitted by
SmartX.
本邮箱为北京志凌海纳科技有限公司（SmartX）工作邮箱. 如本邮箱发出的邮件与工作无关,该邮件未得到本公司任何的明示或默示的授权.
[dpdk-dev] [DPDK] net/virtio: packed ring notification data feature support
This patch supports the feature that the driver passes extra data
(besides identifying the virtqueue) in its device notifications.
Signed-off-by: Cheng Jiang
---
drivers/net/virtio/virtio_ethdev.h | 3 ++-
drivers/net/virtio/virtio_pci.c| 15 ++-
drivers/net/virtio/virtio_pci.h| 6 ++
3 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/net/virtio/virtio_ethdev.h
b/drivers/net/virtio/virtio_ethdev.h
index a10111758..cd8947656 100644
--- a/drivers/net/virtio/virtio_ethdev.h
+++ b/drivers/net/virtio/virtio_ethdev.h
@@ -36,7 +36,8 @@
1ULL << VIRTIO_F_IN_ORDER| \
1ULL << VIRTIO_F_RING_PACKED | \
1ULL << VIRTIO_F_IOMMU_PLATFORM | \
-1ULL << VIRTIO_F_ORDER_PLATFORM)
+1ULL << VIRTIO_F_ORDER_PLATFORM | \
+1ULL << VIRTIO_F_NOTIFICATION_DATA)
#define VIRTIO_PMD_SUPPORTED_GUEST_FEATURES\
(VIRTIO_PMD_DEFAULT_GUEST_FEATURES |\
diff --git a/drivers/net/virtio/virtio_pci.c b/drivers/net/virtio/virtio_pci.c
index 4468e89cb..2462a7dab 100644
--- a/drivers/net/virtio/virtio_pci.c
+++ b/drivers/net/virtio/virtio_pci.c
@@ -418,7 +418,20 @@ modern_del_queue(struct virtio_hw *hw, struct virtqueue
*vq)
static void
modern_notify_queue(struct virtio_hw *hw __rte_unused, struct virtqueue *vq)
{
- rte_write16(vq->vq_queue_index, vq->notify_addr);
+ uint32_t notify_data;
+
+ if (!vtpci_with_feature(hw, VIRTIO_F_NOTIFICATION_DATA)) {
+ rte_write16(vq->vq_queue_index, vq->notify_addr);
+ return;
+ }
+
+ if (vtpci_with_feature(hw, VIRTIO_F_RING_PACKED))
+ notify_data = uint32_t)vq->vq_packed.used_wrap_counter <<
15) |
+ vq->vq_avail_idx) << 16) | vq->vq_queue_index;
+ else
+ notify_data = ((uint32_t)vq->vq_avail_idx << 16) |
+ vq->vq_queue_index;
+ rte_write32(notify_data, vq->notify_addr);
}
const struct virtio_pci_ops modern_ops = {
diff --git a/drivers/net/virtio/virtio_pci.h b/drivers/net/virtio/virtio_pci.h
index a38cb45ad..7433d2f08 100644
--- a/drivers/net/virtio/virtio_pci.h
+++ b/drivers/net/virtio/virtio_pci.h
@@ -135,6 +135,12 @@ struct virtnet_ctl;
*/
#define VIRTIO_F_ORDER_PLATFORM 36
+/*
+ * This feature indicates that the driver passes extra data (besides
+ * identifying the virtqueue) in its device notifications.
+ */
+#define VIRTIO_F_NOTIFICATION_DATA 38
+
/* The Guest publishes the used index for which it expects an interrupt
* at the end of the avail ring. Host should ignore the avail->flags field. */
/* The Host publishes the avail index for which it expects a kick
--
2.17.1
