Re: [dpdk-dev] [PATCH 2/2] net/vhost: support mrg-rxbuf disabling
On 6/20/19 8:52 AM, Matan Azrad wrote: Hi all -Original Message- From: Noa Ezra Sent: Thursday, June 20, 2019 8:58 AM To: Maxime Coquelin Cc: Matan Azrad ; dev@dpdk.org Subject: RE: [PATCH 2/2] net/vhost: support mrg-rxbuf disabling Hi Maxime, Thanks for your comment, please see below. -Original Message- From: Maxime Coquelin [mailto:maxime.coque...@redhat.com] Sent: Wednesday, June 19, 2019 12:10 PM To: Noa Ezra Cc: Matan Azrad ; dev@dpdk.org Subject: Re: [PATCH 2/2] net/vhost: support mrg-rxbuf disabling Hi Noa, On 6/19/19 8:13 AM, Noa Ezra wrote: Rx mergeable buffers is a virtio feature that allows chaining of multiple virtio descriptors to handle large packet size. This behavior is supported and enabled by default, however in case the user knows that rx mergeable buffers are not needed, he can disable the feature. The user should also set mrg_rxbuf=off in virtual machine's xml. I'm not sure to understand why it is needed, as the vhost-user library supports the feature, it's better to let it being advertised. As you say, it is up to the user to disable it in the VM's XML. Done this way, the feature won't be negotiated. I agree with you, I'll remove this patch from the series. Are you sure that no performance impact exists for redundant merg-rx-buf configuration here? I'm not sure to understand what you mean, could you please elaborate? What if the second side want it and the current side no? The feature won't be negotiated, assuming it has been disabled in QEMU cmdline (or via libvirt). It may be that the vhost PMD user may want to disable it to save performance from some reasons, no? Then this user should disable it at QEMU level. Regards, Maxime
Re: [dpdk-dev] [PATCH 1/2] net/vhost: support TSO disabling
On 6/20/19 8:08 AM, Matan Azrad wrote: Hi Tiwei, Maxim From: Tiwei Bie Sent: Thursday, June 20, 2019 5:26 AM To: Maxime Coquelin Cc: Noa Ezra ; Matan Azrad ; dev@dpdk.org Subject: Re: [PATCH 1/2] net/vhost: support TSO disabling On Wed, Jun 19, 2019 at 11:53:05AM +0200, Maxime Coquelin wrote: On 6/19/19 8:13 AM, Noa Ezra wrote: TSO (TCP Segmentation Offload) is enabled by default on vhost. Add the ability to disable TSO on vhost. The user should also disable the feature on the virtual machine's xml. For TSO, I think it make sense to have the option to disable it, as it requires the application to support it. I even wonder whether it should not be disabled by default. Any thoughts? Agree, it looks better to disable it by default. The issue to disable it by default is that it will break the current applications/users which use TSO by default. Maybe we need kind of notice to the user to break it in the next version. What do you think? I think that's a good idea, let's add a notice in the release note for v19.08, and disable it by default in 19.11. Thanks, Maxime Thanks, Tiwei
Re: [dpdk-dev] [PATCH 18/39] eventdev: add framework for eventmode conf
Hi Jerin,
Please see inline.
Thanks,
Anoob
> -Original Message-
> From: Jerin Jacob Kollanukkaran
> Sent: Monday, June 10, 2019 3:36 PM
> To: Anoob Joseph ; Nikhil Rao ;
> Erik Gabriel Carrillo ; Abhinandan Gujjar
> ; Bruce Richardson
> ; Pablo de Lara
>
> Cc: Anoob Joseph ; Narayana Prasad Raju Athreya
> ; dev@dpdk.org; Lukas Bartosik
> ; Pavan Nikhilesh Bhagavatula
> ; Hemant Agrawal ;
> Nipun Gupta ; Harry van Haaren
> ; Mattias Rönnblom
> ; Liang Ma
> Subject: RE: [PATCH 18/39] eventdev: add framework for eventmode conf
>
> > -Original Message-
> > From: Anoob Joseph
> > Sent: Monday, June 3, 2019 11:02 PM
> > To: Jerin Jacob Kollanukkaran ; Nikhil Rao
> > ; Erik Gabriel Carrillo
> > ; Abhinandan Gujjar
> > ; Bruce Richardson
> > ; Pablo de Lara
> >
> > Cc: Anoob Joseph ; Narayana Prasad Raju Athreya
> > ; dev@dpdk.org; Lukas Bartosik
> > ; Pavan Nikhilesh Bhagavatula
> > ; Hemant Agrawal
> ;
> > Nipun Gupta ; Harry van Haaren
> > ; Mattias Rönnblom
> > ; Liang Ma
> > Subject: [PATCH 18/39] eventdev: add framework for eventmode conf
> >
> > Adding eventmode conf which would have all required configuration for
> > the event mode.
> >
> > Signed-off-by: Anoob Joseph
> > Signed-off-by: Lukasz Bartosik
> > ---
> > lib/librte_eventdev/rte_eventmode_helper.c | 16
> > lib/librte_eventdev/rte_eventmode_helper_internal.h | 5 +
> > 2 files changed, 21 insertions(+)
> >
> > diff --git a/lib/librte_eventdev/rte_eventmode_helper.c
> > b/lib/librte_eventdev/rte_eventmode_helper.c
> > index dc2c934..38f1a2b 100644
> > --- a/lib/librte_eventdev/rte_eventmode_helper.c
> > +++ b/lib/librte_eventdev/rte_eventmode_helper.c
> > @@ -97,6 +97,7 @@ rte_eventmode_helper_parse_args(int argc, char
> > **argv) {
> > int32_t opt, ret;
> > struct rte_eventmode_helper_conf *conf = NULL;
> > + struct eventmode_conf *em_conf = NULL;
> >
> > /* Allocate memory for conf */
> > conf = rte_zmalloc("eventmode-helper-conf",
> > @@ -108,9 +109,21 @@ rte_eventmode_helper_parse_args(int argc, char
> > **argv)
> > goto err;
> > }
> >
> > + /* Allocate memory for event mode params */
> > + conf->mode_params = rte_zmalloc("eventmode-helper-mode-
> > params",
>
> Use hugepage alloc memory only fastpath. Malloc() would be fine here.
>
[Anoob] Will fix this in v2.
Re: [dpdk-dev] [PATCH 2/2] net/vhost: support mrg-rxbuf disabling
On 6/20/19 7:57 AM, Noa Ezra wrote:
Hi Maxime,
Thanks for your comment, please see below.
-Original Message-
From: Maxime Coquelin [mailto:maxime.coque...@redhat.com]
Sent: Wednesday, June 19, 2019 12:10 PM
To: Noa Ezra
Cc: Matan Azrad ; dev@dpdk.org
Subject: Re: [PATCH 2/2] net/vhost: support mrg-rxbuf disabling
Hi Noa,
On 6/19/19 8:13 AM, Noa Ezra wrote:
Rx mergeable buffers is a virtio feature that allows chaining of
multiple virtio descriptors to handle large packet size.
This behavior is supported and enabled by default, however in case the
user knows that rx mergeable buffers are not needed, he can disable
the feature.
The user should also set mrg_rxbuf=off in virtual machine's xml.
I'm not sure to understand why it is needed, as the vhost-user library
supports the feature, it's better to let it being advertised.
As you say, it is up to the user to disable it in the VM's XML.
Done this way, the feature won't be negotiated.
I agree with you, I'll remove this patch from the series.
Moreover, the proposal deadline for v19.08 is over by more than 2 weeks.
I'm sorry, the mail was sent a long time but didn't get to the mailing list.
No problem, I just wanted to make you aware I could not take it anyway
in v19.08.
In any case, I'll prepare a new patch with only TSO (the first patch) and send
it to the next release.
As I replied to Matan, could you add the notice for the TSO disabled by
default in the release not for this release?
Thanks,
Maxime
Maxime
Signed-off-by: Noa Ezra
Reviewed-by: Matan Azrad
---
doc/guides/nics/vhost.rst | 5 +
drivers/net/vhost/rte_eth_vhost.c | 17 -
2 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/doc/guides/nics/vhost.rst b/doc/guides/nics/vhost.rst
index 8cfda4d..2a455b5 100644
--- a/doc/guides/nics/vhost.rst
+++ b/doc/guides/nics/vhost.rst
@@ -81,6 +81,11 @@ The user can specify below arguments in `--vdev`
option.
It is used to disable tso support in vhost library.
(Default: 1 (enabled))
+#. ``mrg-rxbuf``:
+
+It is used to disable mrg rxbuf support in vhost library.
+(Default: 1 (enabled))
+
Vhost PMD event handling
diff --git a/drivers/net/vhost/rte_eth_vhost.c
b/drivers/net/vhost/rte_eth_vhost.c
index a38c235..9a54020 100644
--- a/drivers/net/vhost/rte_eth_vhost.c
+++ b/drivers/net/vhost/rte_eth_vhost.c
@@ -32,6 +32,7 @@
#define ETH_VHOST_IOMMU_SUPPORT "iommu-support"
#define ETH_VHOST_POSTCOPY_SUPPORT "postcopy-support"
#define ETH_VHOST_VIRTIO_NET_F_HOST_TSO "tso"
+#define ETH_VHOST_VIRTIO_NET_F_MRG_RXBUF "mrg-rxbuf"
#define VHOST_MAX_PKT_BURST 32
static const char *valid_arguments[] = { @@ -42,6 +43,7 @@
ETH_VHOST_IOMMU_SUPPORT,
ETH_VHOST_POSTCOPY_SUPPORT,
ETH_VHOST_VIRTIO_NET_F_HOST_TSO,
+ ETH_VHOST_VIRTIO_NET_F_MRG_RXBUF,
NULL
};
@@ -1348,6 +1350,7 @@ struct vhost_xstats_name_off {
int iommu_support = 0;
int postcopy_support = 0;
int tso = 1;
+ int mrg_rxbuf = 1;
struct rte_eth_dev *eth_dev;
const char *name = rte_vdev_device_name(dev);
@@ -1442,6 +1445,17 @@ struct vhost_xstats_name_off {
}
}
+ if (rte_kvargs_count(kvlist,
ETH_VHOST_VIRTIO_NET_F_MRG_RXBUF) == 1) {
+ ret = rte_kvargs_process(kvlist,
+ ETH_VHOST_VIRTIO_NET_F_MRG_RXBUF,
+ &open_int, &mrg_rxbuf);
+ if (ret < 0)
+ goto out_free;
+
+ if (mrg_rxbuf == 0)
+ disable_flags |= (1ULL <<
VIRTIO_NET_F_MRG_RXBUF);
+ }
+
if (dev->device.numa_node == SOCKET_ID_ANY)
dev->device.numa_node = rte_socket_id();
@@ -1494,7 +1508,8 @@ struct vhost_xstats_name_off {
"dequeue-zero-copy=<0|1> "
"iommu-support=<0|1> "
"postcopy-support=<0|1> "
- "tso=<0|1>");
+ "tso=<0|1> "
+ "mrg-rxbuf=<0|1>");
RTE_INIT(vhost_init_log)
{
[dpdk-dev] [RFC] ethdev: reserve the RX offload most-significant bits for PMD scartch
Generally speaking, the DEV_RX_OFFLOAD_xxx for RX offload capabilities
of a device is one-bit field definition, it has 64 different values at
most.
Nowdays the receiving queue of NIC has rich features not just checksum
offload, like it can extract the network protocol header fields to its
RX descriptors for quickly handling. But this kind of feature is not so
common, and it is hardware related. Normally, this can be done through
rte_devargs driver parameters, but the scope is per device. This is not
so nice for per queue design.
The per queue API 'rte_eth_rx_queue_setup' and data structure 'struct
rte_eth_rxconf' are stable now, and be common for all PMDs. For keeping
the ethdev API & ABI compatibility, and the application can make good
use of the NIC's specific features, reserving the most-significant bits
of RX offload seems an compromise method.
Then the PMDs redefine these bits as they want, all PMDs share the same
bit positions and expose their new definitions with the header file.
The experimental reserved bits number is 6 currently. Tt can be one-bit
for each features up to the the maximum number 6. It can also be some
bits encoding: e.g, 6 bits can stand for 63 maximum number of features.
We call these reserved bits as DEV_RX_OFFLOAD_PMD_SCRATCH. And the left
unused bits number is : 64 - 19 (currently defined) - 6 (PMD scartch) =
39.
This is not so nice for applications, they need to check PMD's driver
name for lookuping their DEV_RX_OFFLOAD_PMD_SCRATCH definitions. But it
is good for the applications to make use of the hardware compatibility.
Signed-off-by: Haiyue Wang
---
app/test-pmd/cmdline.c | 18 --
lib/librte_ethdev/rte_ethdev.c | 6 ++
lib/librte_ethdev/rte_ethdev.h | 12
3 files changed, 30 insertions(+), 6 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index d1e0d44..ffcc835 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -879,7 +879,8 @@ static void cmd_help_long_parsed(void *parsed_result,
"ipv4_cksum|udp_cksum|tcp_cksum|tcp_lro|qinq_strip|"
"outer_ipv4_cksum|macsec_strip|header_split|"
"vlan_filter|vlan_extend|jumbo_frame|crc_strip|"
- "scatter|timestamp|security|keep_crc on|off\n"
+ "scatter|timestamp|security|keep_crc|"
+
"pmd_scratch0|pmd_scratch1|pmd_scratch2|pmd_scratch3|pmd_scratch4|pmd_scratch5
on|off\n"
" Enable or disable a per port Rx offloading"
" on all Rx queues of a port\n\n"
@@ -887,7 +888,8 @@ static void cmd_help_long_parsed(void *parsed_result,
"ipv4_cksum|udp_cksum|tcp_cksum|tcp_lro|qinq_strip|"
"outer_ipv4_cksum|macsec_strip|header_split|"
"vlan_filter|vlan_extend|jumbo_frame|crc_strip|"
- "scatter|timestamp|security|keep_crc on|off\n"
+ "scatter|timestamp|security|keep_crc|"
+
"pmd_scratch0|pmd_scratch1|pmd_scratch2|pmd_scratch3|pmd_scratch4|pmd_scratch5
on|off\n"
"Enable or disable a per queue Rx offloading"
" only on a specific Rx queue\n\n"
@@ -17991,7 +17993,8 @@ cmdline_parse_token_string_t
cmd_config_per_port_rx_offload_result_offload =
offload, "vlan_strip#ipv4_cksum#udp_cksum#tcp_cksum#tcp_lro#"
"qinq_strip#outer_ipv4_cksum#macsec_strip#"
"header_split#vlan_filter#vlan_extend#jumbo_frame#"
- "crc_strip#scatter#timestamp#security#keep_crc");
+ "crc_strip#scatter#timestamp#security#keep_crc#"
+
"pmd_scratch0#pmd_scratch1#pmd_scratch2#pmd_scratch3#pmd_scratch4#pmd_scratch5");
cmdline_parse_token_string_t cmd_config_per_port_rx_offload_result_on_off =
TOKEN_STRING_INITIALIZER
(struct cmd_config_per_port_rx_offload_result,
@@ -18067,7 +18070,8 @@ cmdline_parse_inst_t cmd_config_per_port_rx_offload = {
.help_str = "port config rx_offload vlan_strip|ipv4_cksum|"
"udp_cksum|tcp_cksum|tcp_lro|qinq_strip|outer_ipv4_cksum|"
"macsec_strip|header_split|vlan_filter|vlan_extend|"
- "jumbo_frame|crc_strip|scatter|timestamp|security|keep_crc "
+ "jumbo_frame|crc_strip|scatter|timestamp|security|keep_crc|"
+
"pmd_scratch0|pmd_scratch1|pmd_scratch2|pmd_scratch3|pmd_scratch4|pmd_scratch5 "
"on|off",
.tokens = {
(void *)&cmd_config_per_port_rx_offload_result_port,
@@ -18117,7 +18121,8 @@ cmdline_parse_token_string_t
cmd_config_per_queue_rx_offload_result_offload =
offload, "vlan_strip#ipv4_cksum#udp_cksum#tcp_cksum#tcp_lro#"
"qinq_strip#oute
Re: [dpdk-dev] [PATCH 2/2] net/vhost: support mrg-rxbuf disabling
From: Maxime Coquelin > Sent: Thursday, June 20, 2019 10:19 AM > To: Matan Azrad ; Noa Ezra > Cc: dev@dpdk.org > Subject: Re: [PATCH 2/2] net/vhost: support mrg-rxbuf disabling > > > > On 6/20/19 8:52 AM, Matan Azrad wrote: > > Hi all > > > >> -Original Message- > >> From: Noa Ezra > >> Sent: Thursday, June 20, 2019 8:58 AM > >> To: Maxime Coquelin > >> Cc: Matan Azrad ; dev@dpdk.org > >> Subject: RE: [PATCH 2/2] net/vhost: support mrg-rxbuf disabling > >> > >> Hi Maxime, > >> Thanks for your comment, please see below. > >> > >>> -Original Message- > >>> From: Maxime Coquelin [mailto:maxime.coque...@redhat.com] > >>> Sent: Wednesday, June 19, 2019 12:10 PM > >>> To: Noa Ezra > >>> Cc: Matan Azrad ; dev@dpdk.org > >>> Subject: Re: [PATCH 2/2] net/vhost: support mrg-rxbuf disabling > >>> > >>> Hi Noa, > >>> > >>> On 6/19/19 8:13 AM, Noa Ezra wrote: > Rx mergeable buffers is a virtio feature that allows chaining of > multiple virtio descriptors to handle large packet size. > This behavior is supported and enabled by default, however in case > the user knows that rx mergeable buffers are not needed, he can > disable the feature. > The user should also set mrg_rxbuf=off in virtual machine's xml. > >>> > >>> I'm not sure to understand why it is needed, as the vhost-user > >>> library supports the feature, it's better to let it being advertised. > >>> > >>> As you say, it is up to the user to disable it in the VM's XML. > >>> Done this way, the feature won't be negotiated. > >>> > >> I agree with you, I'll remove this patch from the series. > > > > Are you sure that no performance impact exists for redundant merg-rx-buf > configuration here? > > I'm not sure to understand what you mean, could you please elaborate? > I guess that if this feature is enabled and the feature actually are not used (no packets are scattered or merged) it will hurt the performance. So if one of the sides doesn't want to use it because of performance, it may want to disable it. > > What if the second side want it and the current side no? > > The feature won't be negotiated, assuming it has been disabled in QEMU > cmdline (or via libvirt). > > It may be that the vhost PMD user may want to disable it to save > performance from some reasons, no? > > > > Then this user should disable it at QEMU level. > So the vhost PMD is not one of the sides to decide? If so, why do we need the APIs to configure the features? Looks like also the qemu is configured with the feature the VM\host sides may decide in some cases to disable it. > Regards, > Maxime
[dpdk-dev] DPDK Techboard minutes of June 6
Meeting notes for the DPDK technical board meeting held on 2018-06-06 Attendees: - Bruce Richardson - Ferruh Yigit - Hemant Agrawal - Jerin Jacob - Maxime Coquelin - Olivier Matz - Stephen Hemminger - Thomas Monjalon 1) Techboard rep in DPDK Gov Board - Stephen will be new tech board rep succeeding Maxime. Olivier gave it a pass. 2) DPDK API Stability discussion - A sub-group is working on how to improve ABI/API stability and will come with a proposal as update to versioning.html and stable.html. Sub-group consist of Ray, Bruce, Stephen and Kevin. - Ray sent a proposal within sub-group for review. - There will be a status update in next TB meeting (June 19). - Jerin suggested that API stability should not come at the cost of performance regression. - Ray is proposing a panel discussion on ABI Compatibility for DPDK Userspace. He will choose the panelists. 3) discussion to extend Techboard membership - proposed to discuss Techboard membership in 1 month time. 4) Userspace summit CFP deadline over. - Proposals are under review. 5) Next meeting will be on June 19 and Jerin will chair it Thanks, Hemant
Re: [dpdk-dev] [PATCH v3 00/27] OCTEON TX2 common and mempool driver
> -Original Message- > From: jer...@marvell.com > Sent: Monday, June 17, 2019 9:25 PM > To: dev@dpdk.org > Cc: Jerin Jacob Kollanukkaran ; Thomas Monjalon > > Subject: [dpdk-dev] [PATCH v3 00/27] OCTEON TX2 common and mempool > driver Hi Thomas, Could you merge this patch series If there are no more review comments. Following patches sets[1] has dependency on this series. [1] http://patches.dpdk.org/patch/54002/ http://patches.dpdk.org/patch/54057/ http://patches.dpdk.org/patch/54017/ > From: Jerin Jacob > > This patch set adds initial driver support for OCTEON TX2 SoC. > > OCTEON TX2 is an armv8.2 SoC with integrated HW based mempool, ethdev, > cryptodev, compressdev, and eventdev devices. > > This patch set adds common driver and mempool device driver for OCTEON > TX2 SoC. > There will be three more patch series in this release to support ethdev, > eventdev and cryptodev devices > > More details about the OCTEON TX2 platform may found in [PATCH 15/27] > doc: add Marvell OCTEON TX2 platform guide under > doc/guides/platform/octeontx2.rst file. > > This patches series also available at https://github.com/jerinjacobk/dpdk.git > for quick download and review. > > # Note on check patch issues > 1) The mailbox prototype is the same as Linux kernel. > https://elixir.bootlin.com/linux/latest/source/drivers/net/ethernet/marvell/ > octeontx2/af/mbox.h#L123 > In order to keep the base code intact, mailbox prototype expressed as > macros with warnings > 2) There are a few warnings from tooling about expected to add new > symbols in the EXPERIMENTAL section. Since these API will be called only by > octeontx2 client drivers and prototype are not exported to the application, > those warnings are not relevant, Discussion at > http://patches.dpdk.org/patch/53590/ > > v3: > > 1) Replace the reference to v19.08 from v19.05 > 2) remove rte_panic from driver code > 3) rebase to dpdk.org master(as of 17-June) > > v2: > > 1) Added CONFIG_RTE_MAX_VFIO_GROUPS for octeontx2 config in patch 1 > 2) Rebased to master to accommodate latest rename like ETHER_ADDR_LEN > to RTE_ETHER_ADDR_LEN > 3) Added pmd.raw.octeontx2.dpi log message in patch 5 > 4) Update platform guide with debugfs documentation in patch 15 > 5) Fix arm64 build issue with patch 25(Aaron Conole) > "mempool/octeontx2: add optimized dequeue operation for arm64" > > Cc: Thomas Monjalon > > Jerin Jacob (22): > common/octeontx2: add build infrastructure and HW definition > common/octeontx2: add IO handling APIs > common/octeontx2: add mbox request and response definition > common/octeontx2: add mailbox base support infra > common/octeontx2: add runtime log infra > common/octeontx2: add mailbox send and receive support > common/octeontx2: introduce common device class > common/octeontx2: introduce irq handling functions > common/octeontx2: handle intra device operations > common/octeontx2: add VF mailbox IRQ and msg handler > doc: add Marvell OCTEON TX2 platform guide > mempool/octeontx2: add build infra and device probe > drivers: add init and fini on octeontx2 NPA object > mempool/octeontx2: add NPA HW operations > mempool/octeontx2: add NPA IRQ handler > mempool/octeontx2: add context dump support > mempool/octeontx2: add mempool alloc op > mempool/octeontx2: add mempool free op > mempool/octeontx2: add remaining slow path ops > mempool/octeontx2: add fast path mempool ops > mempool/octeontx2: add devargs for max pool selection > doc: add Marvell OCTEON TX2 mempool documentation > > Nithin Dabilpuram (4): > common/octeontx2: add AF to PF mailbox IRQ and msg handlers > common/octeontx2: add PF to VF mailbox IRQ and msg handlers > common/octeontx2: add uplink message support > common/octeontx2: add FLR IRQ handler > > Pavan Nikhilesh (1): > mempool/octeontx2: add optimized dequeue operation for arm64 > > MAINTAINERS | 10 + > config/common_base|5 + > config/defconfig_arm64-octeontx2-linuxapp-gcc |3 + > doc/guides/mempool/index.rst |1 + > doc/guides/mempool/octeontx2.rst | 90 + > .../octeontx2_packet_flow_hw_accelerators.svg | 2804 > + .../img/octeontx2_resource_virtualization.svg | 2418 > ++ > doc/guides/platform/index.rst |1 + > doc/guides/platform/octeontx2.rst | 496 +++ > doc/guides/rel_notes/release_19_08.rst|2 + > drivers/common/Makefile |5 + > drivers/common/meson.build|2 +- > drivers/common/octeontx2/Makefile | 37 + > drivers/common/octeontx2/hw/otx2_nix.h| 1379 > drivers/common/octeontx2/hw/otx2_npa.h| 305 ++ > drivers/common/octeontx2/hw/otx2_npc.h| 472 +++ > drivers/common/octeontx2/hw/otx2_rvu.h| 212 ++ > drivers/common/octeontx2/hw/otx2_sso.h| 209 ++ > drivers/
Re: [dpdk-dev] [PATCH v2] lib/telemetry: add support to fetch global metrics
> Hi Reshma, Kevin,
>
> Not related to this patch, but when telemetry library enabled, it is causing
> some warnings [1] with gcc9
>
> The [-Waddress-of-packed-member] warnings already disable for gcc, but
> you need following update to "lib/librte_telemetry/Makefile":
> -CFLAGS += -I$(SRCDIR)
> +CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR)
>
> Can you please take care of this?
>
Sure, I'll look into it. Thanks.
>
>
> [1]
> In file included from .../dpdk/x86_64-native-linuxapp-
> gcc/include/rte_ethdev.h:160,
> from .../dpdk/lib/librte_telemetry/rte_telemetry_parser.c:13:
> .../dpdk/x86_64-native-linuxapp-gcc/include/rte_ether.h: In function
> ‘rte_is_broadcast_ether_addr’:
> .../dpdk/x86_64-native-linuxapp-gcc/include/rte_ether.h:152:2: warning:
> converting a packed ‘const struct rte_ether_addr’ pointer (alignment 1) to a
> ‘unaligned_uint16_t’ {aka ‘const short unsigned int’} pointer (alignment 2)
> may result in an unaligned pointer value [-Waddress-of-packed-member]
> 152 | const unaligned_uint16_t *ea_words = (const unaligned_uint16_t
> *)ea;
> | ^
Re: [dpdk-dev] [PATCH v3 1/3] net/ice: enable switch filter
Hi, > -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Qiming Yang > Sent: Thursday, June 20, 2019 1:35 PM > To: dev@dpdk.org > Cc: Zhao1, Wei > Subject: [dpdk-dev] [PATCH v3 1/3] net/ice: enable switch filter > > From: wei zhao > > The patch enables the backend of rte_flow. It transfers > rte_flow_xxx to device specific data structure and > configures packet process engine's binary classifier > (switch) properly. > > Signed-off-by: Wei Zhao > --- > drivers/net/ice/Makefile| 1 + > drivers/net/ice/ice_ethdev.c| 18 ++ > drivers/net/ice/ice_ethdev.h| 7 + > drivers/net/ice/ice_switch_filter.c | 525 > > drivers/net/ice/ice_switch_filter.h | 24 ++ > drivers/net/ice/meson.build | 3 +- > 6 files changed, 577 insertions(+), 1 deletion(-) > create mode 100644 drivers/net/ice/ice_switch_filter.c > create mode 100644 drivers/net/ice/ice_switch_filter.h > > diff --git a/drivers/net/ice/Makefile b/drivers/net/ice/Makefile > index 0e5c55e..b10d826 100644 > --- a/drivers/net/ice/Makefile > +++ b/drivers/net/ice/Makefile > @@ -60,6 +60,7 @@ ifeq ($(CONFIG_RTE_ARCH_X86), y) > SRCS-$(CONFIG_RTE_LIBRTE_ICE_PMD) += ice_rxtx_vec_sse.c > endif > [...] > + struct ice_adv_lkup_elem *list = NULL; > + uint16_t lkups_num = 0; > + > + ret = ice_parse_switch_filter(pattern, actions, error, > + &rule_info, &list, &lkups_num); > + if (ret) > + goto out; > + > + ret = ice_parse_switch_action(pf, actions, error, &rule_info); > + if (ret) > + goto out; > + > + ret = ice_switch_rule_set(pf, list, lkups_num, &rule_info, flow, error); > + if (ret) > + goto out; > + > + rte_free(list); > + return 0; > + It's better to change "goto out" to "goto error". BRs, Xiao > +out: > + rte_free(list); > + > + return -rte_errno; > +} > +
Re: [dpdk-dev] [PATCH v3 1/3] net/ice: enable switch filter
Hi， xiao > -Original Message- > From: Wang, Xiao W > Sent: Thursday, June 20, 2019 5:01 PM > To: Yang, Qiming ; dev@dpdk.org > Cc: Zhao1, Wei ; Zhang, Qi Z ; > Xing, Beilei > Subject: RE: [dpdk-dev] [PATCH v3 1/3] net/ice: enable switch filter > > Hi, > > > -Original Message- > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Qiming Yang > > Sent: Thursday, June 20, 2019 1:35 PM > > To: dev@dpdk.org > > Cc: Zhao1, Wei > > Subject: [dpdk-dev] [PATCH v3 1/3] net/ice: enable switch filter > > > > From: wei zhao > > > > The patch enables the backend of rte_flow. It transfers rte_flow_xxx > > to device specific data structure and configures packet process > > engine's binary classifier > > (switch) properly. > > > > Signed-off-by: Wei Zhao > > --- > > drivers/net/ice/Makefile| 1 + > > drivers/net/ice/ice_ethdev.c| 18 ++ > > drivers/net/ice/ice_ethdev.h| 7 + > > drivers/net/ice/ice_switch_filter.c | 525 > > > > drivers/net/ice/ice_switch_filter.h | 24 ++ > > drivers/net/ice/meson.build | 3 +- > > 6 files changed, 577 insertions(+), 1 deletion(-) create mode 100644 > > drivers/net/ice/ice_switch_filter.c > > create mode 100644 drivers/net/ice/ice_switch_filter.h > > > > diff --git a/drivers/net/ice/Makefile b/drivers/net/ice/Makefile index > > 0e5c55e..b10d826 100644 > > --- a/drivers/net/ice/Makefile > > +++ b/drivers/net/ice/Makefile > > @@ -60,6 +60,7 @@ ifeq ($(CONFIG_RTE_ARCH_X86), y) > > SRCS-$(CONFIG_RTE_LIBRTE_ICE_PMD) += ice_rxtx_vec_sse.c endif > > > [...] > > > + struct ice_adv_lkup_elem *list = NULL; > > + uint16_t lkups_num = 0; > > + > > + ret = ice_parse_switch_filter(pattern, actions, error, > > + &rule_info, &list, &lkups_num); > > + if (ret) > > + goto out; > > + > > + ret = ice_parse_switch_action(pf, actions, error, &rule_info); > > + if (ret) > > + goto out; > > + > > + ret = ice_switch_rule_set(pf, list, lkups_num, &rule_info, flow, error); > > + if (ret) > > + goto out; > > + > > + rte_free(list); > > + return 0; > > + > > It's better to change "goto out" to "goto error". Ok, Update in v4 > > BRs, > Xiao > > > +out: > > + rte_free(list); > > + > > + return -rte_errno; > > +} > > +
Re: [dpdk-dev] [PATCH v3 2/3] net/ice: add generic flow API
Hi,
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Qiming Yang
> Sent: Thursday, June 20, 2019 1:35 PM
> To: dev@dpdk.org
> Cc: Yang, Qiming
> Subject: [dpdk-dev] [PATCH v3 2/3] net/ice: add generic flow API
>
> This patch adds ice_flow_create, ice_flow_destroy,
> ice_flow_flush and ice_flow_validate support,
> these are used to handle all the generic filters.
>
> Signed-off-by: Qiming Yang
> ---
> drivers/net/ice/Makefile | 1 +
> drivers/net/ice/ice_ethdev.c | 44 +++
> drivers/net/ice/ice_ethdev.h | 5 +
> drivers/net/ice/ice_generic_flow.c | 682
> +
> drivers/net/ice/ice_generic_flow.h | 654
> +++
> drivers/net/ice/meson.build| 1 +
> 6 files changed, 1387 insertions(+)
> create mode 100644 drivers/net/ice/ice_generic_flow.c
> create mode 100644 drivers/net/ice/ice_generic_flow.h
>
> diff --git a/drivers/net/ice/Makefile b/drivers/net/ice/Makefile
> index b10d826..32abeb6 100644
> --- a/drivers/net/ice/Makefile
> +++ b/drivers/net/ice/Makefile
> @@ -79,5 +79,6 @@ endif
> ifeq ($(CC_AVX2_SUPPORT), 1)
> SRCS-$(CONFIG_RTE_LIBRTE_ICE_PMD) += ice_rxtx_vec_avx2.c
> endif
> +SRCS-$(CONFIG_RTE_LIBRTE_ICE_PMD) += ice_generic_flow.c
>
> include $(RTE_SDK)/mk/rte.lib.mk
> diff --git a/drivers/net/ice/ice_ethdev.c b/drivers/net/ice/ice_ethdev.c
> index a94aa7e..8ee06d1 100644
> --- a/drivers/net/ice/ice_ethdev.c
> +++ b/drivers/net/ice/ice_ethdev.c
> @@ -15,6 +15,7 @@
> #include "base/ice_dcb.h"
> #include "ice_ethdev.h"
> #include "ice_rxtx.h"
> +#include "ice_switch_filter.h"
>
> #define ICE_MAX_QP_NUM "max_queue_pair_num"
> #define ICE_DFLT_OUTER_TAG_TYPE ICE_AQ_VSI_OUTER_TAG_VLAN_9100
> @@ -83,6 +84,10 @@ static int ice_xstats_get(struct rte_eth_dev *dev,
> static int ice_xstats_get_names(struct rte_eth_dev *dev,
> struct rte_eth_xstat_name *xstats_names,
> unsigned int limit);
> +static int ice_dev_filter_ctrl(struct rte_eth_dev *dev,
> + enum rte_filter_type filter_type,
> + enum rte_filter_op filter_op,
> + void *arg);
>
> static const struct rte_pci_id pci_id_ice_map[] = {
> { RTE_PCI_DEVICE(ICE_INTEL_VENDOR_ID,
> ICE_DEV_ID_E810C_BACKPLANE) },
> @@ -141,6 +146,7 @@ static const struct eth_dev_ops ice_eth_dev_ops = {
> .xstats_get = ice_xstats_get,
> .xstats_get_names = ice_xstats_get_names,
> .xstats_reset = ice_stats_reset,
> + .filter_ctrl = ice_dev_filter_ctrl,
> };
>
> /* store statistics names and its offset in stats structure */
> @@ -1478,6 +1484,8 @@ ice_dev_init(struct rte_eth_dev *dev)
> /* get base queue pairs index in the device */
> ice_base_queue_get(pf);
>
> + TAILQ_INIT(&pf->flow_list);
> +
> return 0;
>
> err_pf_setup:
> @@ -1620,6 +1628,8 @@ ice_dev_uninit(struct rte_eth_dev *dev)
> {
> struct rte_pci_device *pci_dev = RTE_ETH_DEV_TO_PCI(dev);
> struct rte_intr_handle *intr_handle = &pci_dev->intr_handle;
> + struct ice_pf *pf = ICE_DEV_PRIVATE_TO_PF(dev->data->dev_private);
> + struct rte_flow *p_flow;
>
> ice_dev_close(dev);
>
> @@ -1637,6 +1647,13 @@ ice_dev_uninit(struct rte_eth_dev *dev)
> rte_intr_callback_unregister(intr_handle,
>ice_interrupt_handler, dev);
>
> + /* Remove all flows */
> + while ((p_flow = TAILQ_FIRST(&pf->flow_list))) {
> + TAILQ_REMOVE(&pf->flow_list, p_flow, node);
> + ice_free_switch_filter_rule(p_flow->rule);
> + rte_free(p_flow);
> + }
> +
> return 0;
> }
>
> @@ -3622,6 +3639,33 @@ static int ice_xstats_get_names(__rte_unused
> struct rte_eth_dev *dev,
> }
>
> static int
> +ice_dev_filter_ctrl(struct rte_eth_dev *dev,
> + enum rte_filter_type filter_type,
> + enum rte_filter_op filter_op,
> + void *arg)
> +{
> + int ret = 0;
> +
> + if (!dev)
> + return -EINVAL;
> +
> + switch (filter_type) {
> + case RTE_ETH_FILTER_GENERIC:
> + if (filter_op != RTE_ETH_FILTER_GET)
> + return -EINVAL;
> + *(const void **)arg = &ice_flow_ops;
> + break;
> + default:
> + PMD_DRV_LOG(WARNING, "Filter type (%d) not supported",
> + filter_type);
> + ret = -EINVAL;
> + break;
> + }
> +
> + return ret;
> +}
> +
> +static int
> ice_pci_probe(struct rte_pci_driver *pci_drv __rte_unused,
> struct rte_pci_device *pci_dev)
> {
> diff --git a/drivers/net/ice/ice_ethdev.h b/drivers/net/ice/ice_ethdev.h
> index 50b966c..8a52239 100644
> --- a/drivers/net/ice/ice_ethdev.h
> +++ b/drivers/net/ice/ice_ethdev.h
> @@ -234,12 +234,16
Re: [dpdk-dev] [PATCH] examples/vhost_crypto: fix unchecked return value
On 5/15/19 6:25 PM, Fan Zhang wrote:
This patch tries to fix the coverity issue of unchecked
return value. Since the function that causes the problem
is unused, it is removed completely.
Coverity issue: 336816
Fixes: f5188211c721 ("examples/vhost_crypto: add sample application")
Cc: sta...@dpdk.org
Signed-off-by: Fan Zhang
---
examples/vhost_crypto/main.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/examples/vhost_crypto/main.c b/examples/vhost_crypto/main.c
index ac7118e7e..cfb9dfda2 100644
--- a/examples/vhost_crypto/main.c
+++ b/examples/vhost_crypto/main.c
@@ -354,12 +354,6 @@ static const struct vhost_device_ops
virtio_crypto_device_ops = {
.destroy_device = destroy_device,
};
-__attribute__((unused))
-static void clrscr(void)
-{
- system("@cls||clear");
-}
-
static int
vhost_crypto_worker(void *arg)
{
Reviewed-by: Maxime Coquelin
I'll change the title to:
examples/vhost_crypto: remove unused function
Re: [dpdk-dev] [PATCH] vhost/crypto: fix logically dead code
On 5/15/19 6:19 PM, Fan Zhang wrote:
This patch fixes a few same class bugs that causes the
logically dead code in vhost_crypto.
Coverity issue: 277236
Coverity issue: 277233
Coverity issue: 277220
Coverity issue: 277214
Fixes: 3bb595ecd682 ("vhost/crypto: add request handler")
Cc: sta...@dpdk.org
Signed-off-by: Fan Zhang
---
lib/librte_vhost/vhost_crypto.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/librte_vhost/vhost_crypto.c b/lib/librte_vhost/vhost_crypto.c
index 0edf12d52..069b56108 100644
--- a/lib/librte_vhost/vhost_crypto.c
+++ b/lib/librte_vhost/vhost_crypto.c
@@ -1024,7 +1024,7 @@ prepare_sym_chain_op(struct vhost_crypto *vcrypto, struct
rte_crypto_op *op,
}
if (unlikely(copy_data(rte_pktmbuf_mtod(m_src, uint8_t *),
vc_req, &desc, chain->para.src_data_len,
- nb_descs, vq_size)) < 0) {
+ nb_descs, vq_size) < 0)) {
ret = VIRTIO_CRYPTO_BADMSG;
goto error_exit;
}
@@ -1598,7 +1598,7 @@ rte_vhost_crypto_fetch_requests(int vid, uint32_t qid,
op->sym->m_dst->data_off = 0;
if (unlikely(vhost_crypto_process_one_req(vcrypto, vq,
- op, head, desc_idx)) < 0)
+ op, head, desc_idx) < 0))
break;
}
Reviewed-by: Maxime Coquelin
Thanks,
Maxime
Re: [dpdk-dev] [PATCH] vhost/crypto: fix inferred misuse of enum
On 5/15/19 6:09 PM, Fan Zhang wrote:
This patch fixes the inferred misuse of enum of crypto
algorithms.
Coverity issue: 325879
Fixes: e80a98708166 ("vhost/crypto: add session message handler")
Cc: sta...@dpdk.org
Signed-off-by: Fan Zhang
---
lib/librte_vhost/vhost_crypto.c | 93 ++---
1 file changed, 41 insertions(+), 52 deletions(-)
Reviewed-by: Maxime Coquelin
Thanks,
Maxime
Re: [dpdk-dev] [PATCH v2] vhost: fix add a missing include
On 6/20/19 7:44 AM, Noa Ezra wrote:
Add a missing include with the defines for vhost-user driver features.
Fixes: 5fbb3941da9f ("vhost: introduce driver features related APIs")
Cc:sta...@dpdk.org
Signed-off-by: Noa Ezra
Reviewed-by: Maxime Coquelin
Reviewed-by: Matan Azrad
---
v2 remove checkpatch warnings
---
lib/librte_vhost/rte_vhost.h | 1 +
1 file changed, 1 insertion(+)
Applied to dpdk-next-virtio/master.
Thanks,
Maxime
Re: [dpdk-dev] [PATCH v2 0/4] Some fixes for mergeable Rx
On 6/20/19 4:34 AM, Tiwei Bie wrote: v2: - Fix commit log (Maxime); Tiwei Bie (4): net/virtio: fix memory leak in in-order Rx net/virtio: fix memory leak in mergeable Rx net/virtio: fix memory leak in mergeable packed Rx net/virtio: fix packets check in mergeable packed Rx drivers/net/virtio/virtio_rxtx.c | 56 +++- 1 file changed, 26 insertions(+), 30 deletions(-) Applied to dpdk-next-virtio/master. Thanks, Maxime
Re: [dpdk-dev] [PATCH v4 1/2] net/virtio: add Tx preparation
On 6/17/19 1:31 PM, Andrew Rybchenko wrote:
From: Dilshod Urazov
Virtio requires pseudo-header checksum in TCP/UDP checksum to do
offload, but it was lost when Tx prepare is introduced. Also
rte_validate_tx_offload() should be used to validate Tx offloads.
Also it is incorrect to do virtio_tso_fix_cksum() after prepend
to mbuf without taking prepended size into account, since layer 2/3/4
lengths provide incorrect offsets after prepend.
Fixes: 4fb7e803eb1a ("ethdev: add Tx preparation")
Cc:sta...@dpdk.org
Signed-off-by: Dilshod Urazov
Signed-off-by: Andrew Rybchenko
Reviewed-by: Tiwei Bie
---
drivers/net/virtio/virtio_ethdev.c | 1 +
drivers/net/virtio/virtio_ethdev.h | 3 +++
drivers/net/virtio/virtio_rxtx.c | 32 +-
3 files changed, 35 insertions(+), 1 deletion(-)
Applied to dpdk-next-virtio/master.
Thanks,
Maxime
Re: [dpdk-dev] [PATCH v4 2/2] net/virtio: move VLAN tag insertion to Tx prepare
On 6/17/19 1:31 PM, Andrew Rybchenko wrote:
From: Dilshod Urazov
VLAN tag insertion should be in Tx prepare, not in Tx burst functions.
One of Tx prepare goals is to be able to do preparations in advance
(possibliy on different CPU core) and then transmit it fast.
Also Tx prepare can report that a packet does not pass Tx offloads
check. E.g. has no enough headroom to insert VLAN header.
Fixes: 4fb7e803eb1a ("ethdev: add Tx preparation")
Cc:sta...@dpdk.org
Signed-off-by: Dilshod Urazov
Signed-off-by: Andrew Rybchenko
---
v4:
- add more details to commit log
drivers/net/virtio/virtio_rxtx.c | 50 +---
1 file changed, 14 insertions(+), 36 deletions(-)
Applied to dpdk-next-virtio/master.
Thanks,
Maxime
Re: [dpdk-dev] [PATCH 0/5] virtio: release port upon close
On 6/5/19 11:43 AM, Tiwei Bie wrote: Tiwei Bie (5): net/virtio: fix queue memory leak on error net/virtio: unmap port IO for legacy device net/virtio: unmap device on initialization error net/virtio: release port upon close app/testpmd: drop the workaround for virtio-user app/test-pmd/testpmd.c| 13 - drivers/net/virtio/virtio_ethdev.c| 50 ++- drivers/net/virtio/virtio_pci.c | 1 + .../net/virtio/virtio_user/virtio_user_dev.h | 1 - drivers/net/virtio/virtio_user_ethdev.c | 12 ++--- 5 files changed, 42 insertions(+), 35 deletions(-) Applied to dpdk-next-virtio/master. Thanks, Maxime
Re: [dpdk-dev] [PATCH] examples/vdpa: remove trace of legacy "linuxapp"
On 6/17/19 9:54 AM, David Marchand wrote:
This check on Linux environment has been added at a time when we already
had switched to using the boolean RTE_EXEC_ENV_LINUXAPP.
It was then missed when converting to RTE_EXEC_ENV_LINUX.
Fixes: edbed86d1cc3 ("examples/vdpa: introduce a new sample for vDPA")
Fixes: 742bde12f3bd ("build/linux: rename macro from LINUXAPP to LINUX")
Cc: sta...@dpdk.org
Signed-off-by: David Marchand
---
If we backport this to 18.11, the fix is to switch to
RTE_EXEC_ENV_LINUXAPP.
---
examples/vdpa/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Applied to dpdk-next-virtio/master.
Thanks,
Maxime
Re: [dpdk-dev] [PATCH] examples/vhost_crypto: fix unchecked return value
On 5/15/19 6:25 PM, Fan Zhang wrote:
This patch tries to fix the coverity issue of unchecked
return value. Since the function that causes the problem
is unused, it is removed completely.
Coverity issue: 336816
Fixes: f5188211c721 ("examples/vhost_crypto: add sample application")
Cc: sta...@dpdk.org
Signed-off-by: Fan Zhang
---
examples/vhost_crypto/main.c | 6 --
1 file changed, 6 deletions(-)
Applied to dpdk-next-virtio/master.
Thanks,
Maxime
Re: [dpdk-dev] [PATCH] vhost/crypto: fix logically dead code
On 5/15/19 6:19 PM, Fan Zhang wrote:
This patch fixes a few same class bugs that causes the
logically dead code in vhost_crypto.
Coverity issue: 277236
Coverity issue: 277233
Coverity issue: 277220
Coverity issue: 277214
Fixes: 3bb595ecd682 ("vhost/crypto: add request handler")
Cc: sta...@dpdk.org
Signed-off-by: Fan Zhang
---
lib/librte_vhost/vhost_crypto.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Applied to dpdk-next-virtio/master.
Thanks,
Maxime
Re: [dpdk-dev] [PATCH] vhost/crypto: fix inferred misuse of enum
On 5/15/19 6:09 PM, Fan Zhang wrote:
This patch fixes the inferred misuse of enum of crypto
algorithms.
Coverity issue: 325879
Fixes: e80a98708166 ("vhost/crypto: add session message handler")
Cc: sta...@dpdk.org
Signed-off-by: Fan Zhang
---
lib/librte_vhost/vhost_crypto.c | 93 ++---
1 file changed, 41 insertions(+), 52 deletions(-)
Applied to dpdk-next-virtio/master.
Thanks,
Maxime
Re: [dpdk-dev] [PATCH v6 3/6] raw/ntb: add handshake process
Thanks for comments for patch 1 & 2. Will refine them in the coming v7. And > -Original Message- > From: Wu, Jingjing > Sent: Wednesday, June 19, 2019 00:08 > To: Li, Xiaoyun ; Wiles, Keith ; > Liang, Cunming ; Maslekar, Omkar > > Cc: dev@dpdk.org > Subject: RE: [PATCH v6 3/6] raw/ntb: add handshake process > > >mw_size[mw_idx]); > > If the memzone is reserved inside of driver, how is the buffer be mapped > without > copy when enqueuer/dequeuer as the buffer might not be in the memzone? > How about to design the dev_config to set the mw to be a memzone (might > address + size) which can be created by application instead of created > internally? This is a temporary function to verify the memory w/r works and to suit the hw limitation. There is no fifo right now. Will add the whole process of pkt mbuf pool create and aligned memzone allocation in next release. > > > + db_bits = (*hw->ntb_ops->db_read)(dev); > > + if (!db_bits) > > + NTB_LOG(ERR, "No doorbells"); > > + > > Is the db_bits a common setting between different kind of NTB? Yes. > > [..] > > + /* Init doorbell. */ > > + hw->db_valid_mask = ((uint64_t)1 << hw->db_cnt) - 1; > Use RTE_LEN2MASK instead? Sure. Thx. > > Thanks > Jingjing
Re: [dpdk-dev] [PATCH v2 02/10] meson: add BUILDING_RTE_SDK
On Wed, Jun 19, 2019 at 02:34:43PM -0400, Neil Horman wrote:
> On Wed, Jun 19, 2019 at 11:46:12AM +0100, Bruce Richardson wrote:
> > On Wed, Jun 19, 2019 at 06:39:00AM -0400, Neil Horman wrote:
> > > On Thu, Jun 13, 2019 at 03:44:02PM +0100, Bruce Richardson wrote:
> > > > On Thu, Jun 13, 2019 at 10:23:36AM -0400, Neil Horman wrote:
> > > > > The __rte_internal macro is defined dependent on the value of the
> > > > > build
> > > > > environment variable BUILDING_RTE_SDK. This variable was set in the
> > > > > Makefile environment but not the meson environment, so lets reconcile
> > > > > the two by defining it for meson in the lib and drivers directories,
> > > > > but
> > > > > not the examples/apps directories, which should be treated as they are
> > > > > not part of the core DPDK library
> > > > >
> > > > > Signed-off-by: Neil Horman
> > > > > CC: Jerin Jacob Kollanukkaran
> > > > > CC: Bruce Richardson
> > > > > CC: Thomas Monjalon
> > > > > ---
> > > > > drivers/meson.build | 1 +
> > > > > lib/meson.build | 1 +
> > > > > 2 files changed, 2 insertions(+)
> > > > >
> > > > > diff --git a/drivers/meson.build b/drivers/meson.build
> > > > > index 4c444f495..a312277d1 100644
> > > > > --- a/drivers/meson.build
> > > > > +++ b/drivers/meson.build
> > > > > @@ -23,6 +23,7 @@ endif
> > > > >
> > > > > # specify -D_GNU_SOURCE unconditionally
> > > > > default_cflags += '-D_GNU_SOURCE'
> > > > > +default_cflags += '-DBUILDING_RTE_SDK'
> > > > >
> > > > > foreach class:dpdk_driver_classes
> > > > > drivers = []
> > > > > diff --git a/lib/meson.build b/lib/meson.build
> > > > > index e067ce5ea..0e398d534 100644
> > > > > --- a/lib/meson.build
> > > > > +++ b/lib/meson.build
> > > > > @@ -35,6 +35,7 @@ if is_windows
> > > > > endif
> > > > >
> > > > > default_cflags = machine_args
> > > > > +default_cflags += '-DBUILDING_RTE_SDK'
> > > > > if cc.has_argument('-Wno-format-truncation')
> > > > > default_cflags += '-Wno-format-truncation'
> > > > > endif
> > > >
> > > > While this will work, it's not something that individual components
> > > > should
> > > > ever need to override so I think using "add_project_arguments()"
> > > > function
> > > > is a better way to add this to the C builds.
> > > >
> > > That sounds like it makes sense to me, but reading the documentation for
> > > meson,
> > > I'm not sure I see the behavioral difference. Can you elaborate on how
> > > add_project_arguments behaves differently here?
> > >
> > The end result should be the same. The key differences are:
> > 1. Only ever needs to be set in one place
> > 2. Cannot be overridden by the individual objects in the build.
> >
> > So it's just slightly cleaner. If you prefer your existing approach, I'm ok
> > with that.
> >
>
> No, I like the aspect of item 2, though, just for clarification, do we really
> only need to set it at the top level? I ask because it seems that
> BUILDING_RTE_SDK should be set for the lib and drivers subtrees, but not the
> app
> subtree, as that tree, being the location of our example code, should be
> treated
> as non-core dpdk libraries, and so should throw an error if any code there
> attempts to use a dpdk internal only function. Or is there some other magic
> afoot in that subtree?
>
Good point. Keep your original patch as-is so.
/Bruce
Re: [dpdk-dev] [PATCH v3 2/3] net/ice: add generic flow API
Hi,
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Qiming Yang
> Sent: Thursday, June 20, 2019 1:35 PM
> To: dev@dpdk.org
> Cc: Yang, Qiming
> Subject: [dpdk-dev] [PATCH v3 2/3] net/ice: add generic flow API
>
> This patch adds ice_flow_create, ice_flow_destroy,
> ice_flow_flush and ice_flow_validate support,
> these are used to handle all the generic filters.
>
> Signed-off-by: Qiming Yang
> ---
> drivers/net/ice/Makefile | 1 +
> drivers/net/ice/ice_ethdev.c | 44 +++
> drivers/net/ice/ice_ethdev.h | 5 +
> drivers/net/ice/ice_generic_flow.c | 682
> +
> drivers/net/ice/ice_generic_flow.h | 654
> +++
> drivers/net/ice/meson.build| 1 +
> 6 files changed, 1387 insertions(+)
> create mode 100644 drivers/net/ice/ice_generic_flow.c
> create mode 100644 drivers/net/ice/ice_generic_flow.h
>
[...]
> + case RTE_FLOW_ITEM_TYPE_ETH:
> + eth_spec = item->spec;
> + eth_mask = item->mask;
> +
> + if (eth_spec && eth_mask) {
> + if (rte_is_broadcast_ether_addr(ð_mask-
> >src))
> + input_set |= ICE_INSET_SMAC;
> + if (rte_is_broadcast_ether_addr(ð_mask-
> >dst))
> + input_set |= ICE_INSET_DMAC;
> + if (eth_mask->type == RTE_BE16(0x))
> + input_set |= ICE_INSET_ETHERTYPE;
> + }
> + break;
> + case RTE_FLOW_ITEM_TYPE_IPV4:
> + ipv4_spec = item->spec;
> + ipv4_mask = item->mask;
> +
> + if (!(ipv4_spec && ipv4_mask)) {
> + rte_flow_error_set(error, EINVAL,
> +RTE_FLOW_ERROR_TYPE_ITEM,
> +item,
> +"Invalid IPv4 spec or mask.");
> + return 0;
> + }
> +
> + /* Check IPv4 mask and update input set */
> + if (ipv4_mask->hdr.version_ihl ||
> + ipv4_mask->hdr.total_length ||
> + ipv4_mask->hdr.packet_id ||
> + ipv4_mask->hdr.hdr_checksum) {
> + rte_flow_error_set(error, EINVAL,
> +RTE_FLOW_ERROR_TYPE_ITEM,
> +item,
> +"Invalid IPv4 mask.");
> + return 0;
> + }
> +
> + if (outer_ip) {
> + if (ipv4_mask->hdr.src_addr == UINT32_MAX)
> + input_set |= ICE_INSET_IPV4_SRC;
> + if (ipv4_mask->hdr.dst_addr == UINT32_MAX)
> + input_set |= ICE_INSET_IPV4_DST;
> + if (ipv4_mask->hdr.type_of_service ==
> UINT8_MAX)
> + input_set |= ICE_INSET_IPV4_TOS;
> + if (ipv4_mask->hdr.time_to_live ==
> UINT8_MAX)
> + input_set |= ICE_INSET_IPV4_TTL;
> + if (ipv4_mask->hdr.fragment_offset == 0)
Seems a typo. fragment_offset --> next_proto_id == UINT8_MAX.
> + input_set |= ICE_INSET_IPV4_PROTO;
> + outer_ip = false;
> + } else {
> + if (ipv4_mask->hdr.src_addr == UINT32_MAX)
> + input_set |=
> ICE_INSET_TUN_IPV4_SRC;
> + if (ipv4_mask->hdr.dst_addr == UINT32_MAX)
> + input_set |=
> ICE_INSET_TUN_IPV4_DST;
> + if (ipv4_mask->hdr.time_to_live ==
> UINT8_MAX)
> + input_set |=
> ICE_INSET_TUN_IPV4_TTL;
> + if (ipv4_mask->hdr.next_proto_id ==
> UINT8_MAX)
> + input_set |=
> ICE_INSET_TUN_IPV4_PROTO;
> + }
> + break;
> + case RTE_FLOW_ITEM_TYPE_IPV6:
> + ipv6_spec = item->spec;
> + ipv6_mask = item->mask;
> +
> + if (!(ipv6_spec && ipv6_mask)) {
> + rte_flow_error_set(error, EINVAL,
> + RTE_FLOW_ERROR_TYPE_ITEM,
> + item, "Invalid IPv6 spec or mask");
> + return 0;
> + }
[...]
> +/* bit 16 ~ bit 31 */
> +#define ICE_INSET_IPV4_TOS0x00010
Re: [dpdk-dev] [PATCH v2 02/10] meson: add BUILDING_RTE_SDK
On Thu, Jun 13, 2019 at 10:23:36AM -0400, Neil Horman wrote: > The __rte_internal macro is defined dependent on the value of the build > environment variable BUILDING_RTE_SDK. This variable was set in the > Makefile environment but not the meson environment, so lets reconcile > the two by defining it for meson in the lib and drivers directories, but > not the examples/apps directories, which should be treated as they are > not part of the core DPDK library > > Signed-off-by: Neil Horman > CC: Jerin Jacob Kollanukkaran > CC: Bruce Richardson > CC: Thomas Monjalon Acked-by: Bruce Richardson
[dpdk-dev] [PATCH v7 1/6] raw/ntb: introduce ntb rawdev driver
Introduce rawdev driver support for NTB (Non-transparent Bridge) which
can help to connect two separate hosts with each other.
Signed-off-by: Xiaoyun Li
---
config/common_base| 5 +
drivers/raw/Makefile | 1 +
drivers/raw/meson.build | 2 +-
drivers/raw/ntb_rawdev/Makefile | 27 +
drivers/raw/ntb_rawdev/meson.build| 7 +
drivers/raw/ntb_rawdev/ntb_rawdev.c | 488 ++
drivers/raw/ntb_rawdev/ntb_rawdev.h | 164 ++
.../ntb_rawdev/rte_pmd_ntb_rawdev_version.map | 4 +
mk/rte.app.mk | 1 +
9 files changed, 698 insertions(+), 1 deletion(-)
create mode 100644 drivers/raw/ntb_rawdev/Makefile
create mode 100644 drivers/raw/ntb_rawdev/meson.build
create mode 100644 drivers/raw/ntb_rawdev/ntb_rawdev.c
create mode 100644 drivers/raw/ntb_rawdev/ntb_rawdev.h
create mode 100644 drivers/raw/ntb_rawdev/rte_pmd_ntb_rawdev_version.map
diff --git a/config/common_base b/config/common_base
index 5cb73a7a8..d18dae7b0 100644
--- a/config/common_base
+++ b/config/common_base
@@ -747,6 +747,11 @@ CONFIG_RTE_LIBRTE_PMD_DPAA2_QDMA_RAWDEV=n
#
CONFIG_RTE_LIBRTE_PMD_IFPGA_RAWDEV=y
+#
+# Compile PMD for NTB raw device
+#
+CONFIG_RTE_LIBRTE_PMD_NTB_RAWDEV=y
+
#
# Compile librte_ring
#
diff --git a/drivers/raw/Makefile b/drivers/raw/Makefile
index 8e29b4a56..efe61f451 100644
--- a/drivers/raw/Makefile
+++ b/drivers/raw/Makefile
@@ -10,5 +10,6 @@ DIRS-$(CONFIG_RTE_LIBRTE_PMD_DPAA2_CMDIF_RAWDEV) +=
dpaa2_cmdif
DIRS-$(CONFIG_RTE_LIBRTE_PMD_DPAA2_QDMA_RAWDEV) += dpaa2_qdma
endif
DIRS-$(CONFIG_RTE_LIBRTE_PMD_IFPGA_RAWDEV) += ifpga_rawdev
+DIRS-$(CONFIG_RTE_LIBRTE_PMD_NTB_RAWDEV) += ntb_rawdev
include $(RTE_SDK)/mk/rte.subdir.mk
diff --git a/drivers/raw/meson.build b/drivers/raw/meson.build
index a61cdccef..6abf659d0 100644
--- a/drivers/raw/meson.build
+++ b/drivers/raw/meson.build
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright 2018 NXP
-drivers = ['skeleton_rawdev', 'dpaa2_cmdif', 'dpaa2_qdma', 'ifpga_rawdev']
+drivers = ['skeleton_rawdev', 'dpaa2_cmdif', 'dpaa2_qdma', 'ifpga_rawdev',
'ntb_rawdev']
std_deps = ['rawdev']
config_flag_fmt = 'RTE_LIBRTE_PMD_@0@_RAWDEV'
driver_name_fmt = 'rte_pmd_@0@'
diff --git a/drivers/raw/ntb_rawdev/Makefile b/drivers/raw/ntb_rawdev/Makefile
new file mode 100644
index 0..da87a4610
--- /dev/null
+++ b/drivers/raw/ntb_rawdev/Makefile
@@ -0,0 +1,27 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(c) 2019 Intel Corporation
+
+include $(RTE_SDK)/mk/rte.vars.mk
+
+#
+# library name
+#
+LIB = librte_pmd_ntb_rawdev.a
+
+CFLAGS += -DALLOW_EXPERIMENTAL_API
+CFLAGS += -O3
+CFLAGS += $(WERROR_FLAGS)
+LDLIBS += -lrte_eal -lrte_mbuf -lrte_mempool
+LDLIBS += -lrte_pci -lrte_bus_pci
+LDLIBS += -lrte_rawdev
+
+EXPORT_MAP := rte_pmd_ntb_rawdev_version.map
+
+LIBABIVER := 1
+
+#
+# all source are stored in SRCS-y
+#
+SRCS-$(CONFIG_RTE_LIBRTE_PMD_NTB_RAWDEV) += ntb_rawdev.c
+
+include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/drivers/raw/ntb_rawdev/meson.build
b/drivers/raw/ntb_rawdev/meson.build
new file mode 100644
index 0..ca905049d
--- /dev/null
+++ b/drivers/raw/ntb_rawdev/meson.build
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(c) 2019 Intel Corporation.
+
+deps += ['rawdev', 'mbuf', 'mempool',
+'pci', 'bus_pci']
+sources = files('ntb_rawdev.c')
+allow_experimental_apis = true
diff --git a/drivers/raw/ntb_rawdev/ntb_rawdev.c
b/drivers/raw/ntb_rawdev/ntb_rawdev.c
new file mode 100644
index 0..07ad81d44
--- /dev/null
+++ b/drivers/raw/ntb_rawdev/ntb_rawdev.c
@@ -0,0 +1,488 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2019 Intel Corporation.
+ */
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "ntb_rawdev.h"
+
+int ntb_logtype;
+
+static const struct rte_pci_id pci_id_ntb_map[] = {
+ { .vendor_id = 0, /* sentinel */ },
+};
+
+static void
+ntb_queue_conf_get(struct rte_rawdev *dev __rte_unused,
+ uint16_t queue_id __rte_unused,
+ rte_rawdev_obj_t queue_conf __rte_unused)
+{
+}
+
+static int
+ntb_queue_setup(struct rte_rawdev *dev __rte_unused,
+ uint16_t queue_id __rte_unused,
+ rte_rawdev_obj_t queue_conf __rte_unused)
+{
+ return 0;
+}
+
+static int
+ntb_queue_release(struct rte_rawdev *dev __rte_unused,
+ uint16_t queue_id __rte_unused)
+{
+ return 0;
+}
+
+static uint16_t
+ntb_queue_count(struct rte_rawdev *dev)
+{
+ struct ntb_hw *hw = dev->dev_private;
+ return hw->queue_pairs;
+}
+
+static int
+ntb_enqueue_bufs(struct rte_rawdev *dev,
+struct rte_rawdev_buf **buffers,
+unsigned int count,
+rte_rawdev_obj_t context)
+{
+ RTE
[dpdk-dev] [PATCH v7 0/6] rawdev driver for ntb
This patch set adds support for Intel NTB device with Skylake platform. It is a raw device for allowing two hosts to communicate with each other and access the peer memory. This patch set also provides a simple example to transmit a file between two hosts. But since there is no FIFO here, only support file which is no more than 4M. And will add FIFO in the future. v7: * Fixed a typo. * Generic spad registers to be spad_user and the specific spad is * defined by the specific hw. * Refined the codes by replacing with lib functions such as rte_read32. * Rebased the codes to the newest dpdk-next-net-intel branch. v6: * Fixed a typo. v5: * Actual v4. v4 patchset is the same as v3. v4: * Fix compile issues of comparison of array with null pointer. v3: * Fixed compilation issues with target i686. * Renamed communication devices to misc devices in usertool. * Rebased to the newest dpdk-next-net-intel branch. v2: * Replaced ! with NULL check for pointers. * Added ntb_ops valid check before use it. * Replaced RTE_MEMZONE_1GB with RTE_MEMZONE_IOVA_CONTIG in case users do not use 1G hugepage. * Added a timeout for dev_stop handshake in case that the peer stopped abnormally such as crashed while debugging. * Updated docs especailly about how to setup BIOS for skylake. * Fixed not return issue and not free issue in example. * Renamed ntb_devices to communication_devices to be more generic in usertools. * Polish the codes and docs. Xiaoyun Li (6): raw/ntb: introduce ntb rawdev driver raw/ntb: add intel ntb support raw/ntb: add handshake process examples/ntb: enable an example for ntb usertools/dpdk-devbind.py: add support for ntb doc: update docs for ntb driver MAINTAINERS | 8 + config/common_base| 5 + doc/guides/rawdevs/index.rst | 1 + doc/guides/rawdevs/ntb_rawdev.rst | 41 + doc/guides/rel_notes/release_19_08.rst| 15 + doc/guides/sample_app_ug/index.rst| 1 + doc/guides/sample_app_ug/ntb.rst | 47 + drivers/raw/Makefile | 1 + drivers/raw/meson.build | 2 +- drivers/raw/ntb_rawdev/Makefile | 28 + drivers/raw/ntb_rawdev/meson.build| 8 + drivers/raw/ntb_rawdev/ntb_hw_intel.c | 369 drivers/raw/ntb_rawdev/ntb_hw_intel.h | 86 ++ drivers/raw/ntb_rawdev/ntb_rawdev.c | 839 ++ drivers/raw/ntb_rawdev/ntb_rawdev.h | 164 .../ntb_rawdev/rte_pmd_ntb_rawdev_version.map | 4 + examples/Makefile | 1 + examples/meson.build | 2 +- examples/ntb/Makefile | 68 ++ examples/ntb/meson.build | 16 + examples/ntb/ntb_fwd.c| 377 mk/rte.app.mk | 1 + usertools/dpdk-devbind.py | 9 + 23 files changed, 2091 insertions(+), 2 deletions(-) create mode 100644 doc/guides/rawdevs/ntb_rawdev.rst create mode 100644 doc/guides/sample_app_ug/ntb.rst create mode 100644 drivers/raw/ntb_rawdev/Makefile create mode 100644 drivers/raw/ntb_rawdev/meson.build create mode 100644 drivers/raw/ntb_rawdev/ntb_hw_intel.c create mode 100644 drivers/raw/ntb_rawdev/ntb_hw_intel.h create mode 100644 drivers/raw/ntb_rawdev/ntb_rawdev.c create mode 100644 drivers/raw/ntb_rawdev/ntb_rawdev.h create mode 100644 drivers/raw/ntb_rawdev/rte_pmd_ntb_rawdev_version.map create mode 100644 examples/ntb/Makefile create mode 100644 examples/ntb/meson.build create mode 100644 examples/ntb/ntb_fwd.c -- 2.17.1
[dpdk-dev] [PATCH v7 2/6] raw/ntb: add intel ntb support
Add in the list of registers for the device. And enable ntb device
ops for intel skylake platform.
Signed-off-by: Xiaoyun Li
---
drivers/raw/ntb_rawdev/Makefile | 1 +
drivers/raw/ntb_rawdev/meson.build| 3 +-
drivers/raw/ntb_rawdev/ntb_hw_intel.c | 369 ++
drivers/raw/ntb_rawdev/ntb_hw_intel.h | 86 ++
drivers/raw/ntb_rawdev/ntb_rawdev.c | 5 +
5 files changed, 463 insertions(+), 1 deletion(-)
create mode 100644 drivers/raw/ntb_rawdev/ntb_hw_intel.c
create mode 100644 drivers/raw/ntb_rawdev/ntb_hw_intel.h
diff --git a/drivers/raw/ntb_rawdev/Makefile b/drivers/raw/ntb_rawdev/Makefile
index da87a4610..74c045a86 100644
--- a/drivers/raw/ntb_rawdev/Makefile
+++ b/drivers/raw/ntb_rawdev/Makefile
@@ -23,5 +23,6 @@ LIBABIVER := 1
# all source are stored in SRCS-y
#
SRCS-$(CONFIG_RTE_LIBRTE_PMD_NTB_RAWDEV) += ntb_rawdev.c
+SRCS-$(CONFIG_RTE_LIBRTE_PMD_NTB_RAWDEV) += ntb_hw_intel.c
include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/drivers/raw/ntb_rawdev/meson.build
b/drivers/raw/ntb_rawdev/meson.build
index ca905049d..c696f60b3 100644
--- a/drivers/raw/ntb_rawdev/meson.build
+++ b/drivers/raw/ntb_rawdev/meson.build
@@ -3,5 +3,6 @@
deps += ['rawdev', 'mbuf', 'mempool',
'pci', 'bus_pci']
-sources = files('ntb_rawdev.c')
+sources = files('ntb_rawdev.c',
+'ntb_hw_intel.c')
allow_experimental_apis = true
diff --git a/drivers/raw/ntb_rawdev/ntb_hw_intel.c
b/drivers/raw/ntb_rawdev/ntb_hw_intel.c
new file mode 100644
index 0..1185cd189
--- /dev/null
+++ b/drivers/raw/ntb_rawdev/ntb_hw_intel.c
@@ -0,0 +1,369 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2019 Intel Corporation.
+ */
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "ntb_rawdev.h"
+#include "ntb_hw_intel.h"
+
+enum xeon_ntb_bar {
+ XEON_NTB_BAR23 = 2,
+ XEON_NTB_BAR45 = 4,
+};
+
+static enum xeon_ntb_bar intel_ntb_bar[] = {
+ XEON_NTB_BAR23,
+ XEON_NTB_BAR45,
+};
+
+static int
+intel_ntb_dev_init(struct rte_rawdev *dev)
+{
+ struct ntb_hw *hw = dev->dev_private;
+ uint8_t reg_val, bar;
+ int ret, i;
+
+ if (hw == NULL) {
+ NTB_LOG(ERR, "Invalid device.");
+ return -EINVAL;
+ }
+
+ ret = rte_pci_read_config(hw->pci_dev, ®_val,
+ sizeof(reg_val), XEON_PPD_OFFSET);
+ if (ret < 0) {
+ NTB_LOG(ERR, "Cannot get NTB PPD (PCIe port definition).");
+ return -EIO;
+ }
+
+ /* Check connection topo type. Only support B2B. */
+ switch (reg_val & XEON_PPD_CONN_MASK) {
+ case XEON_PPD_CONN_B2B:
+ NTB_LOG(INFO, "Topo B2B (back to back) is using.");
+ break;
+ case XEON_PPD_CONN_TRANSPARENT:
+ case XEON_PPD_CONN_RP:
+ NTB_LOG(ERR, "Not supported conn topo. Please use B2B.");
+ return -EINVAL;
+ }
+
+ /* Check device type. */
+ if (reg_val & XEON_PPD_DEV_DSD) {
+ NTB_LOG(INFO, "DSD, Downstream Device.");
+ hw->topo = NTB_TOPO_B2B_DSD;
+ } else {
+ NTB_LOG(INFO, "USD, Upstream device.");
+ hw->topo = NTB_TOPO_B2B_USD;
+ }
+
+ /* Check if bar4 is split. Do not support split bar. */
+ if (reg_val & XEON_PPD_SPLIT_BAR_MASK) {
+ NTB_LOG(ERR, "Do not support split bar.");
+ return -EINVAL;
+ }
+
+ hw->hw_addr = (char *)hw->pci_dev->mem_resource[0].addr;
+
+ hw->mw_cnt = XEON_MW_COUNT;
+ hw->db_cnt = XEON_DB_COUNT;
+ hw->spad_cnt = XEON_SPAD_COUNT;
+
+ hw->mw_size = rte_zmalloc("uint64_t",
+ hw->mw_cnt * sizeof(uint64_t), 0);
+ for (i = 0; i < hw->mw_cnt; i++) {
+ bar = intel_ntb_bar[i];
+ hw->mw_size[i] = hw->pci_dev->mem_resource[bar].len;
+ }
+
+ /* Reserve the last 2 spad registers for users. */
+ for (i = 0; i < NTB_SPAD_USER_MAX_NUM; i++) {
+ hw->spad_user_list[i] = hw->spad_cnt;
+ }
+ hw->spad_user_list[0] = hw->spad_cnt - 2;
+ hw->spad_user_list[1] = hw->spad_cnt - 1;
+
+ return 0;
+}
+
+static void *
+intel_ntb_get_peer_mw_addr(struct rte_rawdev *dev, int mw_idx)
+{
+ struct ntb_hw *hw = dev->dev_private;
+ uint8_t bar;
+
+ if (hw == NULL) {
+ NTB_LOG(ERR, "Invalid device.");
+ return 0;
+ }
+
+ if (mw_idx < 0 || mw_idx >= hw->mw_cnt) {
+ NTB_LOG(ERR, "Invalid memory window index (0 - %u).",
+ hw->mw_cnt - 1);
+ return 0;
+ }
+
+ bar = intel_ntb_bar[mw_idx];
+
+ return hw->pci_dev->mem_resource[bar].addr;
+}
+
+static int
+intel_ntb_mw_set_trans(struct rte_rawdev *dev, int mw_idx,
+ uint64_t addr, uint64_t size)
+{
+ struct ntb_hw *hw
[dpdk-dev] [PATCH v7 3/6] raw/ntb: add handshake process
Add handshake process using doorbell so that two hosts can
communicate to start and stop.
Signed-off-by: Xiaoyun Li
---
drivers/raw/ntb_rawdev/ntb_rawdev.c | 336 +++-
1 file changed, 335 insertions(+), 1 deletion(-)
diff --git a/drivers/raw/ntb_rawdev/ntb_rawdev.c
b/drivers/raw/ntb_rawdev/ntb_rawdev.c
index 113ef0169..e4ae95a01 100644
--- a/drivers/raw/ntb_rawdev/ntb_rawdev.c
+++ b/drivers/raw/ntb_rawdev/ntb_rawdev.c
@@ -28,6 +28,183 @@ static const struct rte_pci_id pci_id_ntb_map[] = {
{ .vendor_id = 0, /* sentinel */ },
};
+static int
+ntb_set_mw(struct rte_rawdev *dev, int mw_idx, uint64_t mw_size)
+{
+ struct ntb_hw *hw = dev->dev_private;
+ char mw_name[RTE_MEMZONE_NAMESIZE];
+ const struct rte_memzone *mz;
+ int ret = 0;
+
+ if (hw->ntb_ops->mw_set_trans == NULL) {
+ NTB_LOG(ERR, "Not supported to set mw.");
+ return -ENOTSUP;
+ }
+
+ snprintf(mw_name, sizeof(mw_name), "ntb_%d_mw_%d",
+dev->dev_id, mw_idx);
+
+ mz = rte_memzone_lookup(mw_name);
+ if (mz)
+ return 0;
+
+ /**
+* Hardware requires that mapped memory base address should be
+* aligned with EMBARSZ and needs continuous memzone.
+*/
+ mz = rte_memzone_reserve_aligned(mw_name, mw_size, dev->socket_id,
+ RTE_MEMZONE_IOVA_CONTIG, hw->mw_size[mw_idx]);
+ if (!mz) {
+ NTB_LOG(ERR, "Cannot allocate aligned memzone.");
+ return -EIO;
+ }
+ hw->mz[mw_idx] = mz;
+
+ ret = (*hw->ntb_ops->mw_set_trans)(dev, mw_idx, mz->iova, mw_size);
+ if (ret) {
+ NTB_LOG(ERR, "Cannot set mw translation.");
+ return ret;
+ }
+
+ return ret;
+}
+
+static void
+ntb_link_cleanup(struct rte_rawdev *dev)
+{
+ struct ntb_hw *hw = dev->dev_private;
+ int status, i;
+
+ if (hw->ntb_ops->spad_write == NULL ||
+ hw->ntb_ops->mw_set_trans == NULL) {
+ NTB_LOG(ERR, "Not supported to clean up link.");
+ return;
+ }
+
+ /* Clean spad registers. */
+ for (i = 0; i < hw->spad_cnt; i++) {
+ status = (*hw->ntb_ops->spad_write)(dev, i, 0, 0);
+ if (status)
+ NTB_LOG(ERR, "Failed to clean local spad.");
+ }
+
+ /* Clear mw so that peer cannot access local memory.*/
+ for (i = 0; i < hw->mw_cnt; i++) {
+ status = (*hw->ntb_ops->mw_set_trans)(dev, i, 0, 0);
+ if (status)
+ NTB_LOG(ERR, "Failed to clean mw.");
+ }
+}
+
+static void
+ntb_dev_intr_handler(void *param)
+{
+ struct rte_rawdev *dev = (struct rte_rawdev *)param;
+ struct ntb_hw *hw = dev->dev_private;
+ uint32_t mw_size_h, mw_size_l;
+ uint64_t db_bits = 0;
+ int i = 0;
+
+ if (hw->ntb_ops->db_read == NULL ||
+ hw->ntb_ops->db_clear == NULL ||
+ hw->ntb_ops->peer_db_set == NULL) {
+ NTB_LOG(ERR, "Doorbell is not supported.");
+ return;
+ }
+
+ db_bits = (*hw->ntb_ops->db_read)(dev);
+ if (!db_bits)
+ NTB_LOG(ERR, "No doorbells");
+
+ /* Doorbell 0 is for peer device ready. */
+ if (db_bits & 1) {
+ NTB_LOG(DEBUG, "DB0: Peer device is up.");
+ /* Clear received doorbell. */
+ (*hw->ntb_ops->db_clear)(dev, 1);
+
+ /**
+* Peer dev is already up. All mw settings are already done.
+* Skip them.
+*/
+ if (hw->peer_dev_up)
+ return;
+
+ if (hw->ntb_ops->spad_read == NULL ||
+ hw->ntb_ops->spad_write == NULL) {
+ NTB_LOG(ERR, "Scratchpad is not supported.");
+ return;
+ }
+
+ hw->peer_mw_cnt = (*hw->ntb_ops->spad_read)
+ (dev, SPAD_NUM_MWS, 0);
+ hw->peer_mw_size = rte_zmalloc("uint64_t",
+ hw->peer_mw_cnt * sizeof(uint64_t), 0);
+ for (i = 0; i < hw->mw_cnt; i++) {
+ mw_size_h = (*hw->ntb_ops->spad_read)
+ (dev, SPAD_MW0_SZ_H + 2 * i, 0);
+ mw_size_l = (*hw->ntb_ops->spad_read)
+ (dev, SPAD_MW0_SZ_L + 2 * i, 0);
+ hw->peer_mw_size[i] = ((uint64_t)mw_size_h << 32) |
+ mw_size_l;
+ NTB_LOG(DEBUG, "Peer %u mw size: 0x%"PRIx64"", i,
+ hw->peer_mw_size[i]);
+ }
+
+ hw->peer_dev_up = 1;
+
+ /**
+* Handshake with peer. Spad_write only works when both
+* devices are up. So w
[dpdk-dev] [PATCH v7 4/6] examples/ntb: enable an example for ntb
Enable an example for rawdev ntb. Support interactive mode to send
file on one host and receive file from another host. The command line
would be 'send [filepath]' and 'receive [filepath]'.
But since the FIFO is not enabled right now, use rte_memcpy as the enqueue
and dequeue functions and only support transmitting file no more than 4M.
Signed-off-by: Xiaoyun Li
---
drivers/raw/ntb_rawdev/ntb_rawdev.c | 28 ++-
examples/Makefile | 1 +
examples/meson.build| 2 +-
examples/ntb/Makefile | 68 +
examples/ntb/meson.build| 16 ++
examples/ntb/ntb_fwd.c | 377
6 files changed, 483 insertions(+), 9 deletions(-)
create mode 100644 examples/ntb/Makefile
create mode 100644 examples/ntb/meson.build
create mode 100644 examples/ntb/ntb_fwd.c
diff --git a/drivers/raw/ntb_rawdev/ntb_rawdev.c
b/drivers/raw/ntb_rawdev/ntb_rawdev.c
index e4ae95a01..145c77bd7 100644
--- a/drivers/raw/ntb_rawdev/ntb_rawdev.c
+++ b/drivers/raw/ntb_rawdev/ntb_rawdev.c
@@ -240,11 +240,19 @@ ntb_enqueue_bufs(struct rte_rawdev *dev,
unsigned int count,
rte_rawdev_obj_t context)
{
- RTE_SET_USED(dev);
- RTE_SET_USED(buffers);
- RTE_SET_USED(count);
- RTE_SET_USED(context);
+ /* Not FIFO right now. Just for testing memory write. */
+ struct ntb_hw *hw = dev->dev_private;
+ unsigned int i;
+ void *bar_addr;
+ size_t size;
+
+ if (hw->ntb_ops->get_peer_mw_addr == NULL)
+ return -ENOTSUP;
+ bar_addr = (*hw->ntb_ops->get_peer_mw_addr)(dev, 0);
+ size = (size_t)context;
+ for (i = 0; i < count; i++)
+ rte_memcpy(bar_addr, buffers[i]->buf_addr, size);
return 0;
}
@@ -254,11 +262,15 @@ ntb_dequeue_bufs(struct rte_rawdev *dev,
unsigned int count,
rte_rawdev_obj_t context)
{
- RTE_SET_USED(dev);
- RTE_SET_USED(buffers);
- RTE_SET_USED(count);
- RTE_SET_USED(context);
+ /* Not FIFO. Just for testing memory read. */
+ struct ntb_hw *hw = dev->dev_private;
+ unsigned int i;
+ size_t size;
+
+ size = (size_t)context;
+ for (i = 0; i < count; i++)
+ rte_memcpy(buffers[i]->buf_addr, hw->mz[i]->addr, size);
return 0;
}
diff --git a/examples/Makefile b/examples/Makefile
index 7562424d9..de11dd487 100644
--- a/examples/Makefile
+++ b/examples/Makefile
@@ -53,6 +53,7 @@ DIRS-y += link_status_interrupt
DIRS-$(CONFIG_RTE_LIBRTE_LPM) += load_balancer
DIRS-y += multi_process
DIRS-y += netmap_compat/bridge
+DIRS-y += ntb
DIRS-$(CONFIG_RTE_LIBRTE_REORDER) += packet_ordering
ifeq ($(CONFIG_RTE_ARCH_X86_64),y)
DIRS-y += performance-thread
diff --git a/examples/meson.build b/examples/meson.build
index c695d52c9..2a4a084af 100644
--- a/examples/meson.build
+++ b/examples/meson.build
@@ -30,7 +30,7 @@ all_examples = [
'multi_process/hotplug_mp',
'multi_process/simple_mp',
'multi_process/symmetric_mp',
- 'netmap_compat', 'packet_ordering',
+ 'netmap_compat', 'ntb', 'packet_ordering',
'performance-thread', 'ptpclient',
'qos_meter', 'qos_sched',
'quota_watermark', 'rxtx_callbacks',
diff --git a/examples/ntb/Makefile b/examples/ntb/Makefile
new file mode 100644
index 0..5ddd9b95f
--- /dev/null
+++ b/examples/ntb/Makefile
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(c) 2019 Intel Corporation
+
+# binary name
+APP = ntb_fwd
+
+# all source are stored in SRCS-y
+SRCS-y := ntb_fwd.c
+
+# Build using pkg-config variables if possible
+$(shell pkg-config --exists libdpdk)
+ifeq ($(.SHELLSTATUS),0)
+
+all: shared
+.PHONY: shared static
+shared: build/$(APP)-shared
+ ln -sf $(APP)-shared build/$(APP)
+static: build/$(APP)-static
+ ln -sf $(APP)-static build/$(APP)
+
+CFLAGS += -D_FILE_OFFSET_BITS=64
+LDFLAGS += -pthread
+
+PC_FILE := $(shell pkg-config --path libdpdk)
+CFLAGS += -O3 $(shell pkg-config --cflags libdpdk)
+LDFLAGS_SHARED = $(shell pkg-config --libs libdpdk)
+LDFLAGS_STATIC = -Wl,-Bstatic $(shell pkg-config --static --libs libdpdk)
+
+build/$(APP)-shared: $(SRCS-y) Makefile $(PC_FILE) | build
+ $(CC) $(CFLAGS) $(SRCS-y) -o $@ $(LDFLAGS) $(LDFLAGS_SHARED)
+
+build/$(APP)-static: $(SRCS-y) Makefile $(PC_FILE) | build
+ $(CC) $(CFLAGS) $(SRCS-y) -o $@ $(LDFLAGS) $(LDFLAGS_STATIC)
+
+build:
+ @mkdir -p $@
+
+.PHONY: clean
+clean:
+ rm -f build/$(APP) build/$(APP)-static build/$(APP)-shared
+ rmdir --ignore-fail-on-non-empty build
+
+else # Build using legacy build system
+
+ifeq ($(RTE_SDK),)
+$(error "Please define RTE_SDK environment variable")
+endif
+
+# Default target, can be overridden by command line or environment
+RTE_TARGET ?= x86_64-native-linuxapp-gcc
+
+include $(RTE_SDK)/mk/rte.vars.mk
+
+ifneq ($(CONFIG_RTE_EXEC_ENV_LINUXAPP),y)
+$(info T
[dpdk-dev] [PATCH v7 5/6] usertools/dpdk-devbind.py: add support for ntb
In order to allow binding/unbinding of devices for use by the
ntb_rawdev, we need to update the devbind script to add a new class
of device, and add device ids for the specific HW instances. And
only support skx platform right now.
Signed-off-by: Xiaoyun Li
---
usertools/dpdk-devbind.py | 9 +
1 file changed, 9 insertions(+)
diff --git a/usertools/dpdk-devbind.py b/usertools/dpdk-devbind.py
index 9e79f0d28..6e6f64bd3 100755
--- a/usertools/dpdk-devbind.py
+++ b/usertools/dpdk-devbind.py
@@ -36,11 +36,15 @@
octeontx2_npa = {'Class': '08', 'Vendor': '177d', 'Device': 'a0fb,a0fc',
'SVendor': None, 'SDevice': None}
+intel_ntb_skx = {'Class': '06', 'Vendor': '8086', 'Device': '201c',
+ 'SVendor': None, 'SDevice': None}
+
network_devices = [network_class, cavium_pkx, avp_vnic, ifpga_class]
crypto_devices = [encryption_class, intel_processor_class]
eventdev_devices = [cavium_sso, cavium_tim, octeontx2_sso]
mempool_devices = [cavium_fpa, octeontx2_npa]
compress_devices = [cavium_zip]
+misc_devices = [intel_ntb_skx]
# global dict ethernet devices present. Dictionary indexed by PCI address.
# Each device within this is itself a dictionary of device properties
@@ -595,6 +599,9 @@ def show_status():
if status_dev == "compress" or status_dev == "all":
show_device_status(compress_devices , "Compress")
+if status_dev == "misc" or status_dev == "all":
+show_device_status(misc_devices , "Misc")
+
def parse_args():
'''Parses the command-line arguments given by the user and takes the
@@ -670,6 +677,7 @@ def do_arg_actions():
get_device_details(eventdev_devices)
get_device_details(mempool_devices)
get_device_details(compress_devices)
+get_device_details(misc_devices)
show_status()
@@ -690,6 +698,7 @@ def main():
get_device_details(eventdev_devices)
get_device_details(mempool_devices)
get_device_details(compress_devices)
+get_device_details(misc_devices)
do_arg_actions()
if __name__ == "__main__":
--
2.17.1
[dpdk-dev] [PATCH v7 6/6] doc: update docs for ntb driver
Update related documents for ntb pmd and example. Signed-off-by: Xiaoyun Li --- MAINTAINERS| 8 + doc/guides/rawdevs/index.rst | 1 + doc/guides/rawdevs/ntb_rawdev.rst | 41 ++ doc/guides/rel_notes/release_19_08.rst | 15 doc/guides/sample_app_ug/index.rst | 1 + doc/guides/sample_app_ug/ntb.rst | 47 ++ 6 files changed, 113 insertions(+) create mode 100644 doc/guides/rawdevs/ntb_rawdev.rst create mode 100644 doc/guides/sample_app_ug/ntb.rst diff --git a/MAINTAINERS b/MAINTAINERS index fdc083db9..8c919484d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1057,6 +1057,10 @@ M: Nipun Gupta F: drivers/raw/dpaa2_cmdif/ F: doc/guides/rawdevs/dpaa2_cmdif.rst +NTB Rawdev +M: Xiaoyun Li +F: drivers/raw/ntb_rawdev/ +F: doc/guides/rawdevs/ntb_rawdev.rst Packet processing - @@ -1433,3 +1437,7 @@ F: examples/tep_termination/ F: examples/vmdq/ F: examples/vmdq_dcb/ F: doc/guides/sample_app_ug/vmdq_dcb_forwarding.rst + +M: Xiaoyun Li +F: examples/ntb/ +F: doc/guides/sample_app_ug/ntb.rst diff --git a/doc/guides/rawdevs/index.rst b/doc/guides/rawdevs/index.rst index 7c3bd9586..cf6fcb06b 100644 --- a/doc/guides/rawdevs/index.rst +++ b/doc/guides/rawdevs/index.rst @@ -14,3 +14,4 @@ application through rawdev API. dpaa2_cmdif dpaa2_qdma ifpga_rawdev +ntb_rawdev diff --git a/doc/guides/rawdevs/ntb_rawdev.rst b/doc/guides/rawdevs/ntb_rawdev.rst new file mode 100644 index 0..429e2af3e --- /dev/null +++ b/doc/guides/rawdevs/ntb_rawdev.rst @@ -0,0 +1,41 @@ +.. SPDX-License-Identifier: BSD-3-Clause +Copyright(c) 2018 Intel Corporation. + +NTB Rawdev Driver += + +The ``ntb`` rawdev driver provides a non-transparent bridge between two +separate hosts so that they can communicate with each other. Thus, many +user cases can benefit from this, such as fault tolerance and visual +acceleration. + +This PMD allows two hosts to handshake for device start and stop, memory +allocation for the peer to access and read/write allocated memory from peer. +Also, the PMD allows to use doorbell registers to notify the peer and share +some information by using scratchpad registers. + +But the PMD hasn't implemented FIFO. The FIFO will come in 19.11 release. +And this PMD only supports intel skylake platform. + +BIOS setting on skylake platform + + +Intel non-transparent bridge needs special BIOS setting. Since the PMD only +supports intel skylake platform, introduce BIOS setting here. The referencce +is https://www.intel.com/content/dam/support/us/en/documents/server-products/Intel_Xeon_Processor_Scalable_Family_BIOS_User_Guide.pdf + +- Set the needed PCIe port as NTB to NTB mode on both hosts. +- Enable NTB bars and set bar size of bar 23 and bar 45 as 12-29 (2K-512M) + on both hosts. Note that bar size on both hosts should be the same. +- Disable split bars for both hosts. +- Set crosslink control override as DSD/USP on one host, USD/DSP on + another host. +- Disable PCIe PII SSC (Spread Spectrum Clocking) for both hosts. This + is a hardware requirement. + +Build options +- + +- ``CONFIG_RTE_LIBRTE_IFPGA_RAWDEV`` (default ``y``) + + Toggle compilation of the ``ntb_rawdev`` driver. diff --git a/doc/guides/rel_notes/release_19_08.rst b/doc/guides/rel_notes/release_19_08.rst index 563999d57..3a35ffbd7 100644 --- a/doc/guides/rel_notes/release_19_08.rst +++ b/doc/guides/rel_notes/release_19_08.rst @@ -94,6 +94,21 @@ New Features * Enabled Tx outer/inner L3/L4 checksum offload. +* **Introduced NTB PMD.** + + The PMD provided a non-transparent bridge between two separate hosts so + that they can communicate with each other. Thus, many user cases can + benefit from this, such as fault tolerance and visual acceleration. + + This PMD implemented the following features: + * Handshake for device start and stop between two hosts. + * Memory allocation for the peer to access and read/write allocated +memory from peer. + * Use doorbell registers to notify the peer and share some information +by using scratchpad registers. + + But the PMD hasn't implemented FIFO. The FIFO will come in 19.11 release. + And this PMD only supports intel skylake platform. Removed Items - diff --git a/doc/guides/sample_app_ug/index.rst b/doc/guides/sample_app_ug/index.rst index 2945be08f..f23f8f59e 100644 --- a/doc/guides/sample_app_ug/index.rst +++ b/doc/guides/sample_app_ug/index.rst @@ -58,3 +58,4 @@ Sample Applications User Guides fips_validation ipsec_secgw bbdev_app +ntb diff --git a/doc/guides/sample_app_ug/ntb.rst b/doc/guides/sample_app_ug/ntb.rst new file mode 100644 index 0..079242175 --- /dev/null +++ b/doc/guides/sample_app_ug/ntb.rst @@ -0,0 +1,47 @@ +.. SPDX-License-Identifier: BSD-3-Clause +Copyright(c) 2019 Intel Corporation. + +NTB Sample Application
Re: [dpdk-dev] [PATCH 01/28] vhost: introduce vhost transport operations structure
On Wed, Jun 19, 2019 at 04:14:09PM -0400, Aaron Conole wrote:
> Nikos Dragazis writes:
>
> > This is the first of a series of patches, whose purpose is to add
> > support for the virtio-vhost-user transport. This is a vhost-user
> > transport implementation that is different from the default AF_UNIX
> > transport. It uses the virtio-vhost-user PCI device in order to tunnel
> > vhost-user protocol messages over virtio. This lets guests act as vhost
> > device backends for other guests.
> >
> > File descriptor passing is specific to the AF_UNIX vhost-user protocol
> > transport. In order to add support for additional transports, it is
> > necessary to extract transport-specific code from the main vhost-user
> > code.
> >
> > This patch introduces struct vhost_transport_ops and associates each
> > device with a transport. Core vhost-user code calls into
> > vhost_transport_ops to perform transport-specific operations.
> >
> > Notifying callfd is a transport-specific operation, so it belongs to
> > trans_af_unix.c.
> >
> > Several more patches follow this one to complete the task of moving
> > AF_UNIX transport code out of core vhost-user code.
> >
> > Signed-off-by: Nikos Dragazis
> > Signed-off-by: Stefan Hajnoczi
> > ---
>
> You'll need to also accommodate the meson build - probably with
> something like:
>
> diff --git a/lib/librte_vhost/meson.build b/lib/librte_vhost/meson.build
> index 3090bbe08..81b70683b 100644
> --- a/lib/librte_vhost/meson.build
> +++ b/lib/librte_vhost/meson.build
> @@ -14,6 +14,6 @@ allow_experimental_apis = true
> cflags += '-fno-strict-aliasing'
> sources = files('fd_man.c', 'iotlb.c', 'socket.c', 'vdpa.c',
> 'vhost.c', 'vhost_user.c',
> - 'virtio_net.c', 'vhost_crypto.c')
> + 'virtio_net.c', 'vhost_crypto.c', 'trans_af_unix.c')
> headers = files('rte_vhost.h', 'rte_vdpa.h', 'rte_vhost_crypto.h')
> deps += ['ethdev', 'cryptodev', 'hash', 'pci']
>
>
Yep, except I think we should try and keep the files in alphabetical order,
with only a couple of entries per line [so place trans_af_unix.c on a new
line with vdpa.c].
Re: [dpdk-dev] [PATCH v2 3/3] lib/lpm: remove unnecessary inline
Hi Vladimir,
> -Original Message-
> From: Medvedkin, Vladimir
> Sent: Wednesday, June 19, 2019 20:51
> To: Ruifeng Wang (Arm Technology China) ;
> bruce.richard...@intel.com
> Cc: dev@dpdk.org; Honnappa Nagarahalli
> ; Gavin Hu (Arm Technology China)
> ; nd
> Subject: Re: [PATCH v2 3/3] lib/lpm: remove unnecessary inline
>
> Hi Wang,
>
> 1. It is better to explicitly use __rte_noinline with this function because my
> gcc still inlines it even without the inline qualifier.
>
> 2. The same should be applied to _v20 functions.
>
> 3. Please try running the tests again and show the results.
For x86, I can do test with E5 platform that we have.
>
> 4. Make this patch the first in a series.
>
Thanks. Will come back with new patch set.
> On 19/06/2019 06:36, Ruifeng Wang wrote:
> > Tests showed that the 'inline' keyword caused performance drop on some
> > x86 platforms after the memory ordering patches applied.
> > By removing the 'inline' keyword, the performance was recovered as
> > before on x86 and no impact to arm64 platforms.
> >
> > Suggested-by: Medvedkin Vladimir
> > Signed-off-by: Ruifeng Wang
> > Reviewed-by: Gavin Hu
> > ---
> > v2: initail version to recover rte_lpm_add() performance
> >
> > lib/librte_lpm/rte_lpm.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/lib/librte_lpm/rte_lpm.c b/lib/librte_lpm/rte_lpm.c index
> > 0addff5d4..c97b602e6 100644
> > --- a/lib/librte_lpm/rte_lpm.c
> > +++ b/lib/librte_lpm/rte_lpm.c
> > @@ -778,7 +778,7 @@ add_depth_small_v20(struct rte_lpm_v20 *lpm,
> uint32_t ip, uint8_t depth,
> > return 0;
> > }
> >
> > -static inline int32_t
> > +static int32_t
> > add_depth_small_v1604(struct rte_lpm *lpm, uint32_t ip, uint8_t depth,
> > uint32_t next_hop)
> > {
> > @@ -975,7 +975,7 @@ add_depth_big_v20(struct rte_lpm_v20 *lpm,
> uint32_t ip_masked, uint8_t depth,
> > return 0;
> > }
> >
> > -static inline int32_t
> > +static int32_t
> > add_depth_big_v1604(struct rte_lpm *lpm, uint32_t ip_masked, uint8_t
> depth,
> > uint32_t next_hop)
> > {
>
> --
> Regards,
> Vladimir
Re: [dpdk-dev] [PATCH v4] eal: rename state values in rte_lcore_state
On Wed, Jun 19, 2019 at 9:24 PM Stephen Hemminger < step...@networkplumber.org> wrote: > C language does not really treat enum's as first class symbols. > The values in an enum live in a global namespace. That means if > DPDK defines "RUNNING" it can't be used by another enum in an > application using DPDK. > > To solve this add a prefix "RTE_LCORE_" to the enum values, and > make them grammatically consistent. > > Also, simplify the inline thread_is_running() which is copied > in softnic and ip_pipeline. > > Signed-off-by: Stephen Hemminger > --- > v4 - rebase (after lcore changes),fix FreeBSD typo > > Did an extra pass, you missed the windows eal and the api descriptions: https://github.com/david-marchand/dpdk/commit/0084114455a82f90b783bdf1659a4af6f76c89f2 My only objection to this patch is that we are breaking a public API by removing those enums. We need to maintain those and send a deprecation notice for their future removal. -- David Marchand
Re: [dpdk-dev] [PATCH 00/28] vhost: add virtio-vhost-user transport
On 19.06.2019 18:14, Nikos Dragazis wrote: > Hi everyone, Hi. I didn't look at the code, just a few comments inline. > > this patch series introduces the concept of the virtio-vhost-user > transport. This is actually a revised version of an earlier RFC > implementation that has been proposed by Stefan Hajnoczi [1]. Though > this is a great feature, it seems to have been stalled, so I’d like to > restart the conversation on this and hopefully get it merged with your > help. Let me give you an overview. > > The virtio-vhost-user transport is a vhost-user transport implementation > that is based on the virtio-vhost-user device. Its key difference with > the existing transport is that it allows deploying vhost-user targets > inside dedicated Storage Appliance VMs instead of host user space. In > other words, it allows having guests that act as vhost-user backends for > other guests. > > The virtio-vhost-user device implements the vhost-user control plane > (master-slave communication) as follows: > > 1. it parses the vhost-user messages from the vhost-user unix domain >socket and forwards them to the slave guest through virtqueues > > 2. it maps the vhost memory regions in QEMU’s process address space and >exposes them to the slave guest as a RAM-backed PCI MMIO region > > 3. it hooks up doorbells to the callfds. The slave guest can use these >doorbells to interrupt the master guest driver > > The device code has not yet been merged into upstream QEMU, but this is > definitely the end goal. The current state is that we are awaiting for > the approval of the virtio spec. > > I have Cced Darek from the SPDK community who has helped me a lot by > reviewing this series. Note that any device type could be implemented > over this new transport. So, adding the virtio-vhost-user transport in > DPDK would allow using it from SPDK as well. > > Getting into the code internals, this patch series makes the following > changes: > > 1. introduce a generic interface for the transport-specific operations. >Each of the two available transports, the pre-existing AF_UNIX >transport and the virtio-vhost-user transport, is going to implement >this interface. The AF_UNIX-specific code has been extracted from the >core vhost-user code and is now part of the AF_UNIX transport >implementation in trans_af_unix.c. > > 2. introduce the virtio-vhost-user transport. The virtio-vhost-user >transport requires a driver for the virtio-vhost-user devices. The >driver along with the transport implementation have been packed into >a separate library in `drivers/virtio_vhost_user/`. The necessary >virtio-pci code has been copied from `drivers/net/virtio/`. Some >additional changes have been made so that the driver can utilize the >additional resources of the virtio-vhost-user device. > > 3. update librte_vhost public API to enable choosing transport for each >new vhost device. Extend the vhost net driver and vhost-scsi example >application to export this new API to the end user. > > The primary changes I did to Stefan’s RFC implementation are the > following: > > 1. moved postcopy live migration code into trans_af_unix.c. Postcopy >live migration relies on the userfault fd mechanism, which cannot be >supported by virtio-vhost-user. > > 2. moved setup of the log memory region into trans_af_unix.c. Setting up >the log memory region involves mapping/unmapping guest memory. This >is an AF_UNIX transport-specific operation. Logging dirty pages is the main concept of live migration support. Does it mean that the live migration is not supported for virtio-vhost-user at all? > > 3. introduced a vhost transport operation for >process_slave_message_reply() > > 4. moved the virtio-vhost-user transport/driver into a separate library >in `drivers/virtio_vhost_user/`. This required making vhost.h and >vhost_user.h part of librte_vhost public API and exporting some >private symbols via the version script. This looks better to me that >just moving the entire librte_vhost into `drivers/`. I am not sure if >this is the most appropriate solution. I am looking forward to your >suggestions on this. Moving the virtio-vhost-user code to a separate driver looks strange for me. What is the purpose? Exporting a lot of vhost internal structures will lead to a frequent API/ABI breakages and will slow down accepting changes to releases in general. It looks inconsistent to have 'trans_af_unix.c' in 'lib/librte_vhost/' and 'trans_virtio_vhost_user.c' in 'drivers/virtio_vhost_user/' because these files should be similar in provided functionality, hence, should be located in similar places. > > 5. made use of the virtio PCI capabilities for the additional device >resources (doorbells, shared memory). This required changes in >virtio_pci.c and trans_virtio_vhost_user.c. > > 6. [minor] changed some commit headlines to comply with >check-g
Re: [dpdk-dev] [PATCH 00/28] vhost: add virtio-vhost-user transport
Hi Nikos, On 6/19/19 5:14 PM, Nikos Dragazis wrote: Hi everyone, this patch series introduces the concept of the virtio-vhost-user transport. This is actually a revised version of an earlier RFC implementation that has been proposed by Stefan Hajnoczi [1]. Though this is a great feature, it seems to have been stalled, so I’d like to restart the conversation on this and hopefully get it merged with your help. Let me give you an overview. Thanks for taking over the series! I think you are already aware of that, but it arrives too late to consider it for v19.08, as the proposal deadline is over by almost 3 weeks. That said, it is good that you sent it early, so that we can work to make it in for v19.11. The virtio-vhost-user transport is a vhost-user transport implementation that is based on the virtio-vhost-user device. Its key difference with the existing transport is that it allows deploying vhost-user targets inside dedicated Storage Appliance VMs instead of host user space. In other words, it allows having guests that act as vhost-user backends for other guests. The virtio-vhost-user device implements the vhost-user control plane (master-slave communication) as follows: 1. it parses the vhost-user messages from the vhost-user unix domain socket and forwards them to the slave guest through virtqueues 2. it maps the vhost memory regions in QEMU’s process address space and exposes them to the slave guest as a RAM-backed PCI MMIO region 3. it hooks up doorbells to the callfds. The slave guest can use these doorbells to interrupt the master guest driver The device code has not yet been merged into upstream QEMU, but this is definitely the end goal. Could you provide a pointer to the QEMU series, and instructions to test this new device? The current state is that we are awaiting for the approval of the virtio spec. Ditto, a link to the spec patches would be useful. I have Cced Darek from the SPDK community who has helped me a lot by reviewing this series. Note that any device type could be implemented over this new transport. So, adding the virtio-vhost-user transport in DPDK would allow using it from SPDK as well. Getting into the code internals, this patch series makes the following changes: 1. introduce a generic interface for the transport-specific operations. Each of the two available transports, the pre-existing AF_UNIX transport and the virtio-vhost-user transport, is going to implement this interface. The AF_UNIX-specific code has been extracted from the core vhost-user code and is now part of the AF_UNIX transport implementation in trans_af_unix.c. 2. introduce the virtio-vhost-user transport. The virtio-vhost-user transport requires a driver for the virtio-vhost-user devices. The driver along with the transport implementation have been packed into a separate library in `drivers/virtio_vhost_user/`. The necessary virtio-pci code has been copied from `drivers/net/virtio/`. Some additional changes have been made so that the driver can utilize the additional resources of the virtio-vhost-user device. 3. update librte_vhost public API to enable choosing transport for each new vhost device. Extend the vhost net driver and vhost-scsi example application to export this new API to the end user. The primary changes I did to Stefan’s RFC implementation are the following: 1. moved postcopy live migration code into trans_af_unix.c. Postcopy live migration relies on the userfault fd mechanism, which cannot be supported by virtio-vhost-user. 2. moved setup of the log memory region into trans_af_unix.c. Setting up the log memory region involves mapping/unmapping guest memory. This is an AF_UNIX transport-specific operation. 3. introduced a vhost transport operation for process_slave_message_reply() 4. moved the virtio-vhost-user transport/driver into a separate library in `drivers/virtio_vhost_user/`. This required making vhost.h and vhost_user.h part of librte_vhost public API and exporting some private symbols via the version script. This looks better to me that just moving the entire librte_vhost into `drivers/`. I am not sure if this is the most appropriate solution. I am looking forward to your suggestions on this. I'm not sure this is the right place to put it. 5. made use of the virtio PCI capabilities for the additional device resources (doorbells, shared memory). This required changes in virtio_pci.c and trans_virtio_vhost_user.c. 6. [minor] changed some commit headlines to comply with check-git-log.sh. Please, have a look and let me know about your thoughts. Any reviews/pointers/suggestions are welcome. Maxime
Re: [dpdk-dev] [PATCH 1/3] net: new ipv6 header extension parsing function
Hi Marcin,
>
> Introduce new function for IPv6 header extension parsing able to
> determine extension length and next protocol number.
>
> This function is helpful when implementing IPv6 header traversing.
>
> Signed-off-by: Marcin Smoczynski
> ---
> lib/librte_net/rte_ip.h | 49 +
> 1 file changed, 49 insertions(+)
>
> diff --git a/lib/librte_net/rte_ip.h b/lib/librte_net/rte_ip.h
> index f9b909090..be64da662 100644
> --- a/lib/librte_net/rte_ip.h
> +++ b/lib/librte_net/rte_ip.h
> @@ -425,6 +425,55 @@ rte_ipv6_udptcp_cksum(const struct ipv6_hdr
> *ipv6_hdr, const void *l4_hdr)
> return (uint16_t)cksum;
> }
>
> +/* IPv6 fragmentation header size */
> +#define RTE_IPV6_FRAG_HDR_SIZE 8
> +
> +/**
> + * Parse next IPv6 header extension
> + *
> + * This function checks if proto number is an IPv6 extensions and parses its
> + * data if so, providing information on next header and extension length.
> + *
> + * @param p
> + * Pointer to an extension raw data.
> + * @param proto
> + * Protocol number extracted from the "next header" field from
> + * the IPv6 header or the previous extension.
> + * @param ext_len
> + * Extension data length.
> + * @return
> + * next protocol number if proto is an IPv6 extension, -EINVAL otherwise
> + */
> +static inline int __rte_experimental
Rte_experimental may not be required for inline functions.
> +rte_ipv6_get_next_ext(uint8_t *p, int proto, size_t *ext_len)
> +{
> + int next_proto;
> +
> + switch (proto) {
> + case IPPROTO_AH:
> + next_proto = *p++;
> + *ext_len = (*p + 2) * sizeof(uint32_t);
> + break;
> +
> + case IPPROTO_HOPOPTS:
> + case IPPROTO_ROUTING:
> + case IPPROTO_DSTOPTS:
> + next_proto = *p++;
> + *ext_len = (*p + 1) * sizeof(uint64_t);
> + break;
> +
> + case IPPROTO_FRAGMENT:
I see that there is some compilation issues with respect to IPPROTO_xxx fields.
These are reported in patchworks if you need details.
Could you please fix these and send next rev.
Thanks,
Akhil
[dpdk-dev] Your Bugzilla bug list needs attention.
[This e-mail has been automatically generated.] You have one or more bugs assigned to you in the Bugzilla bug tracking system (http://dpdk.space:8000/) that require attention. All of these bugs are in the CONFIRMED state, and have not been touched in 7 days or more. You need to take a look at them, and decide on an initial action. Generally, this means one of three things: (1) You decide this bug is really quick to deal with (like, it's INVALID), and so you get rid of it immediately. (2) You decide the bug doesn't belong to you, and you reassign it to someone else. (Hint: if you don't know who to reassign it to, make sure that the Component field seems reasonable, and then use the "Reset Assignee to default" option.) (3) You decide the bug belongs to you, but you can't solve it this moment. Accept the bug by setting the status to IN_PROGRESS. To get a list of all CONFIRMED bugs, you can use this URL (bookmark it if you like!): http://dpdk.space:8000/buglist.cgi?bug_status=CONFIRMED&assigned_to=dev@dpdk.org Or, you can use the general query page, at http://dpdk.space:8000/query.cgi Appended below are the individual URLs to get to all of your CONFIRMED bugs that haven't been touched for 7 days or more. You will get this message once a day until you've dealt with these bugs! Green goal: power efficiency with all hardwares -> http://dpdk.space:8000/show_bug.cgi?id=1 dpdk-pdump leads to ovs-vswitchd crash -> http://dpdk.space:8000/show_bug.cgi?id=6 Kernel crash after "Detected Tx Unit Hang" report -> http://dpdk.space:8000/show_bug.cgi?id=15 Does not cross-compile: buildtools/check-experimental-syms.sh assumes `objdump` -> http://dpdk.space:8000/show_bug.cgi?id=32 "rte_eth_tx_queue_setup" will be failed if argument "tx_conf" not specified -> http://dpdk.space:8000/show_bug.cgi?id=43 Reciprocal division: Fail [Crash] -> http://dpdk.space:8000/show_bug.cgi?id=46 For RSS flow actions, e1000_ethdev.h uses IGB_MAX_RX_QUEUE_NUM instead of IGB_MAX_RX_QUEUE_NUM_82576 -> http://dpdk.space:8000/show_bug.cgi?id=83 rte_memcpy() moves data incorrectly on Ubuntu 18.04 on Intel Skylake -> http://dpdk.space:8000/show_bug.cgi?id=97 axgbe driver does not support 1G Copper 1000BASE-T SFPs (Unsupported AN_CL37) -> http://dpdk.space:8000/show_bug.cgi?id=99 Cannot create crypto_openssl after vdev_uninit -> http://dpdk.space:8000/show_bug.cgi?id=105 pktgen -s option send pcap traffic once -> http://dpdk.space:8000/show_bug.cgi?id=113 rte_rand() is not thread-safe but not documented as such -> http://dpdk.space:8000/show_bug.cgi?id=114 conflicting information for 'Running DPDK Applications Without Root Privileges' -> http://dpdk.space:8000/show_bug.cgi?id=118 configure rx queue for JUMBO frame returns warning as offload is 0x0, but eth_pcap_rx_jumbo is present -> http://dpdk.space:8000/show_bug.cgi?id=164 DPDK on Azure using `intel-go/nff-go` fails using `hv_netvsc` driver -> http://dpdk.space:8000/show_bug.cgi?id=175 secondary process cannot execute iommu -> http://dpdk.space:8000/show_bug.cgi?id=176 Problem using cloned rte_mbuf buffers with KNI interface -> http://dpdk.space:8000/show_bug.cgi?id=183 PVP zero-loss performance degradation without --legacy-mem -> http://dpdk.space:8000/show_bug.cgi?id=185 Merge linux and bsd eal_thread.c which are same -> http://dpdk.space:8000/show_bug.cgi?id=187 ethdev API for firmware version request is not tested -> http://dpdk.space:8000/show_bug.cgi?id=225 Flow control mode on mac Intel Corporation I350 Gigabit Network Connection (rev 01) issues -> http://dpdk.space:8000/show_bug.cgi?id=227 Running test-build.sh Fails on ppc_64 fails due to hard-coded requirement for IXGBE_PMD in examples/vm_power_manager -> http://dpdk.space:8000/show_bug.cgi?id=237 [tree-wide] enhance getopt_long usage -> http://dpdk.space:8000/show_bug.cgi?id=238 ipsec-secgw fails to initialize when librte_ipsec is enabled -> http://dpdk.space:8000/show_bug.cgi?id=239 QEMU (vIOMMU+virtio) crashes when DPDK exits -> http://dpdk.space:8000/show_bug.cgi?id=241 Unable to run DPDK test with "make test" command -> http://dpdk.space:8000/show_bug.cgi?id=253 Tap driver unnecessarily triggers timeout on failure -> http://dpdk.space:8000/show_bug.cgi?id=258 Unaligned memory access when reading ipv6 header -> http://dpdk.space:8000/show_bug.cgi?id=279 X710 PF Reset Issue with DPDK VF Driver -> http://dpdk.space:8000/show_bug.cgi?id=280 Fix missing headers in FreeBSD CURRENT build -> http://dpdk.space:8000/show_bug.cgi?id=282 BPF: array ins_chk is missing an entry -> http://dpdk.space:8000/show_bug.cgi?id=283 netvsc PMD/dpdk/azure: Driver lockup with multi-queue configuration -> http://dpdk.space:8000/show_bug.cgi?id=287 Target name recorded wrong when try to build dpdk with x86_64-native-linux-gcc -> http://dpdk.space:8000/show_bug.cgi?id=
[dpdk-dev] DPDK Release Status Meeting 20/6/2019
Minutes 20 June 2019 Agenda: * Release Dates * Subtrees * OvS * Opens Participants: * Intel * Marvell * Mellanox * NXP * Red Hat Release Dates - * v19.08 dates: * RC1 date pushed to *Monday 08 July* * Release Thurs 01 August 2019 * Reminder to send roadmaps for the release, it helps planning * Intel and Arm already shared the roadmap * Marvell will have new PMDs and will provide a roadmap * Mellanox will send the roadmap soon * v19.11 dates: * Proposal/V1 Friday 06 September 2019 * Integration/Merge/RC1 Friday 11 October 2019 * Release Friday 08 November 2019 Subtrees * main * Will do a sub-trees merge today/tomorrow * next-net * Merging patches, more to go * Will be ready for pull from main at the end of today * Marvell proposed to have a net vendor sub-tree, which will be pulled by next-net. Thanks for it, this will help on next-net work load * For next-net-intel, Xiaolong will cover Qi during holiday * next-virtio * Will send a pull request today * next-crypto * Will get ipsec patches * bbdev patches are in backlog, comments sent * next-eventdev * Merging patches * Waiting for new versions of patches * Stable trees * Kevin will be on holiday, Luca will cover him for 18.11.x * v17.11.7 work will start, target is to have rc in two weeks OvS --- * Travis patch to track branches integrated * OvS 2.9/2.10 validating 17.11.6, will help to know 17.11.7 plans * OvS 2.12, v1: 1 July, feature freeze mid July, release mid August Opens - * Please fix Coverity issues * Ferruh to check build errors in daily build log DPDK Release Status Meetings The DPDK Release Status Meeting is intended for DPDK Committers to discuss the status of the master tree and sub-trees, and for project managers to track progress or milestone dates. The meeting occurs on Thursdays at 8:30 UTC. If you wish to attend just send an email to "John McNamara " for the invite.
Re: [dpdk-dev] [PATCH 2/3] ipsec: fix transport mode for ipv6 with extensions
Hi Marcin,
>
> Reconstructing IPv6 header after encryption or decryption requires
> updating 'next header' value in the preceding protocol header, which
> is determined by parsing IPv6 header and iteratively looking for
> next IPv6 header extension.
>
> It is required that 'l3_len' in the mbuf metadata contains a total
> length of the IPv6 header with header extensions up to ESP header.
>
> Signed-off-by: Marcin Smoczynski
> ---
> lib/Makefile | 3 ++-
> lib/librte_ipsec/iph.h | 55 --
> 2 files changed, 49 insertions(+), 9 deletions(-)
>
> diff --git a/lib/Makefile b/lib/Makefile
> index 791e0d991..3ad579f68 100644
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@ -108,7 +108,8 @@ DEPDIRS-librte_gso += librte_mempool
> DIRS-$(CONFIG_RTE_LIBRTE_BPF) += librte_bpf
> DEPDIRS-librte_bpf := librte_eal librte_mempool librte_mbuf librte_ethdev
> DIRS-$(CONFIG_RTE_LIBRTE_IPSEC) += librte_ipsec
> -DEPDIRS-librte_ipsec := librte_eal librte_mbuf librte_cryptodev
> librte_security
> +DEPDIRS-librte_ipsec := librte_eal librte_mbuf librte_cryptodev
> librte_security \
> + librte_net
A nit.
Please update the comment in lib/meson.build file for the dependencies.
Currently it is only for crypto and security.
> DIRS-$(CONFIG_RTE_LIBRTE_TELEMETRY) += librte_telemetry
> DEPDIRS-librte_telemetry := librte_eal librte_metrics librte_ethdev
> DIRS-$(CONFIG_RTE_LIBRTE_RCU) += librte_rcu
> diff --git a/lib/librte_ipsec/iph.h b/lib/librte_ipsec/iph.h
> index 58930cf18..082e4e73e 100644
> --- a/lib/librte_ipsec/iph.h
> +++ b/lib/librte_ipsec/iph.h
> @@ -5,6 +5,8 @@
> #ifndef _IPH_H_
> #define _IPH_H_
>
> +#include
> +
> /**
> * @file iph.h
> * Contains functions/structures/macros to manipulate IPv4/IPv6 headers
> @@ -40,24 +42,61 @@ static inline int
> update_trs_l3hdr(const struct rte_ipsec_sa *sa, void *p, uint32_t plen,
> uint32_t l2len, uint32_t l3len, uint8_t proto)
> {
> - struct ipv4_hdr *v4h;
> - struct ipv6_hdr *v6h;
> int32_t rc;
>
> + /* IPv4 */
> if ((sa->type & RTE_IPSEC_SATP_IPV_MASK) == RTE_IPSEC_SATP_IPV4) {
> + struct ipv4_hdr *v4h;
> +
> v4h = p;
> rc = v4h->next_proto_id;
> v4h->next_proto_id = proto;
> v4h->total_length = rte_cpu_to_be_16(plen - l2len);
> - } else if (l3len == sizeof(*v6h)) {
> + /* IPv6 */
> + } else {
> + struct ipv6_hdr *v6h;
> + uint8_t *next_proto_off;
> +
> v6h = p;
> - rc = v6h->proto;
> - v6h->proto = proto;
> +
> + /* basic IPv6 header with no extensions */
> + if (l3len == sizeof(struct ipv6_hdr))
> + next_proto_off = &v6h->proto;
Is this next_proto_off a pointer to an offset or the value of the next_proto.
So IMO the name should be next_proto or it should be p_nh
> +
> + /* IPv6 with extensions */
> + else {
> + size_t ext_len;
> + int nh;
> + uint8_t *pd, *plimit;
> +
> + /* locate last extension within l3len bytes */
> + pd = (uint8_t *)p;
> + plimit = pd + l3len;
> + ext_len = sizeof(struct ipv6_hdr);
> + nh = v6h->proto;
> + while (pd + ext_len < plimit) {
> + pd += ext_len;
> + nh = rte_ipv6_get_next_ext(pd, nh, &ext_len);
> + if (unlikely(nh < 0))
> + return -EINVAL;
> + }
> +
> + /* invalid l3len - extension exceeds header length */
> + if (unlikely(pd + ext_len != plimit))
> + return -EINVAL;
> +
> + /* save last extension offset */
> + next_proto_off = pd;
> + }
> +
> + /* update header type; return original value */
> + rc = *next_proto_off;
> + *next_proto_off = proto;
> +
> + /* fix packet length */
> v6h->payload_len = rte_cpu_to_be_16(plen - l2len -
> sizeof(*v6h));
> - /* need to add support for IPv6 with options */
> - } else
> - rc = -ENOTSUP;
> + }
>
> return rc;
> }
> --
> 2.21.0.windows.1
Re: [dpdk-dev] [PATCH v1] lib/ipsec: add support for header construction
Hi Marko, Could you please address to the comments from Konstantin? We have an RC1 date coming. Thanks, Akhil > Hi, > > > > > Add support for RFC 4301(5.1.2) to update of > > Type of service field and Traffic class field > > bits inside ipv4/ipv6 packets for outbound cases > > and inbound cases which deals with the update of > > the DSCP/ENC bits inside each of the fields. > > > > Signed-off-by: Marko Kovacevic > > --- > > examples/ipsec-secgw/sa.c | 2 + > > lib/librte_ipsec/esp_inb.c | 14 - > > lib/librte_ipsec/esp_outb.c| 4 +- > > lib/librte_ipsec/iph.h | 119 > > +++- > - > > lib/librte_ipsec/rte_ipsec_sa.h| 25 > > lib/librte_ipsec/sa.c | 17 ++ > > lib/librte_ipsec/sa.h | 2 + > > lib/librte_net/rte_ip.h| 8 +++ > > lib/librte_security/rte_security.h | 9 +++ > > 9 files changed, 191 insertions(+), 9 deletions(-) > > Looks good in general, some generic comments: > - I think it is better to split the patch into few sub-pathces: > One for rte_security, second for rte_net, third - rte_ipsec, forth - > examples/ipsec-secgw > - Would be good to add support for other options too (ttl, etc.) > - Would be good to add new test-case for it into examples/ipsec-secgw/test/ > > Plus few nits in the code below. > Konstantin >
Re: [dpdk-dev] [PATCH v9] app/pdump: exit with primary process
> -Original Message- > From: Suanming.Mou [mailto:mousuanm...@huawei.com] > Sent: Wednesday, May 15, 2019 6:11 AM > To: dev@dpdk.org > Cc: Varghese, Vipin ; Burakov, Anatoly > ; tho...@monjalon.net; Pattan, Reshma > > Subject: [PATCH v9] app/pdump: exit with primary process > > From: Suanming Mou > > The pdump tool works as the secondary process. When the primary process > exits and the residual secondary process keeps running, it will make the > primary process can't start up again. Since the ex-fbarry files are still > attached by the secondary process pdump, the 'new' primary process can't > get these files locked. > > The patch is to set up an alarm which runs every 0.5s periodically to monitor > the primary process in the pdump. Once the primary exits, so will the > pdump. > > Signed-off-by: Suanming Mou > Reviewed-by: Anatoly Burakov > Reviewed-by: Vipin Varghese > Reviewed-by: Reshma Pattan > Reviewed-by: Thomas Monjalon > --- > V9: > * reword the comments and update the git log. > * move release note to release_19_08.rst. > * remove dot in name. > Acked-by line is missing, so re acking. Keep my ack if you have to send next version. Acked-by: Reshma Pattan
Re: [dpdk-dev] [PATCH v2] ipsec: support multi-segment packets
Hi Konstantin, > > Add support for packets that consist of multiple segments. > Take into account that trailer bytes (padding, ESP tail, ICV) > can spawn across multiple segments. > > Signed-off-by: Konstantin Ananyev > --- Which all action types does this patch work well with? Will it work for lookaside none and inline crypto case both? For the other 2, ipsec lib is not used. Also how can the SG support be tested? > > v1 -> v2: > merge with latest mainline > fix build problem for RTE_BUILD_SHARED_LIB=y > update programmer's guide > > doc/guides/prog_guide/ipsec_lib.rst | 1 - > lib/librte_ipsec/Makefile | 3 +- > lib/librte_ipsec/esp_inb.c | 148 +--- > lib/librte_ipsec/misc.h | 61 > 4 files changed, 175 insertions(+), 38 deletions(-) > > diff --git a/doc/guides/prog_guide/ipsec_lib.rst > b/doc/guides/prog_guide/ipsec_lib.rst > index 6fc08886f..63b75b652 100644 > --- a/doc/guides/prog_guide/ipsec_lib.rst > +++ b/doc/guides/prog_guide/ipsec_lib.rst > @@ -162,7 +162,6 @@ Limitations > The following features are not properly supported in the current version: > > * ESP transport mode for IPv6 packets with extension headers. > -* Multi-segment packets. > * Updates of the fields in inner IP header for tunnel mode > (as described in RFC 4301, section 5.1.2). > * Hard/soft limit for SA lifetime (time interval/byte count). > diff --git a/lib/librte_ipsec/Makefile b/lib/librte_ipsec/Makefile > index e80926baa..22f29d98a 100644 > --- a/lib/librte_ipsec/Makefile > +++ b/lib/librte_ipsec/Makefile > @@ -9,7 +9,8 @@ LIB = librte_ipsec.a > CFLAGS += -O3 > CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) > CFLAGS += -DALLOW_EXPERIMENTAL_API > -LDLIBS += -lrte_eal -lrte_mbuf -lrte_net -lrte_cryptodev -lrte_security > +LDLIBS += -lrte_eal -lrte_mempool -lrte_mbuf -lrte_net > +LDLIBS += -lrte_cryptodev -lrte_security > I believe this build dependency should also be updated in meson.build file as well. > EXPORT_MAP := rte_ipsec_version.map > > diff --git a/lib/librte_ipsec/esp_inb.c b/lib/librte_ipsec/esp_inb.c > index 3e12ca103..819d2bf25 100644 > --- a/lib/librte_ipsec/esp_inb.c > +++ b/lib/librte_ipsec/esp_inb.c > @@ -104,6 +104,34 @@ inb_cop_prepare(struct rte_crypto_op *cop, > } > } >
Re: [dpdk-dev] [PATCH 2/2] examples/ipsec-secgw: fix not working inline ipsec modes
Hi Marius,
> Application ipsec-secgw is not working for IPv4 transport mode and for
> IPv6 both transport and tunnel mode.
>
> IPv6 tunnel mode is not working due to wrongly assigned fields of
> security association patterns, as it was IPv4, during creation of
> inline crypto session.
>
> IPv6 and IPv4 transport mode is iterating through security capabilities
> until it reaches tunnel, which causes session to be created as tunnel,
> instead of transport. Another issue, is that config file does not
> provide source and destination ip addresses for transport mode, which
> are required by NIC to perform inline crypto. It uses default addresses
> stored in security association (all zeroes), which causes dropped
> packages.
>
> To fix that, reorganization of code in create_session() is needed,
> to behave appropriately to given protocol (IPv6/IPv4). Change in
> iteration through security capabilities is also required, to check
> for expected mode (not only tunnel).
>
> For lack of addresses issue, some resolving mechanism is needed.
> Approach is to store addresses in security association, as it is
> for tunnel mode. Difference is that they are obtained from sp rules,
> instead of config file. To do that, sp[4/6]_spi_present() function
> is used to find addresses based on spi value, and then stored in
> corresponding sa rule. This approach assumes, that every sp rule
> for inline crypto have valid addresses, as well as range of addresses
> is not supported.
>
> New flags for ipsec_sa structure are required to distinguish between
> IPv4 and IPv6 transport modes. Because of that, there is need to
> change all checks done on these flags, so they work as expected.
>
> Fixes: ec17993a145a ("examples/ipsec-secgw: support security offload")
> Fixes: 9a0752f498d2 ("net/ixgbe: enable inline IPsec")
>
This is a very well written description. Thanks. This helps in review of the
patch.
I have a few small comments, rest all is fine.
> Signed-off-by: Mariusz Drost
> ---
> examples/ipsec-secgw/esp.c | 12 +--
> examples/ipsec-secgw/ipsec.c | 19 +++--
> examples/ipsec-secgw/ipsec.h | 21 +-
> examples/ipsec-secgw/sa.c| 142 ++-
> examples/ipsec-secgw/sp4.c | 24 +-
> examples/ipsec-secgw/sp6.c | 42 ++-
> 6 files changed, 205 insertions(+), 55 deletions(-)
>
> diff --git a/examples/ipsec-secgw/esp.c b/examples/ipsec-secgw/esp.c
> index f11d095ba..764e08dcf 100644
> --- a/examples/ipsec-secgw/esp.c
> +++ b/examples/ipsec-secgw/esp.c
> @@ -192,7 +192,7 @@ esp_inbound_post(struct rte_mbuf *m, struct ipsec_sa
> *sa,
> }
> }
>
> - if (unlikely(sa->flags == TRANSPORT)) {
> + if (unlikely(IS_TRANSPORT(sa->flags))) {
> ip = rte_pktmbuf_mtod(m, struct ip *);
> ip4 = (struct ip *)rte_pktmbuf_adj(m,
> sizeof(struct rte_esp_hdr) + sa->iv_len);
> @@ -233,13 +233,13 @@ esp_outbound(struct rte_mbuf *m, struct ipsec_sa
> *sa,
>
> ip4 = rte_pktmbuf_mtod(m, struct ip *);
> if (likely(ip4->ip_v == IPVERSION)) {
> - if (unlikely(sa->flags == TRANSPORT)) {
> + if (unlikely(IS_TRANSPORT(sa->flags))) {
> ip_hdr_len = ip4->ip_hl * 4;
> nlp = ip4->ip_p;
> } else
> nlp = IPPROTO_IPIP;
> } else if (ip4->ip_v == IP6_VERSION) {
> - if (unlikely(sa->flags == TRANSPORT)) {
> + if (unlikely(IS_TRANSPORT(sa->flags))) {
> /* XXX No option headers supported */
> ip_hdr_len = sizeof(struct ip6_hdr);
> ip6 = (struct ip6_hdr *)ip4;
> @@ -258,13 +258,13 @@ esp_outbound(struct rte_mbuf *m, struct ipsec_sa
> *sa,
> pad_len = pad_payload_len + ip_hdr_len - rte_pktmbuf_pkt_len(m);
>
> RTE_ASSERT(sa->flags == IP4_TUNNEL || sa->flags == IP6_TUNNEL ||
> - sa->flags == TRANSPORT);
> + IS_TRANSPORT(sa->flags));
I can see that at multiple places, sa->flags are accessed without your defined
macros. Could you please update this at all places, so that it will be uniform
across the application.
>
> if (likely(sa->flags == IP4_TUNNEL))
> ip_hdr_len = sizeof(struct ip);
> else if (sa->flags == IP6_TUNNEL)
> ip_hdr_len = sizeof(struct ip6_hdr);
> - else if (sa->flags != TRANSPORT) {
> + else if (!IS_TRANSPORT(sa->flags)) {
> RTE_LOG(ERR, IPSEC_ESP, "Unsupported SA flags: 0x%x\n",
> sa->flags);
> return -EINVAL;
> @@ -291,7 +291,7 @@ esp_outbound(struct rte_mbuf *m, struct ipsec_sa *sa,
> rte_prefetch0(padding);
> }
>
> - switch (sa->flags) {
> + switch (WITHOUT_TRANSPORT_VERSION(sa->flags)) {
I do not get the intent of this macro " WITHOUT_TRANSPORT_VERSION ". could you
explain this in comments or some better name of the
Re: [dpdk-dev] [PATCH v3] ipsec: include high order bytes of esn in pkt len
> > > > When esn is used then high-order 32 bits are included in ICV > > calculation however are not transmitted. Update packet length > > to be consistent with auth data offset and length before crypto > > operation. High-order 32 bits of esn will be removed from packet > > length in crypto post processing. > > > > Signed-off-by: Lukasz Bartosik > > --- > > Acked-by: Konstantin Ananyev > Acked-by: Akhil Goyal
Re: [dpdk-dev] [PATCH v3 2/3] net/ice: add generic flow API
Qiming Yang writes:
> This patch adds ice_flow_create, ice_flow_destroy,
> ice_flow_flush and ice_flow_validate support,
> these are used to handle all the generic filters.
>
> Signed-off-by: Qiming Yang
> ---
> drivers/net/ice/Makefile | 1 +
> drivers/net/ice/ice_ethdev.c | 44 +++
> drivers/net/ice/ice_ethdev.h | 5 +
> drivers/net/ice/ice_generic_flow.c | 682
> +
> drivers/net/ice/ice_generic_flow.h | 654 +++
> drivers/net/ice/meson.build| 1 +
> 6 files changed, 1387 insertions(+)
> create mode 100644 drivers/net/ice/ice_generic_flow.c
> create mode 100644 drivers/net/ice/ice_generic_flow.h
>
> diff --git a/drivers/net/ice/Makefile b/drivers/net/ice/Makefile
> index b10d826..32abeb6 100644
> --- a/drivers/net/ice/Makefile
> +++ b/drivers/net/ice/Makefile
> @@ -79,5 +79,6 @@ endif
> ifeq ($(CC_AVX2_SUPPORT), 1)
> SRCS-$(CONFIG_RTE_LIBRTE_ICE_PMD) += ice_rxtx_vec_avx2.c
> endif
> +SRCS-$(CONFIG_RTE_LIBRTE_ICE_PMD) += ice_generic_flow.c
>
> include $(RTE_SDK)/mk/rte.lib.mk
> diff --git a/drivers/net/ice/ice_ethdev.c b/drivers/net/ice/ice_ethdev.c
> index a94aa7e..8ee06d1 100644
> --- a/drivers/net/ice/ice_ethdev.c
> +++ b/drivers/net/ice/ice_ethdev.c
> @@ -15,6 +15,7 @@
> #include "base/ice_dcb.h"
> #include "ice_ethdev.h"
> #include "ice_rxtx.h"
> +#include "ice_switch_filter.h"
>
> #define ICE_MAX_QP_NUM "max_queue_pair_num"
> #define ICE_DFLT_OUTER_TAG_TYPE ICE_AQ_VSI_OUTER_TAG_VLAN_9100
> @@ -83,6 +84,10 @@ static int ice_xstats_get(struct rte_eth_dev *dev,
> static int ice_xstats_get_names(struct rte_eth_dev *dev,
> struct rte_eth_xstat_name *xstats_names,
> unsigned int limit);
> +static int ice_dev_filter_ctrl(struct rte_eth_dev *dev,
> + enum rte_filter_type filter_type,
> + enum rte_filter_op filter_op,
> + void *arg);
>
> static const struct rte_pci_id pci_id_ice_map[] = {
> { RTE_PCI_DEVICE(ICE_INTEL_VENDOR_ID, ICE_DEV_ID_E810C_BACKPLANE) },
> @@ -141,6 +146,7 @@ static const struct eth_dev_ops ice_eth_dev_ops = {
> .xstats_get = ice_xstats_get,
> .xstats_get_names = ice_xstats_get_names,
> .xstats_reset = ice_stats_reset,
> + .filter_ctrl = ice_dev_filter_ctrl,
> };
>
> /* store statistics names and its offset in stats structure */
> @@ -1478,6 +1484,8 @@ ice_dev_init(struct rte_eth_dev *dev)
> /* get base queue pairs index in the device */
> ice_base_queue_get(pf);
>
> + TAILQ_INIT(&pf->flow_list);
> +
> return 0;
>
> err_pf_setup:
> @@ -1620,6 +1628,8 @@ ice_dev_uninit(struct rte_eth_dev *dev)
> {
> struct rte_pci_device *pci_dev = RTE_ETH_DEV_TO_PCI(dev);
> struct rte_intr_handle *intr_handle = &pci_dev->intr_handle;
> + struct ice_pf *pf = ICE_DEV_PRIVATE_TO_PF(dev->data->dev_private);
> + struct rte_flow *p_flow;
>
> ice_dev_close(dev);
>
> @@ -1637,6 +1647,13 @@ ice_dev_uninit(struct rte_eth_dev *dev)
> rte_intr_callback_unregister(intr_handle,
>ice_interrupt_handler, dev);
>
> + /* Remove all flows */
> + while ((p_flow = TAILQ_FIRST(&pf->flow_list))) {
> + TAILQ_REMOVE(&pf->flow_list, p_flow, node);
> + ice_free_switch_filter_rule(p_flow->rule);
> + rte_free(p_flow);
> + }
> +
> return 0;
> }
>
> @@ -3622,6 +3639,33 @@ static int ice_xstats_get_names(__rte_unused struct
> rte_eth_dev *dev,
> }
>
> static int
> +ice_dev_filter_ctrl(struct rte_eth_dev *dev,
> + enum rte_filter_type filter_type,
> + enum rte_filter_op filter_op,
> + void *arg)
> +{
> + int ret = 0;
> +
> + if (!dev)
> + return -EINVAL;
> +
> + switch (filter_type) {
> + case RTE_ETH_FILTER_GENERIC:
> + if (filter_op != RTE_ETH_FILTER_GET)
> + return -EINVAL;
> + *(const void **)arg = &ice_flow_ops;
> + break;
> + default:
> + PMD_DRV_LOG(WARNING, "Filter type (%d) not supported",
> + filter_type);
> + ret = -EINVAL;
> + break;
> + }
> +
> + return ret;
> +}
> +
> +static int
> ice_pci_probe(struct rte_pci_driver *pci_drv __rte_unused,
> struct rte_pci_device *pci_dev)
> {
> diff --git a/drivers/net/ice/ice_ethdev.h b/drivers/net/ice/ice_ethdev.h
> index 50b966c..8a52239 100644
> --- a/drivers/net/ice/ice_ethdev.h
> +++ b/drivers/net/ice/ice_ethdev.h
> @@ -234,12 +234,16 @@ struct ice_vsi {
> bool offset_loaded;
> };
>
> +extern const struct rte_flow_ops ice_flow_ops;
> +
> /* Struct to store flow created. */
> struct rte_flow {
> TAILQ_ENTRY(rte_flow) node;
> void
Re: [dpdk-dev] [PATCH v6] baseband/fpga_lte_fec: adding driver for FEC on FPGA
On 6/18/2019 7:40 AM, Chalupnik, KamilX wrote: >> -Original Message- >> From: Chautru, Nicolas >> Sent: Friday, June 14, 2019 6:18 PM >> To: akhil.go...@nxp.com; dev@dpdk.org >> Cc: Yigit, Ferruh ; tho...@monjalon.net; Mokhtar, >> Amr ; Chalupnik, KamilX >> ; Chautru, Nicolas >> >> Subject: [PATCH v6] baseband/fpga_lte_fec: adding driver for FEC on FPGA >> >> Supports for FEC 4G PMD Driver on FPGA card PAC N3000 >> >> Signed-off-by: Nicolas Chautru > > Acked-by: Kamil Chalupnik > Above is the ack from Kamil, for some reason seems not hit the mail list, will carry here so that patchwork can pick it. Acked-by: Kamil Chalupnik
Re: [dpdk-dev] [PATCH] cryptodev: add ff_disable field in cryptodev config
> > Adding a new field, ff_disable, to allow applications to control the > features enabled on the crypto device. This would allow for efficient > usage of HW/SW offloads by disabling the features not required by the > application. > > Signed-off-by: Anoob Joseph > --- Acked-by: Akhil Goyal
Re: [dpdk-dev] [PATCH] cryptodev: extend api of asymmetric crypto by sessionless
> > Asymmetric cryptography algorithms may more likely use > sessionless API so there is need to extend API. > > Signed-off-by: Arek Kusztal > --- Acked-by: Akhil Goyal
Re: [dpdk-dev] [PATCH v4 8/8] app/testpmd: use rte_ether_unformat_addr
Hi Stephen,
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Stephen
> Hemminger
> Sent: Wednesday, June 5, 2019 7:10 PM
> To: dev@dpdk.org
> Cc: Stephen Hemminger
> Subject: [dpdk-dev] [PATCH v4 8/8] app/testpmd: use
> rte_ether_unformat_addr
>
> The cmdline_parse_ether_addr does not need to be used everywhere in
> testpmd. Can use rte_ether_unformat_addr instead.
> As an added bonus it eliminates some code for copying.
>
> Signed-off-by: Stephen Hemminger
> ---
> app/test-pmd/cmdline_flow.c | 5 ++---
> app/test-pmd/config.c | 10 +++---
> app/test-pmd/parameters.c | 15 +++
> 3 files changed, 8 insertions(+), 22 deletions(-)
>
> diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
> index 201bd9de56e0..2b02ca29b7ac 100644
> --- a/app/test-pmd/cmdline_flow.c
> +++ b/app/test-pmd/cmdline_flow.c
> @@ -18,7 +18,6 @@
> #include
> #include
> #include
> -#include
> #include
>
> #include "testpmd.h"
> @@ -4627,8 +4626,8 @@ parse_mac_addr(struct context *ctx, const struct
> token *token,
> /* Only network endian is supported. */
> if (!arg->hton)
> goto error;
> - ret = cmdline_parse_etheraddr(NULL, str, &tmp, size);
> - if (ret < 0 || (unsigned int)ret != len)
> + ret = rte_ether_unformat_addr(str, &tmp);
> + if (ret < 0)
> goto error;
> if (!ctx->object)
> return len;
> diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c index
> ab458c8d2837..1d804705d96c 100644
> --- a/app/test-pmd/config.c
> +++ b/app/test-pmd/config.c
> @@ -49,7 +49,6 @@
> #include
> #endif
> #include
> -#include
> #include
>
> #include "testpmd.h"
> @@ -2278,19 +2277,16 @@ pkt_fwd_config_display(struct fwd_config *cfg)
> void set_fwd_eth_peer(portid_t port_id, char *peer_addr) {
> - uint8_t c, new_peer_addr[6];
> + struct rte_ether_addr new_peer_addr;
> if (!rte_eth_dev_is_valid_port(port_id)) {
> printf("Error: Invalid port number %i\n", port_id);
> return;
> }
> - if (cmdline_parse_etheraddr(NULL, peer_addr, &new_peer_addr,
> - sizeof(new_peer_addr)) < 0) {
> + if (rte_ether_unformat_addr(peer_addr, &new_peer_addr) < 0) {
> printf("Error: Invalid ethernet address: %s\n", peer_addr);
> return;
> }
> - for (c = 0; c < 6; c++)
> - peer_eth_addrs[port_id].addr_bytes[c] =
> - new_peer_addr[c];
> + peer_eth_addrs[port_id] = new_peer_addr;
> }
>
> int
> diff --git a/app/test-pmd/parameters.c b/app/test-pmd/parameters.c index
> 245b610641ee..975a97807009 100644
> --- a/app/test-pmd/parameters.c
> +++ b/app/test-pmd/parameters.c
> @@ -39,10 +39,6 @@
> #include
> #include
> #include
> -#ifdef RTE_LIBRTE_CMDLINE
> -#include
> -#include
> -#endif
> #ifdef RTE_LIBRTE_PMD_BOND
> #include
> #endif
> @@ -227,8 +223,7 @@ init_peer_eth_addrs(char *config_filename)
> if (fgets(buf, sizeof(buf), config_file) == NULL)
> break;
>
> - if (cmdline_parse_etheraddr(NULL, buf,
> &peer_eth_addrs[i],
> - sizeof(peer_eth_addrs[i])) < 0) {
> + if (rte_ether_unformat_addr(buf, &peer_eth_addrs[i]) < 0) {
> printf("Bad MAC address format on line %d\n", i+1);
> fclose(config_file);
> return -1;
> @@ -727,7 +722,6 @@ launch_args_parse(int argc, char** argv)
> }
> if (!strcmp(lgopts[opt_idx].name, "eth-peer")) {
> char *port_end;
> - uint8_t c, peer_addr[6];
>
> errno = 0;
> n = strtoul(optarg, &port_end, 10); @@ -
> 739,14 +733,11 @@ launch_args_parse(int argc, char** argv)
>"eth-peer: port %d >=
> RTE_MAX_ETHPORTS(%d)\n",
>n, RTE_MAX_ETHPORTS);
>
> - if (cmdline_parse_etheraddr(NULL,
> port_end,
> - &peer_addr,
> sizeof(peer_addr)) < 0)
> + if (rte_ether_unformat_addr(port_end,
> +
> &peer_eth_addrs[n]) < 0)
> rte_exit(EXIT_FAILURE,
>"Invalid ethernet address:
> %s\n",
>port_end);
> - for (c = 0; c < 6; c++)
> - peer_eth_addrs[n].addr_bytes[c] =
> - peer_addr[c];
> nb_peer_eth_addrs++;
> }
> #endif
> --
> 2.20.1
./devtools/check-git-log.sh -1
Wrong headline format:
app/testpmd: use rte_ether_unformat_add
Re: [dpdk-dev] [PATCH] doc/cryptodev: clarify that full xform struct should be zeroed before use
Hi Fiona, > > Hi Akhil, etc, > Is a deprecation notice necessary for this patch? > If this patch is accepted I will send a follow-up patchset zeroing the xforms > in > crypto apps. > Fiona > Sorry for late reply. I don't think this patch need deprecation notice. > > -Original Message- > > From: Trahe, Fiona > > Sent: Wednesday, May 15, 2019 5:37 PM > > To: dev@dpdk.org > > Cc: Trahe, Fiona ; akhil.go...@nxp.com; De Lara > Guarch, Pablo > > ; Doherty, Declan > ; Zhang, Roy Fan > > ; jer...@marvell.com; Nicolau, Radu > > > Subject: [PATCH] doc/cryptodev: clarify that full xform struct should be > > zeroed > before use > > > > Signed-off-by: Fiona Trahe > > --- > > doc/guides/prog_guide/cryptodev_lib.rst | 10 -- > > 1 files changed, 8 insertions(+), 2 deletions(-) > > Acked-by: Akhil Goyal
Re: [dpdk-dev] [PATCH v2] ipsec: support multi-segment packets
Hi Akhil, > Hi Konstantin, > > > > > Add support for packets that consist of multiple segments. > > Take into account that trailer bytes (padding, ESP tail, ICV) > > can spawn across multiple segments. > > > > Signed-off-by: Konstantin Ananyev > > --- > > Which all action types does this patch work well with? > Will it work for lookaside none and inline crypto case both? Yes, in theory it should work with any device that supports in-place SGL. On practice, right now I am not aware about inline-crypto devices that can support such feature. So far, tested with lookaside-none device. > For the other 2, ipsec lib is not used. In fact, ipsec lib can be used by all 4 cases I believe. Though as I udenstand for lookaside-proto and inline-proto nothing need to be added/changed inside the lib (as HW supposed to deal with it transparently). > > Also how can the SG support be tested? Here is a separate patch series that adds fragmentation/reassembly support into ipsec-secgw and updates test-scripts with new test-cases: http://patches.dpdk.org/cover/54491/ > > > > > v1 -> v2: > > merge with latest mainline > > fix build problem for RTE_BUILD_SHARED_LIB=y > > update programmer's guide > > > > doc/guides/prog_guide/ipsec_lib.rst | 1 - > > lib/librte_ipsec/Makefile | 3 +- > > lib/librte_ipsec/esp_inb.c | 148 +--- > > lib/librte_ipsec/misc.h | 61 > > 4 files changed, 175 insertions(+), 38 deletions(-) > > > > diff --git a/doc/guides/prog_guide/ipsec_lib.rst > > b/doc/guides/prog_guide/ipsec_lib.rst > > index 6fc08886f..63b75b652 100644 > > --- a/doc/guides/prog_guide/ipsec_lib.rst > > +++ b/doc/guides/prog_guide/ipsec_lib.rst > > @@ -162,7 +162,6 @@ Limitations > > The following features are not properly supported in the current version: > > > > * ESP transport mode for IPv6 packets with extension headers. > > -* Multi-segment packets. > > * Updates of the fields in inner IP header for tunnel mode > > (as described in RFC 4301, section 5.1.2). > > * Hard/soft limit for SA lifetime (time interval/byte count). > > diff --git a/lib/librte_ipsec/Makefile b/lib/librte_ipsec/Makefile > > index e80926baa..22f29d98a 100644 > > --- a/lib/librte_ipsec/Makefile > > +++ b/lib/librte_ipsec/Makefile > > @@ -9,7 +9,8 @@ LIB = librte_ipsec.a > > CFLAGS += -O3 > > CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) > > CFLAGS += -DALLOW_EXPERIMENTAL_API > > -LDLIBS += -lrte_eal -lrte_mbuf -lrte_net -lrte_cryptodev -lrte_security > > +LDLIBS += -lrte_eal -lrte_mempool -lrte_mbuf -lrte_net > > +LDLIBS += -lrte_cryptodev -lrte_security > > > > I believe this build dependency should also be updated in meson.build file as > well. I found that unnecessary, meson seems to be able to figure out implicit dependencies itself. Though if you strongly insist, I can add them. Konstantin
Re: [dpdk-dev] [PATCH] maintainers: update dpdk-next-net-intel
On 6/19/2019 9:24 AM, Qi Zhang wrote: > Xiaolong Ye will replace Beilei Xing as co-maintainer of > dpdk-next-net-intel. > > Signed-off-by: Qi Zhang Acked-by: Ferruh Yigit
Re: [dpdk-dev] [RFC] app/testpmd: add profiling for Rx/Tx burst routines
Hi Slava, > -Original Message- > From: Slava Ovsiienko [mailto:viachesl...@mellanox.com] > Sent: Monday, June 10, 2019 5:40 AM > To: Iremonger, Bernard ; dev@dpdk.org > Cc: Yigit, Ferruh > Subject: RE: [dpdk-dev] [RFC] app/testpmd: add profiling for Rx/Tx burst > routines > > > > static void > > > diff --git a/config/common_base b/config/common_base index > > > 6b96e0e..6e84af4 100644 > > > --- a/config/common_base > > > +++ b/config/common_base > > > @@ -998,6 +998,8 @@ CONFIG_RTE_PROC_INFO=n # > > CONFIG_RTE_TEST_PMD=y > > > CONFIG_RTE_TEST_PMD_RECORD_CORE_CYCLES=n > > > +CONFIG_RTE_TEST_PMD_RECORD_CORE_RX_CYCLES=n > > > +CONFIG_RTE_TEST_PMD_RECORD_CORE_TX_CYCLES=n > > > CONFIG_RTE_TEST_PMD_RECORD_BURST_STATS=n > > > > Should the RECORD macros be documented in the run_app.rst file ? You missed the above comment in your reply. There seems to be no documentation on the RECORD macros at present, there probably should be some. Regards, Bernard.
Re: [dpdk-dev] [PATCH v4 8/8] app/testpmd: use rte_ether_unformat_addr
On Thu, 20 Jun 2019 14:18:18 +
"Iremonger, Bernard" wrote:
> Hi Stephen,
>
> > -Original Message-
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Stephen
> > Hemminger
> > Sent: Wednesday, June 5, 2019 7:10 PM
> > To: dev@dpdk.org
> > Cc: Stephen Hemminger
> > Subject: [dpdk-dev] [PATCH v4 8/8] app/testpmd: use
> > rte_ether_unformat_addr
> >
> > The cmdline_parse_ether_addr does not need to be used everywhere in
> > testpmd. Can use rte_ether_unformat_addr instead.
> > As an added bonus it eliminates some code for copying.
> >
> > Signed-off-by: Stephen Hemminger
> > ---
> > app/test-pmd/cmdline_flow.c | 5 ++---
> > app/test-pmd/config.c | 10 +++---
> > app/test-pmd/parameters.c | 15 +++
> > 3 files changed, 8 insertions(+), 22 deletions(-)
> >
> > diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
> > index 201bd9de56e0..2b02ca29b7ac 100644
> > --- a/app/test-pmd/cmdline_flow.c
> > +++ b/app/test-pmd/cmdline_flow.c
> > @@ -18,7 +18,6 @@
> > #include
> > #include
> > #include
> > -#include
> > #include
> >
> > #include "testpmd.h"
> > @@ -4627,8 +4626,8 @@ parse_mac_addr(struct context *ctx, const struct
> > token *token,
> > /* Only network endian is supported. */
> > if (!arg->hton)
> > goto error;
> > - ret = cmdline_parse_etheraddr(NULL, str, &tmp, size);
> > - if (ret < 0 || (unsigned int)ret != len)
> > + ret = rte_ether_unformat_addr(str, &tmp);
> > + if (ret < 0)
> > goto error;
> > if (!ctx->object)
> > return len;
> > diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c index
> > ab458c8d2837..1d804705d96c 100644
> > --- a/app/test-pmd/config.c
> > +++ b/app/test-pmd/config.c
> > @@ -49,7 +49,6 @@
> > #include
> > #endif
> > #include
> > -#include
> > #include
> >
> > #include "testpmd.h"
> > @@ -2278,19 +2277,16 @@ pkt_fwd_config_display(struct fwd_config *cfg)
> > void set_fwd_eth_peer(portid_t port_id, char *peer_addr) {
> > - uint8_t c, new_peer_addr[6];
> > + struct rte_ether_addr new_peer_addr;
> > if (!rte_eth_dev_is_valid_port(port_id)) {
> > printf("Error: Invalid port number %i\n", port_id);
> > return;
> > }
> > - if (cmdline_parse_etheraddr(NULL, peer_addr, &new_peer_addr,
> > - sizeof(new_peer_addr)) < 0) {
> > + if (rte_ether_unformat_addr(peer_addr, &new_peer_addr) < 0) {
> > printf("Error: Invalid ethernet address: %s\n", peer_addr);
> > return;
> > }
> > - for (c = 0; c < 6; c++)
> > - peer_eth_addrs[port_id].addr_bytes[c] =
> > - new_peer_addr[c];
> > + peer_eth_addrs[port_id] = new_peer_addr;
> > }
> >
> > int
> > diff --git a/app/test-pmd/parameters.c b/app/test-pmd/parameters.c index
> > 245b610641ee..975a97807009 100644
> > --- a/app/test-pmd/parameters.c
> > +++ b/app/test-pmd/parameters.c
> > @@ -39,10 +39,6 @@
> > #include
> > #include
> > #include
> > -#ifdef RTE_LIBRTE_CMDLINE
> > -#include
> > -#include
> > -#endif
> > #ifdef RTE_LIBRTE_PMD_BOND
> > #include
> > #endif
> > @@ -227,8 +223,7 @@ init_peer_eth_addrs(char *config_filename)
> > if (fgets(buf, sizeof(buf), config_file) == NULL)
> > break;
> >
> > - if (cmdline_parse_etheraddr(NULL, buf,
> > &peer_eth_addrs[i],
> > - sizeof(peer_eth_addrs[i])) < 0) {
> > + if (rte_ether_unformat_addr(buf, &peer_eth_addrs[i]) < 0) {
> > printf("Bad MAC address format on line %d\n", i+1);
> > fclose(config_file);
> > return -1;
> > @@ -727,7 +722,6 @@ launch_args_parse(int argc, char** argv)
> > }
> > if (!strcmp(lgopts[opt_idx].name, "eth-peer")) {
> > char *port_end;
> > - uint8_t c, peer_addr[6];
> >
> > errno = 0;
> > n = strtoul(optarg, &port_end, 10); @@ -
> > 739,14 +733,11 @@ launch_args_parse(int argc, char** argv)
> > "eth-peer: port %d >=
> > RTE_MAX_ETHPORTS(%d)\n",
> > n, RTE_MAX_ETHPORTS);
> >
> > - if (cmdline_parse_etheraddr(NULL,
> > port_end,
> > - &peer_addr,
> > sizeof(peer_addr)) < 0)
> > + if (rte_ether_unformat_addr(port_end,
> > +
> > &peer_eth_addrs[n]) < 0)
> > rte_exit(EXIT_FAILURE,
> > "Invalid ethernet address:
> > %s\n",
> > port_end);
> > - for (c = 0; c < 6; c++)
> > - peer_eth_addrs[n].addr_bytes[c] =
> > -
[dpdk-dev] [PATCH] eal: promote some service core functions to stable
The functions rte_service_may_be_active(), rte_service_lcore_attr_get(),
and rte_service_attr_reset_all() were introduced nearly a year ago in DPDK
18.08. They can be considered non-experimental for the 19.08 release.
rte_service_may_be_active() is used by eventdev and the sw PMD, and this
commit allows them to not need any experimental API.
Signed-off-by: Gage Eads
---
drivers/event/sw/Makefile | 1 -
drivers/event/sw/meson.build| 1 -
lib/librte_eal/common/include/rte_service.h | 15 +++
lib/librte_eal/common/rte_service.c | 6 +++---
lib/librte_eal/rte_eal_version.map | 6 +++---
lib/librte_eventdev/Makefile| 1 -
lib/librte_eventdev/meson.build | 1 -
7 files changed, 9 insertions(+), 22 deletions(-)
diff --git a/drivers/event/sw/Makefile b/drivers/event/sw/Makefile
index 81236a392..c6600e836 100644
--- a/drivers/event/sw/Makefile
+++ b/drivers/event/sw/Makefile
@@ -7,7 +7,6 @@ include $(RTE_SDK)/mk/rte.vars.mk
LIB = librte_pmd_sw_event.a
# build flags
-CFLAGS += -DALLOW_EXPERIMENTAL_API
CFLAGS += -O3
CFLAGS += $(WERROR_FLAGS)
# for older GCC versions, allow us to initialize an event using
diff --git a/drivers/event/sw/meson.build b/drivers/event/sw/meson.build
index 30d221647..985012219 100644
--- a/drivers/event/sw/meson.build
+++ b/drivers/event/sw/meson.build
@@ -1,7 +1,6 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2017 Intel Corporation
-allow_experimental_apis = true
sources = files('sw_evdev_scheduler.c',
'sw_evdev_selftest.c',
'sw_evdev_worker.c',
diff --git a/lib/librte_eal/common/include/rte_service.h
b/lib/librte_eal/common/include/rte_service.h
index bf25aec35..d8701dd4c 100644
--- a/lib/librte_eal/common/include/rte_service.h
+++ b/lib/librte_eal/common/include/rte_service.h
@@ -162,9 +162,6 @@ int32_t rte_service_runstate_set(uint32_t id, uint32_t
runstate);
int32_t rte_service_runstate_get(uint32_t id);
/**
- * @warning
- * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
- *
* This function returns whether the service may be currently executing on
* at least one lcore, or definitely is not. This function can be used to
* determine if, after setting the service runstate to stopped, the service
@@ -178,7 +175,7 @@ int32_t rte_service_runstate_get(uint32_t id);
* @retval 0 Service is not running on any lcore
* @retval -EINVAL Invalid service id
*/
-int32_t __rte_experimental
+int32_t
rte_service_may_be_active(uint32_t id);
/**
@@ -389,9 +386,6 @@ int32_t rte_service_attr_reset_all(uint32_t id);
#define RTE_SERVICE_LCORE_ATTR_LOOPS 0
/**
- * @warning
- * @b EXPERIMENTAL: this API may change without prior notice
- *
* Get an attribute from a service core.
*
* @param lcore Id of the service core.
@@ -401,14 +395,11 @@ int32_t rte_service_attr_reset_all(uint32_t id);
* -EINVAL Invalid lcore, attr_id or attr_value was NULL.
* -ENOTSUP lcore is not a service core.
*/
-int32_t __rte_experimental
+int32_t
rte_service_lcore_attr_get(uint32_t lcore, uint32_t attr_id,
uint64_t *attr_value);
/**
- * @warning
- * @b EXPERIMENTAL: this API may change without prior notice
- *
* Reset all attribute values of a service core.
*
* @param lcore The service core to reset all the statistics of
@@ -416,7 +407,7 @@ rte_service_lcore_attr_get(uint32_t lcore, uint32_t attr_id,
* -EINVAL Invalid service id provided
* -ENOTSUP lcore is not a service core.
*/
-int32_t __rte_experimental
+int32_t
rte_service_lcore_attr_reset_all(uint32_t lcore);
#ifdef __cplusplus
diff --git a/lib/librte_eal/common/rte_service.c
b/lib/librte_eal/common/rte_service.c
index 5f75e5a53..c3653ebae 100644
--- a/lib/librte_eal/common/rte_service.c
+++ b/lib/librte_eal/common/rte_service.c
@@ -378,7 +378,7 @@ service_run(uint32_t i, int lcore, struct core_state *cs,
uint64_t service_mask)
return 0;
}
-int32_t __rte_experimental
+int32_t
rte_service_may_be_active(uint32_t id)
{
uint32_t ids[RTE_MAX_LCORE] = {0};
@@ -754,7 +754,7 @@ rte_service_attr_get(uint32_t id, uint32_t attr_id,
uint64_t *attr_value)
}
}
-int32_t __rte_experimental
+int32_t
rte_service_lcore_attr_get(uint32_t lcore, uint32_t attr_id,
uint64_t *attr_value)
{
@@ -814,7 +814,7 @@ rte_service_attr_reset_all(uint32_t id)
return 0;
}
-int32_t __rte_experimental
+int32_t
rte_service_lcore_attr_reset_all(uint32_t lcore)
{
struct core_state *cs;
diff --git a/lib/librte_eal/rte_eal_version.map
b/lib/librte_eal/rte_eal_version.map
index 824edf0ff..fc26b9503 100644
--- a/lib/librte_eal/rte_eal_version.map
+++ b/lib/librte_eal/rte_eal_version.map
@@ -292,6 +292,9 @@ DPDK_19.08 {
rte_lcore_index;
rte_lcore_to_socket_id;
+ rte_service_lcore_attr_get;
+ rte_service_lcore_attr_reset_all;
+
Re: [dpdk-dev] [dpdk-announce] DPDK 18.11.2 (LTS) released
Hello, DPDK https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.dpdk.org%2Fdpdk-stable%2Fsnapshot%2Fdpdk-stable-v18.11.2.tar.gz&data=02%7C01%7Cv-advlad%40microsoft.com%7Cf25bf3676935492f47a908d6f586fbdf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636966357449547606&sdata=3Vkt83IWYWEP18ocYyroCPYxNsxLJI18SPZPNLNHjYI%3D&reserved=0, was validated on Azure for Canonical UbuntuServer 16.04-LTS latest, Canonical UbuntuServer 18.04-DAILY-LTS latest, RedHat RHEL 7-RAW latest, RedHat RHEL 7.5 latest, Openlogic CentOS 7.5 latest, SUSE SLES 15 latest. Tested with Mellanox and netvsc poll-mode drivers. The tests were executed using LISAv2 framework (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FLIS%2FLISAv2&data=02%7C01%7Cv-advlad%40microsoft.com%7Cf25bf3676935492f47a908d6f586fbdf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636966357449557602&sdata=Ape9pbmocU5cMltRKDmJZCZJXIQOwvoo1HCMY8bVb0M%3D&reserved=0). NOTE: some tests below 'Failed' are not related to DPDK issue, but host did not bring up VF interface. Test case description: * VERIFY-DPDK-COMPLIANCE - verifies kernel is supported and that the build is successful * VERIFY-DPDK-BUILD-AND-TESTPMD-TEST - verifies using testpmd that packets can be sent from a VM to another VM * VERIFY-DPDK-OVS - builds OVS with DPDK support and tests if the OVS DPDK ports can be created (only on Ubuntu) * VERIFY-SRIOV-FAILSAFE-FOR-DPDK - disables/enables Accelerated Networking for the NICs under test and makes sure DPDK works in both scenarios * VERIFY-DPDK-FAILSAFE-DURING-TRAFFIC - disables/enables Accelerated Networking for the NICs while generating traffic using testpmd * PERF-DPDK-FWD-PPS-DS15 - verifies DPDK forwarding performance using testpmd on 2, 4, 8 cores, rx and io mode on size Standard_DS15_v2 * PERF-DPDK-SINGLE-CORE-PPS-DS4 - verifies DPDK performance using testpmd on 1 core, rx and io mode on size Standard_DS4_v2 * PERF-DPDK-SINGLE-CORE-PPS-DS15 - verifies DPDK performance using testpmd on 1 core, rx and io mode on size Standard_DS15_v2 * PERF-DPDK-MULTICORE-PPS-DS15 - verifies DPDK performance using testpmd on 2, 4, 8 cores, rx and io mode on size Standard_DS15_v2 * PERF-DPDK-MULTICORE-PPS-F32 - verifies DPDK performance using testpmd on 2, 4, 8, 16 cores, rx and io mode on size Standard_F32s_v2 * DPDK-RING-LATENCY - verifies DPDK CPU latency using https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fshemminger%2Fdpdk-ring-ping.git&data=02%7C01%7Cv-advlad%40microsoft.com%7Cf25bf3676935492f47a908d6f586fbdf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636966357449557602&sdata=Q4nRfM8tGtlnppQuuNSFFKOTFr72%2BvnWuxy%2FRN9vFsM%3D&reserved=0 DPDK job exited with status: UNSTABLE - https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flinuxpipeline.westus2.cloudapp.azure.com%2Fjob%2FDPDK%2Fjob%2Fpipeline-dpdk-validation%2Fjob%2Fmaster%2F113%2F&data=02%7C01%7Cv-advlad%40microsoft.com%7Cf25bf3676935492f47a908d6f586fbdf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636966357449557602&sdata=Hu9KjbtDnBpUZWK1o3IjWvpTGTB43FkeexhpxUZjH9g%3D&reserved=0. Test results for DPDK 'https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.dpdk.org%2Fdpdk-stable%2Fsnapshot%2Fdpdk-stable-v18.11.2.tar.gz&data=02%7C01%7Cv-advlad%40microsoft.com%7Cf25bf3676935492f47a908d6f586fbdf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636966357449557602&sdata=yfpj4rFvFP2sDD3I42U%2B09wzNQS6Fb26p63BpB5Z%2BlQ%3D&reserved=0' and Azure image: 'Canonical UbuntuServer 16.04-LTS latest': * PERF-DPDK-SINGLE-CORE-PPS-DS4: PASSED * VERIFY-DPDK-BUILD-AND-TESTPMD-TEST: PASSED * VERIFY-SRIOV-FAILSAFE-FOR-DPDK: PASSED * PERF-DPDK-MULTICORE-PPS-F32: PASSED * VERIFY-DPDK-FAILSAFE-DURING-TRAFFIC: PASSED * PERF-DPDK-FWD-PPS-DS15: ABORTED * PERF-DPDK-SINGLE-CORE-PPS-DS15: PASSED * PERF-DPDK-MULTICORE-PPS-DS15: PASSED * VERIFY-DPDK-COMPLIANCE: PASSED * VERIFY-DPDK-RING-LATENCY: PASSED Test results for DPDK 'https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.dpdk.org%2Fdpdk-stable%2Fsnapshot%2Fdpdk-stable-v18.11.2.tar.gz&data=02%7C01%7Cv-advlad%40microsoft.com%7Cf25bf3676935492f47a908d6f586fbdf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636966357449557602&sdata=yfpj4rFvFP2sDD3I42U%2B09wzNQS6Fb26p63BpB5Z%2BlQ%3D&reserved=0' and Azure image: 'Canonical UbuntuServer 18.04-DAILY-LTS latest': * PERF-DPDK-SINGLE-CORE-PPS-DS4: PASSED * VERIFY-DPDK-BUILD-AND-TESTPMD-TEST: PASSED * VERIFY-SRIOV-FAILSAFE-FOR-DPDK: PASSED * PERF-DPDK-MULTICORE-PPS-F32: PASSED * VERIFY-DPDK-FAILSAFE-DURING-TRAFFIC: PASSED * PERF-DPDK-FWD-PPS-DS15: PASSED * PERF-DPDK-SINGLE-CORE-PPS-DS15: PASSED * PERF-DPDK-MULTICORE-PPS-DS15: PASSED * VERIFY-DPDK-COMPLIANCE: PASSED * VERIFY-DPDK-RING-LATENCY: PASSED Test results for DPDK 'https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.dpdk.org%2Fdpdk-stable%2Fsnapshot%2Fdpdk-stable-v18.11.2.tar.gz&data=02%7C01%7Cv-advlad
Re: [dpdk-dev] [PATCH] eal: resort symbols in EXPERIMENTAL section
On Fri, Jun 14, 2019 at 5:32 PM Ferruh Yigit wrote: > On 6/14/2019 8:44 AM, David Marchand wrote: > > On Fri, Jun 14, 2019 at 9:39 AM Thomas Monjalon > wrote: > > > >> 06/04/2019 05:30, Stephen Hemminger: > >>> The symbols in the EXPERIMENTAL were close to alphabetic > >>> order but running sort showed several mistakes. > >>> > >>> This has no impact on code, API, ABI or otherwise. > >>> Purely for humans. > >>> > >>> Signed-off-by: Stephen Hemminger > >> > >> I don't think it's worth adding a layer of git history for this sort. > >> I would prefer to leave it as is. > >> > >> > > If this is about preferrence, I would prefer we have those symbols sorted > > per versions that introduced them ;-). > > Much easier to check and see if they are candidates for entering stable > ABI. > > > > Not bad idea, +1 from my side J > Here is what it looks like: https://github.com/david-marchand/dpdk/commit/cab0d75ea6bdc7782566d7aad6718b9f5fa784f7 Comments? -- David Marchand
Re: [dpdk-dev] [PATCH v7 0/3] BBDEV turbo_sw PMD compilation fix
On 6/19/2019 6:48 PM, Nicolas Chautru wrote: > Update v7: Remove architecture specific reference to RTE_CPUFLAG_SSE4_2 > reported on travis-ci > Update v6: Cosmetic change to commit message to include previous Acked-by. > Update v5: Cosmetic change to remove trailing space and to commit message. > Rebased to latest. > Update v4: Missed one file for meson build path and minor change to prevent > warning for some configurations due to unused symbols. > Update v3: Cosmetic changes in documentation commit to be more 4G/AVX2 > specific. > Update v2: Splitting into 3 patches as recommended (ignore previous v2 which > had a typo) > > Based on discussion with maintainer, pushing first a patch to help > maintenance of the baseband_turbo_sw which had been lacking. > The documentation is clarified to point to steps on building the SDK > libraries which are now publicly available. > (Cosmetic changes to the webpage containing these SDK will happen in > parallel based on feedback from maintainer). > A compile flag is added to be able to build the turbo_sw PMD when the SDK > libraries for AVX2 are installed or not. > In both cases this can be compiled with gcc RTE_TARGET. > Missing meson build support is also added. > > Note that additional BBDEV changes pushed in previous v1 > https://patches.dpdk.org/project/dpdk/list/?series=4657 > will be added in a separate v2 patchset which will depend on this very > patchset. > > > Nicolas Chautru (3): > baseband/turbo_sw: option to build turbosw PMD without SDK > docs/guides: updating turbo_sw building steps > baseband/turbo_sw: meson build support for PMD driver > For series, Acked-by: Ferruh Yigit
Re: [dpdk-dev] [PATCH 1/3] net: new ipv6 header extension parsing function
Hi Akhil,
>
> Hi Marcin,
>
> >
> > Introduce new function for IPv6 header extension parsing able to
> > determine extension length and next protocol number.
> >
> > This function is helpful when implementing IPv6 header traversing.
> >
> > Signed-off-by: Marcin Smoczynski
> > ---
> > lib/librte_net/rte_ip.h | 49 +
> > 1 file changed, 49 insertions(+)
> >
> > diff --git a/lib/librte_net/rte_ip.h b/lib/librte_net/rte_ip.h
> > index f9b909090..be64da662 100644
> > --- a/lib/librte_net/rte_ip.h
> > +++ b/lib/librte_net/rte_ip.h
> > @@ -425,6 +425,55 @@ rte_ipv6_udptcp_cksum(const struct ipv6_hdr
> > *ipv6_hdr, const void *l4_hdr)
> > return (uint16_t)cksum;
> > }
> >
> > +/* IPv6 fragmentation header size */
> > +#define RTE_IPV6_FRAG_HDR_SIZE 8
> > +
> > +/**
> > + * Parse next IPv6 header extension
> > + *
> > + * This function checks if proto number is an IPv6 extensions and parses
> > its
> > + * data if so, providing information on next header and extension length.
> > + *
> > + * @param p
> > + * Pointer to an extension raw data.
> > + * @param proto
> > + * Protocol number extracted from the "next header" field from
> > + * the IPv6 header or the previous extension.
> > + * @param ext_len
> > + * Extension data length.
> > + * @return
> > + * next protocol number if proto is an IPv6 extension, -EINVAL otherwise
> > + */
> > +static inline int __rte_experimental
>
>
> Rte_experimental may not be required for inline functions.
AFAIK we do need that tag for both inline and non-inline functions,
till API will be transferred to 'stable' state:
$ find lib -type f | xargs grep __rte_experimental | grep inline | wc -l
57
>
>
> > +rte_ipv6_get_next_ext(uint8_t *p, int proto, size_t *ext_len)
> > +{
> > + int next_proto;
> > +
> > + switch (proto) {
> > + case IPPROTO_AH:
> > + next_proto = *p++;
> > + *ext_len = (*p + 2) * sizeof(uint32_t);
> > + break;
> > +
> > + case IPPROTO_HOPOPTS:
> > + case IPPROTO_ROUTING:
> > + case IPPROTO_DSTOPTS:
> > + next_proto = *p++;
> > + *ext_len = (*p + 1) * sizeof(uint64_t);
> > + break;
> > +
> > + case IPPROTO_FRAGMENT:
> I see that there is some compilation issues with respect to IPPROTO_xxx
> fields. These are reported in patchworks if you need details.
>
> Could you please fix these and send next rev.
>
> Thanks,
> Akhil
Re: [dpdk-dev] [PATCH] doc: add multi-proc shared lib mempool note
On 6/18/19 9:48 PM, Gage Eads wrote:
The mempool library assigns handler ops indexes based on the dynamic load
order of mempool handlers. Indexes are used so a mempool can be used by
multiple processes, but this only works if all processes agree on the
mapping from index to mempool handler.
When using the '-d' argument, it's possible for different processes to load
mempool handlers in different orders, and thus have different
index->handler mappings. Using a mempool in multiple of such processes will
result in undefined behavior.
This commit adds a note to the mempool library programmer's guide warning
users against this.
Fixes: 449c49b93a6b ("mempool: support handler operations")
Cc: sta...@dpdk.org
Signed-off-by: Gage Eads
---
doc/guides/prog_guide/mempool_lib.rst | 7 +++
1 file changed, 7 insertions(+)
diff --git a/doc/guides/prog_guide/mempool_lib.rst
b/doc/guides/prog_guide/mempool_lib.rst
index 52a569f57..4470f6b38 100644
--- a/doc/guides/prog_guide/mempool_lib.rst
+++ b/doc/guides/prog_guide/mempool_lib.rst
@@ -133,6 +133,13 @@ For applications that use ``rte_pktmbuf_create()``, there
is a config setting
(``RTE_MBUF_DEFAULT_MEMPOOL_OPS``) that allows the application to make use of
an alternative mempool handler.
+ .. note::
+
+When running a DPDK application with shared libraries, mempool handler
+shared objects specified with the '-d' EAL command-line parameter are
+dynamically loaded. When running a multi-process application with shared
+libraries, the -d arguments for mempool handlers *must be specified in the
+same order for all processes* to ensure correct operation.
One more empty line is required here, other than that:
Acked-by: Andrew Rybchenko
I think it is OK as a fix for stable branches.
In theory I think it is still technically possible to guarantee ops
indices correctness
using dedicated memzone (as Olivier suggested), but with sync up on
rte_mempool_{get,set}_ops() (which should be called when EAL is
initialized) and
reordering. However, it requires API breakage to avoid returning of
ops_index
on register (since it may change in secondary process on resync when EAL is
already initialized).
Re: [dpdk-dev] [PATCH 01/28] vhost: introduce vhost transport operations structure
On 19/6/19 11:14 μ.μ., Aaron Conole wrote:
> Nikos Dragazis writes:
>
>> This is the first of a series of patches, whose purpose is to add
>> support for the virtio-vhost-user transport. This is a vhost-user
>> transport implementation that is different from the default AF_UNIX
>> transport. It uses the virtio-vhost-user PCI device in order to tunnel
>> vhost-user protocol messages over virtio. This lets guests act as vhost
>> device backends for other guests.
>>
>> File descriptor passing is specific to the AF_UNIX vhost-user protocol
>> transport. In order to add support for additional transports, it is
>> necessary to extract transport-specific code from the main vhost-user
>> code.
>>
>> This patch introduces struct vhost_transport_ops and associates each
>> device with a transport. Core vhost-user code calls into
>> vhost_transport_ops to perform transport-specific operations.
>>
>> Notifying callfd is a transport-specific operation, so it belongs to
>> trans_af_unix.c.
>>
>> Several more patches follow this one to complete the task of moving
>> AF_UNIX transport code out of core vhost-user code.
>>
>> Signed-off-by: Nikos Dragazis
>> Signed-off-by: Stefan Hajnoczi
>> ---
> You'll need to also accommodate the meson build - probably with
> something like:
>
> diff --git a/lib/librte_vhost/meson.build b/lib/librte_vhost/meson.build
> index 3090bbe08..81b70683b 100644
> --- a/lib/librte_vhost/meson.build
> +++ b/lib/librte_vhost/meson.build
> @@ -14,6 +14,6 @@ allow_experimental_apis = true
> cflags += '-fno-strict-aliasing'
> sources = files('fd_man.c', 'iotlb.c', 'socket.c', 'vdpa.c',
> 'vhost.c', 'vhost_user.c',
> - 'virtio_net.c', 'vhost_crypto.c')
> + 'virtio_net.c', 'vhost_crypto.c', 'trans_af_unix.c')
> headers = files('rte_vhost.h', 'rte_vdpa.h', 'rte_vhost_crypto.h')
> deps += ['ethdev', 'cryptodev', 'hash', 'pci']
Thanks for the pointer. I will incorporate the change in the second
version of the patch series along with any other potential comments.
>
>
>> lib/librte_vhost/Makefile| 2 +-
>> lib/librte_vhost/trans_af_unix.c | 20
>> lib/librte_vhost/vhost.c | 1 +
>> lib/librte_vhost/vhost.h | 34 +-
>> 4 files changed, 51 insertions(+), 6 deletions(-)
>> create mode 100644 lib/librte_vhost/trans_af_unix.c
>>
>> diff --git a/lib/librte_vhost/Makefile b/lib/librte_vhost/Makefile
>> index 8623e91..5ff5fb2 100644
>> --- a/lib/librte_vhost/Makefile
>> +++ b/lib/librte_vhost/Makefile
>> @@ -23,7 +23,7 @@ LDLIBS += -lrte_eal -lrte_mempool -lrte_mbuf -lrte_ethdev
>> -lrte_net
>>
>> # all source are stored in SRCS-y
>> SRCS-$(CONFIG_RTE_LIBRTE_VHOST) := fd_man.c iotlb.c socket.c vhost.c \
>> -vhost_user.c virtio_net.c vdpa.c
>> +vhost_user.c virtio_net.c vdpa.c
>> trans_af_unix.c
>>
>> # install includes
>> SYMLINK-$(CONFIG_RTE_LIBRTE_VHOST)-include += rte_vhost.h rte_vdpa.h
>> diff --git a/lib/librte_vhost/trans_af_unix.c
>> b/lib/librte_vhost/trans_af_unix.c
>> new file mode 100644
>> index 000..3f0c308
>> --- /dev/null
>> +++ b/lib/librte_vhost/trans_af_unix.c
>> @@ -0,0 +1,20 @@
>> +/* SPDX-License-Identifier: BSD-3-Clause
>> + * Copyright(c) 2010-2018 Intel Corporation
>> + * Copyright(c) 2017 Red Hat, Inc.
>> + * Copyright(c) 2019 Arrikto Inc.
>> + */
>> +
>> +#include "vhost.h"
>> +
>> +static int
>> +af_unix_vring_call(struct virtio_net *dev __rte_unused,
>> + struct vhost_virtqueue *vq)
>> +{
>> +if (vq->callfd >= 0)
>> +eventfd_write(vq->callfd, (eventfd_t)1);
>> +return 0;
>> +}
>> +
>> +const struct vhost_transport_ops af_unix_trans_ops = {
>> +.vring_call = af_unix_vring_call,
>> +};
>> diff --git a/lib/librte_vhost/vhost.c b/lib/librte_vhost/vhost.c
>> index 981837b..a36bc01 100644
>> --- a/lib/librte_vhost/vhost.c
>> +++ b/lib/librte_vhost/vhost.c
>> @@ -507,6 +507,7 @@ vhost_new_device(void)
>> dev->vid = i;
>> dev->flags = VIRTIO_DEV_BUILTIN_VIRTIO_NET;
>> dev->slave_req_fd = -1;
>> +dev->trans_ops = &af_unix_trans_ops;
>> dev->vdpa_dev_id = -1;
>> dev->postcopy_ufd = -1;
>> rte_spinlock_init(&dev->slave_req_lock);
>> diff --git a/lib/librte_vhost/vhost.h b/lib/librte_vhost/vhost.h
>> index 884befa..077f213 100644
>> --- a/lib/librte_vhost/vhost.h
>> +++ b/lib/librte_vhost/vhost.h
>> @@ -286,6 +286,30 @@ struct guest_page {
>> uint64_t size;
>> };
>>
>> +struct virtio_net;
>> +
>> +/**
>> + * A structure containing function pointers for transport-specific
>> operations.
>> + */
>> +struct vhost_transport_ops {
>> +/**
>> + * Notify the guest that used descriptors have been added to the vring.
>> + * The VRING_AVAIL_F_NO_INTERRUPT flag and event idx have already been
>> checked
>> + * so this function just needs to perform the notification.
>> + *
>> + * @param dev
Re: [dpdk-dev] [PATCH 01/28] vhost: introduce vhost transport operations structure
On 20/6/19 1:30 μ.μ., Bruce Richardson wrote:
> On Wed, Jun 19, 2019 at 04:14:09PM -0400, Aaron Conole wrote:
>> Nikos Dragazis writes:
>>
>>> This is the first of a series of patches, whose purpose is to add
>>> support for the virtio-vhost-user transport. This is a vhost-user
>>> transport implementation that is different from the default AF_UNIX
>>> transport. It uses the virtio-vhost-user PCI device in order to tunnel
>>> vhost-user protocol messages over virtio. This lets guests act as vhost
>>> device backends for other guests.
>>>
>>> File descriptor passing is specific to the AF_UNIX vhost-user protocol
>>> transport. In order to add support for additional transports, it is
>>> necessary to extract transport-specific code from the main vhost-user
>>> code.
>>>
>>> This patch introduces struct vhost_transport_ops and associates each
>>> device with a transport. Core vhost-user code calls into
>>> vhost_transport_ops to perform transport-specific operations.
>>>
>>> Notifying callfd is a transport-specific operation, so it belongs to
>>> trans_af_unix.c.
>>>
>>> Several more patches follow this one to complete the task of moving
>>> AF_UNIX transport code out of core vhost-user code.
>>>
>>> Signed-off-by: Nikos Dragazis
>>> Signed-off-by: Stefan Hajnoczi
>>> ---
>> You'll need to also accommodate the meson build - probably with
>> something like:
>>
>> diff --git a/lib/librte_vhost/meson.build b/lib/librte_vhost/meson.build
>> index 3090bbe08..81b70683b 100644
>> --- a/lib/librte_vhost/meson.build
>> +++ b/lib/librte_vhost/meson.build
>> @@ -14,6 +14,6 @@ allow_experimental_apis = true
>> cflags += '-fno-strict-aliasing'
>> sources = files('fd_man.c', 'iotlb.c', 'socket.c', 'vdpa.c',
>> 'vhost.c', 'vhost_user.c',
>> - 'virtio_net.c', 'vhost_crypto.c')
>> + 'virtio_net.c', 'vhost_crypto.c', 'trans_af_unix.c')
>> headers = files('rte_vhost.h', 'rte_vdpa.h', 'rte_vhost_crypto.h')
>> deps += ['ethdev', 'cryptodev', 'hash', 'pci']
>>
>>
> Yep, except I think we should try and keep the files in alphabetical order,
> with only a couple of entries per line [so place trans_af_unix.c on a new
> line with vdpa.c].
Ack
Re: [dpdk-dev] [PATCH] eal: promote some service core functions to stable
Gage Eads writes:
> The functions rte_service_may_be_active(), rte_service_lcore_attr_get(),
> and rte_service_attr_reset_all() were introduced nearly a year ago in DPDK
> 18.08. They can be considered non-experimental for the 19.08 release.
>
> rte_service_may_be_active() is used by eventdev and the sw PMD, and this
> commit allows them to not need any experimental API.
>
> Signed-off-by: Gage Eads
> ---
> drivers/event/sw/Makefile | 1 -
> drivers/event/sw/meson.build| 1 -
> lib/librte_eal/common/include/rte_service.h | 15 +++
> lib/librte_eal/common/rte_service.c | 6 +++---
> lib/librte_eal/rte_eal_version.map | 6 +++---
> lib/librte_eventdev/Makefile| 1 -
> lib/librte_eventdev/meson.build | 1 -
> 7 files changed, 9 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/event/sw/Makefile b/drivers/event/sw/Makefile
> index 81236a392..c6600e836 100644
> --- a/drivers/event/sw/Makefile
> +++ b/drivers/event/sw/Makefile
> @@ -7,7 +7,6 @@ include $(RTE_SDK)/mk/rte.vars.mk
> LIB = librte_pmd_sw_event.a
>
> # build flags
> -CFLAGS += -DALLOW_EXPERIMENTAL_API
> CFLAGS += -O3
> CFLAGS += $(WERROR_FLAGS)
> # for older GCC versions, allow us to initialize an event using
> diff --git a/drivers/event/sw/meson.build b/drivers/event/sw/meson.build
> index 30d221647..985012219 100644
> --- a/drivers/event/sw/meson.build
> +++ b/drivers/event/sw/meson.build
> @@ -1,7 +1,6 @@
> # SPDX-License-Identifier: BSD-3-Clause
> # Copyright(c) 2017 Intel Corporation
>
> -allow_experimental_apis = true
I don't think you can remove these. There are still some experimental
APIs (f.e. the rename for rte_cryptodev_sym_session_get_private_data
marked that function as experimental and it will cause build breakage).
Maybe I'm mis understanding it? It would be good to get verification
from Bruce whether that API should not be marked as experimental (it was
just a rename, so not sure...) - maybe that's a follow up for this
patch?
See: https://travis-ci.com/ovsrobot/dpdk/jobs/209722145 for an example
The odd thing is I only see it on the clang builds - perhaps it's a
missing definition for the clang compiler.
> sources = files('sw_evdev_scheduler.c',
> 'sw_evdev_selftest.c',
> 'sw_evdev_worker.c',
> diff --git a/lib/librte_eal/common/include/rte_service.h
> b/lib/librte_eal/common/include/rte_service.h
> index bf25aec35..d8701dd4c 100644
> --- a/lib/librte_eal/common/include/rte_service.h
> +++ b/lib/librte_eal/common/include/rte_service.h
> @@ -162,9 +162,6 @@ int32_t rte_service_runstate_set(uint32_t id, uint32_t
> runstate);
> int32_t rte_service_runstate_get(uint32_t id);
>
> /**
> - * @warning
> - * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
> - *
> * This function returns whether the service may be currently executing on
> * at least one lcore, or definitely is not. This function can be used to
> * determine if, after setting the service runstate to stopped, the service
> @@ -178,7 +175,7 @@ int32_t rte_service_runstate_get(uint32_t id);
> * @retval 0 Service is not running on any lcore
> * @retval -EINVAL Invalid service id
> */
> -int32_t __rte_experimental
> +int32_t
> rte_service_may_be_active(uint32_t id);
>
> /**
> @@ -389,9 +386,6 @@ int32_t rte_service_attr_reset_all(uint32_t id);
> #define RTE_SERVICE_LCORE_ATTR_LOOPS 0
>
> /**
> - * @warning
> - * @b EXPERIMENTAL: this API may change without prior notice
> - *
> * Get an attribute from a service core.
> *
> * @param lcore Id of the service core.
> @@ -401,14 +395,11 @@ int32_t rte_service_attr_reset_all(uint32_t id);
> * -EINVAL Invalid lcore, attr_id or attr_value was NULL.
> * -ENOTSUP lcore is not a service core.
> */
> -int32_t __rte_experimental
> +int32_t
> rte_service_lcore_attr_get(uint32_t lcore, uint32_t attr_id,
> uint64_t *attr_value);
>
> /**
> - * @warning
> - * @b EXPERIMENTAL: this API may change without prior notice
> - *
> * Reset all attribute values of a service core.
> *
> * @param lcore The service core to reset all the statistics of
> @@ -416,7 +407,7 @@ rte_service_lcore_attr_get(uint32_t lcore, uint32_t
> attr_id,
> * -EINVAL Invalid service id provided
> * -ENOTSUP lcore is not a service core.
> */
> -int32_t __rte_experimental
> +int32_t
> rte_service_lcore_attr_reset_all(uint32_t lcore);
>
> #ifdef __cplusplus
> diff --git a/lib/librte_eal/common/rte_service.c
> b/lib/librte_eal/common/rte_service.c
> index 5f75e5a53..c3653ebae 100644
> --- a/lib/librte_eal/common/rte_service.c
> +++ b/lib/librte_eal/common/rte_service.c
> @@ -378,7 +378,7 @@ service_run(uint32_t i, int lcore, struct core_state *cs,
> uint64_t service_mask)
> return 0;
> }
>
> -int32_t __rte_experimental
> +int32_t
> rte_service_may_be_active(uint32_t id)
> {
> uint32_t ids[RTE_MAX
Re: [dpdk-dev] [RFC] ethdev: reserve the RX offload most-significant bits for PMD scartch
CC ethdev maintainers On 6/20/19 10:25 AM, Haiyue Wang wrote: Generally speaking, the DEV_RX_OFFLOAD_xxx for RX offload capabilities of a device is one-bit field definition, it has 64 different values at most. Nowdays the receiving queue of NIC has rich features not just checksum offload, like it can extract the network protocol header fields to its RX descriptors for quickly handling. But this kind of feature is not so common, and it is hardware related. Normally, this can be done through rte_devargs driver parameters, but the scope is per device. This is not so nice for per queue design. The per queue API 'rte_eth_rx_queue_setup' and data structure 'struct rte_eth_rxconf' are stable now, and be common for all PMDs. For keeping the ethdev API & ABI compatibility, and the application can make good use of the NIC's specific features, reserving the most-significant bits of RX offload seems an compromise method. Then the PMDs redefine these bits as they want, all PMDs share the same bit positions and expose their new definitions with the header file. The experimental reserved bits number is 6 currently. Tt can be one-bit for each features up to the the maximum number 6. It can also be some bits encoding: e.g, 6 bits can stand for 63 maximum number of features. We call these reserved bits as DEV_RX_OFFLOAD_PMD_SCRATCH. And the left unused bits number is : 64 - 19 (currently defined) - 6 (PMD scartch) = 39. This is not so nice for applications, they need to check PMD's driver name for lookuping their DEV_RX_OFFLOAD_PMD_SCRATCH definitions. But it is good for the applications to make use of the hardware compatibility. Signed-off-by: Haiyue Wang I would say that it very bad for applications. It sounds like reserved bits in registers which have meaning in fact and sometimes different meaning. Of course, it is not that bad when rules are defined, but such kind of features tend to spread and clutter up interfaces. IMHO, the feature is really frightening.
Re: [dpdk-dev] [RFC] ethdev: reserve the RX offload most-significant bits for PMD scartch
On Thu, 20 Jun 2019 15:25:52 +0800 Haiyue Wang wrote: > Generally speaking, the DEV_RX_OFFLOAD_xxx for RX offload capabilities > of a device is one-bit field definition, it has 64 different values at > most. > > Nowdays the receiving queue of NIC has rich features not just checksum > offload, like it can extract the network protocol header fields to its > RX descriptors for quickly handling. But this kind of feature is not so > common, and it is hardware related. Normally, this can be done through > rte_devargs driver parameters, but the scope is per device. This is not > so nice for per queue design. > > The per queue API 'rte_eth_rx_queue_setup' and data structure 'struct > rte_eth_rxconf' are stable now, and be common for all PMDs. For keeping > the ethdev API & ABI compatibility, and the application can make good > use of the NIC's specific features, reserving the most-significant bits > of RX offload seems an compromise method. > > Then the PMDs redefine these bits as they want, all PMDs share the same > bit positions and expose their new definitions with the header file. > > The experimental reserved bits number is 6 currently. Tt can be one-bit > for each features up to the the maximum number 6. It can also be some > bits encoding: e.g, 6 bits can stand for 63 maximum number of features. > > We call these reserved bits as DEV_RX_OFFLOAD_PMD_SCRATCH. And the left > unused bits number is : 64 - 19 (currently defined) - 6 (PMD scartch) = > 39. > > This is not so nice for applications, they need to check PMD's driver > name for lookuping their DEV_RX_OFFLOAD_PMD_SCRATCH definitions. But it > is good for the applications to make use of the hardware compatibility. > > Signed-off-by: Haiyue Wang > --- Anything that is per device type is useless for a generic application. The goal of the DPDK should be to provide a high performance platform that works for many device types. Too often, I see patches from hardware vendors that are just "we can enable are cool proprietary hardware feature in DPDK". This would just encourage that bad practice.
Re: [dpdk-dev] [PATCH] eal: promote some service core functions to stable
> Gage Eads writes: > > > The functions rte_service_may_be_active(), > > rte_service_lcore_attr_get(), and rte_service_attr_reset_all() were > > introduced nearly a year ago in DPDK 18.08. They can be considered non- > experimental for the 19.08 release. > > > > rte_service_may_be_active() is used by eventdev and the sw PMD, and > > this commit allows them to not need any experimental API. > > > > Signed-off-by: Gage Eads > > --- > > drivers/event/sw/Makefile | 1 - > > drivers/event/sw/meson.build| 1 - > > lib/librte_eal/common/include/rte_service.h | 15 +++ > > lib/librte_eal/common/rte_service.c | 6 +++--- > > lib/librte_eal/rte_eal_version.map | 6 +++--- > > lib/librte_eventdev/Makefile| 1 - > > lib/librte_eventdev/meson.build | 1 - > > 7 files changed, 9 insertions(+), 22 deletions(-) > > > > diff --git a/drivers/event/sw/Makefile b/drivers/event/sw/Makefile > > index 81236a392..c6600e836 100644 > > --- a/drivers/event/sw/Makefile > > +++ b/drivers/event/sw/Makefile > > @@ -7,7 +7,6 @@ include $(RTE_SDK)/mk/rte.vars.mk LIB = > > librte_pmd_sw_event.a > > > > # build flags > > -CFLAGS += -DALLOW_EXPERIMENTAL_API > > CFLAGS += -O3 > > CFLAGS += $(WERROR_FLAGS) > > # for older GCC versions, allow us to initialize an event using diff > > --git a/drivers/event/sw/meson.build b/drivers/event/sw/meson.build > > index 30d221647..985012219 100644 > > --- a/drivers/event/sw/meson.build > > +++ b/drivers/event/sw/meson.build > > @@ -1,7 +1,6 @@ > > # SPDX-License-Identifier: BSD-3-Clause # Copyright(c) 2017 Intel > > Corporation > > > > -allow_experimental_apis = true > > I don't think you can remove these. There are still some experimental APIs > (f.e. the rename for rte_cryptodev_sym_session_get_private_data > marked that function as experimental and it will cause build breakage). > > Maybe I'm mis understanding it? It would be good to get verification from > Bruce whether that API should not be marked as experimental (it was just a > rename, so not sure...) - maybe that's a follow up for this patch? > > See: https://travis-ci.com/ovsrobot/dpdk/jobs/209722145 for an example > > The odd thing is I only see it on the clang builds - perhaps it's a missing > definition for the clang compiler. > You're right, eventdev still uses that experimental API (which this patch is unrelated to). I tested this change with GCC (5.4.0) and it built without errors, which I took to mean no more experimental APIs were in use. That's concerning that GCC didn't catch it. At any rate, I'll correct this in v2. Thanks, Gage
[dpdk-dev] [PATCH v2] eal: promote some service core functions to stable
The functions rte_service_may_be_active(), rte_service_lcore_attr_get(),
and rte_service_attr_reset_all() were introduced nearly a year ago in DPDK
18.08. They can be considered non-experimental for the 19.08 release.
rte_service_may_be_active() is used by the sw PMD, and this commit allows
it to not need any experimental API.
Signed-off-by: Gage Eads
---
drivers/event/sw/Makefile | 1 -
drivers/event/sw/meson.build| 1 -
lib/librte_eal/common/include/rte_service.h | 15 +++
lib/librte_eal/common/rte_service.c | 6 +++---
lib/librte_eal/rte_eal_version.map | 6 +++---
5 files changed, 9 insertions(+), 20 deletions(-)
v2: add allow-experimental flag back to eventdev, which still uses an
experimental cryptodev API
diff --git a/drivers/event/sw/Makefile b/drivers/event/sw/Makefile
index 81236a392..c6600e836 100644
--- a/drivers/event/sw/Makefile
+++ b/drivers/event/sw/Makefile
@@ -7,7 +7,6 @@ include $(RTE_SDK)/mk/rte.vars.mk
LIB = librte_pmd_sw_event.a
# build flags
-CFLAGS += -DALLOW_EXPERIMENTAL_API
CFLAGS += -O3
CFLAGS += $(WERROR_FLAGS)
# for older GCC versions, allow us to initialize an event using
diff --git a/drivers/event/sw/meson.build b/drivers/event/sw/meson.build
index 30d221647..985012219 100644
--- a/drivers/event/sw/meson.build
+++ b/drivers/event/sw/meson.build
@@ -1,7 +1,6 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2017 Intel Corporation
-allow_experimental_apis = true
sources = files('sw_evdev_scheduler.c',
'sw_evdev_selftest.c',
'sw_evdev_worker.c',
diff --git a/lib/librte_eal/common/include/rte_service.h
b/lib/librte_eal/common/include/rte_service.h
index bf25aec35..d8701dd4c 100644
--- a/lib/librte_eal/common/include/rte_service.h
+++ b/lib/librte_eal/common/include/rte_service.h
@@ -162,9 +162,6 @@ int32_t rte_service_runstate_set(uint32_t id, uint32_t
runstate);
int32_t rte_service_runstate_get(uint32_t id);
/**
- * @warning
- * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
- *
* This function returns whether the service may be currently executing on
* at least one lcore, or definitely is not. This function can be used to
* determine if, after setting the service runstate to stopped, the service
@@ -178,7 +175,7 @@ int32_t rte_service_runstate_get(uint32_t id);
* @retval 0 Service is not running on any lcore
* @retval -EINVAL Invalid service id
*/
-int32_t __rte_experimental
+int32_t
rte_service_may_be_active(uint32_t id);
/**
@@ -389,9 +386,6 @@ int32_t rte_service_attr_reset_all(uint32_t id);
#define RTE_SERVICE_LCORE_ATTR_LOOPS 0
/**
- * @warning
- * @b EXPERIMENTAL: this API may change without prior notice
- *
* Get an attribute from a service core.
*
* @param lcore Id of the service core.
@@ -401,14 +395,11 @@ int32_t rte_service_attr_reset_all(uint32_t id);
* -EINVAL Invalid lcore, attr_id or attr_value was NULL.
* -ENOTSUP lcore is not a service core.
*/
-int32_t __rte_experimental
+int32_t
rte_service_lcore_attr_get(uint32_t lcore, uint32_t attr_id,
uint64_t *attr_value);
/**
- * @warning
- * @b EXPERIMENTAL: this API may change without prior notice
- *
* Reset all attribute values of a service core.
*
* @param lcore The service core to reset all the statistics of
@@ -416,7 +407,7 @@ rte_service_lcore_attr_get(uint32_t lcore, uint32_t attr_id,
* -EINVAL Invalid service id provided
* -ENOTSUP lcore is not a service core.
*/
-int32_t __rte_experimental
+int32_t
rte_service_lcore_attr_reset_all(uint32_t lcore);
#ifdef __cplusplus
diff --git a/lib/librte_eal/common/rte_service.c
b/lib/librte_eal/common/rte_service.c
index 5f75e5a53..c3653ebae 100644
--- a/lib/librte_eal/common/rte_service.c
+++ b/lib/librte_eal/common/rte_service.c
@@ -378,7 +378,7 @@ service_run(uint32_t i, int lcore, struct core_state *cs,
uint64_t service_mask)
return 0;
}
-int32_t __rte_experimental
+int32_t
rte_service_may_be_active(uint32_t id)
{
uint32_t ids[RTE_MAX_LCORE] = {0};
@@ -754,7 +754,7 @@ rte_service_attr_get(uint32_t id, uint32_t attr_id,
uint64_t *attr_value)
}
}
-int32_t __rte_experimental
+int32_t
rte_service_lcore_attr_get(uint32_t lcore, uint32_t attr_id,
uint64_t *attr_value)
{
@@ -814,7 +814,7 @@ rte_service_attr_reset_all(uint32_t id)
return 0;
}
-int32_t __rte_experimental
+int32_t
rte_service_lcore_attr_reset_all(uint32_t lcore)
{
struct core_state *cs;
diff --git a/lib/librte_eal/rte_eal_version.map
b/lib/librte_eal/rte_eal_version.map
index 824edf0ff..fc26b9503 100644
--- a/lib/librte_eal/rte_eal_version.map
+++ b/lib/librte_eal/rte_eal_version.map
@@ -292,6 +292,9 @@ DPDK_19.08 {
rte_lcore_index;
rte_lcore_to_socket_id;
+ rte_service_lcore_attr_get;
+ rte_service_lcore_attr_reset_all;
+ rte_service_may_b
Re: [dpdk-dev] [PATCH] doc: add multi-proc shared lib mempool note
> -Original Message-
> From: Andrew Rybchenko [mailto:arybche...@solarflare.com]
> Sent: Thursday, June 20, 2019 1:01 PM
> To: Eads, Gage ; dev@dpdk.org
> Cc: olivier.m...@6wind.com; sta...@dpdk.org
> Subject: Re: [PATCH] doc: add multi-proc shared lib mempool note
>
> On 6/18/19 9:48 PM, Gage Eads wrote:
> > The mempool library assigns handler ops indexes based on the dynamic
> > load order of mempool handlers. Indexes are used so a mempool can be
> > used by multiple processes, but this only works if all processes agree
> > on the mapping from index to mempool handler.
> >
> > When using the '-d' argument, it's possible for different processes to
> > load mempool handlers in different orders, and thus have different
> > index->handler mappings. Using a mempool in multiple of such processes
> > index->will
> > result in undefined behavior.
> >
> > This commit adds a note to the mempool library programmer's guide
> > warning users against this.
> >
> > Fixes: 449c49b93a6b ("mempool: support handler operations")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Gage Eads
> > ---
> > doc/guides/prog_guide/mempool_lib.rst | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/doc/guides/prog_guide/mempool_lib.rst
> > b/doc/guides/prog_guide/mempool_lib.rst
> > index 52a569f57..4470f6b38 100644
> > --- a/doc/guides/prog_guide/mempool_lib.rst
> > +++ b/doc/guides/prog_guide/mempool_lib.rst
> > @@ -133,6 +133,13 @@ For applications that use ``rte_pktmbuf_create()``,
> there is a config setting
> > (``RTE_MBUF_DEFAULT_MEMPOOL_OPS``) that allows the application to
> make use of
> > an alternative mempool handler.
> >
> > + .. note::
> > +
> > +When running a DPDK application with shared libraries, mempool
> handler
> > +shared objects specified with the '-d' EAL command-line parameter are
> > +dynamically loaded. When running a multi-process application with
> shared
> > +libraries, the -d arguments for mempool handlers *must be specified in
> the
> > +same order for all processes* to ensure correct operation.
> >
>
> One more empty line is required here, other than that:
> Acked-by: Andrew Rybchenko
Can do. Just for my understanding, why is the extra empty line required?
>
> I think it is OK as a fix for stable branches.
>
> In theory I think it is still technically possible to guarantee ops indices
> correctness using dedicated memzone (as Olivier suggested), but with sync
> up on
> rte_mempool_{get,set}_ops() (which should be called when EAL is
> initialized) and
> reordering. However, it requires API breakage to avoid returning of
> ops_index on register (since it may change in secondary process on resync
> when EAL is already initialized).
[dpdk-dev] [PATCH v5 0/9] kni: fixes and cleanups
While testing KNI with netvsc, saw lots of places more code could be safely removed from KNI kernel driver. v5 - add minimal ethtool, fix checkpath author complaints v4 - add more style fixes v3 - rebase to current master, add style fix patch v2 - get rid of unnecessary padding, combine the unused field patches Stephen Hemminger (9): kni: don't need stubs for rx_mode or ioctl kni: use netdev_alloc_skb kni: don't keep stats in kni_net kni: drop unused fields kni: use proper type for kni fifo's kni: return -EFAULT if copy_from_user fails doc: update KNI documentation kni: fix style issues kni: add minimal ethtool .../sample_app_ug/kernel_nic_interface.rst| 18 ++-- kernel/linux/kni/kni_dev.h| 20 ++-- kernel/linux/kni/kni_misc.c | 18 ++-- kernel/linux/kni/kni_net.c| 100 +++--- lib/librte_kni/rte_kni.c | 38 +++ 5 files changed, 78 insertions(+), 116 deletions(-) -- 2.20.1
[dpdk-dev] [PATCH v5 1/9] kni: don't need stubs for rx_mode or ioctl
The netdev subsystem already handles case where
network sevice does not support ioctl.
If device has no rx_mode hook it is not called.
Signed-off-by: Stephen Hemminger
---
kernel/linux/kni/kni_net.c | 19 ---
1 file changed, 19 deletions(-)
diff --git a/kernel/linux/kni/kni_net.c b/kernel/linux/kni/kni_net.c
index ad8365877cda..c86337d099ab 100644
--- a/kernel/linux/kni/kni_net.c
+++ b/kernel/linux/kni/kni_net.c
@@ -593,23 +593,6 @@ kni_net_tx_timeout(struct net_device *dev)
netif_wake_queue(dev);
}
-/*
- * Ioctl commands
- */
-static int
-kni_net_ioctl(struct net_device *dev, struct ifreq *rq, int cmd)
-{
- pr_debug("kni_net_ioctl group:%d cmd:%d\n",
- ((struct kni_dev *)netdev_priv(dev))->group_id, cmd);
-
- return -EOPNOTSUPP;
-}
-
-static void
-kni_net_set_rx_mode(struct net_device *dev)
-{
-}
-
static int
kni_net_change_mtu(struct net_device *dev, int new_mtu)
{
@@ -758,8 +741,6 @@ static const struct net_device_ops kni_net_netdev_ops = {
.ndo_change_rx_flags = kni_net_set_promiscusity,
.ndo_start_xmit = kni_net_tx,
.ndo_change_mtu = kni_net_change_mtu,
- .ndo_do_ioctl = kni_net_ioctl,
- .ndo_set_rx_mode = kni_net_set_rx_mode,
.ndo_get_stats = kni_net_stats,
.ndo_tx_timeout = kni_net_tx_timeout,
.ndo_set_mac_address = kni_net_set_mac,
--
2.20.1
[dpdk-dev] [PATCH v5 2/9] kni: use netdev_alloc_skb
netdev_alloc_skb is optimized to any alignment or setup
of skb->dev that is required. The kernel has chosen to not pad
packets on x86 (for many years), because it is faster.
Signed-off-by: Stephen Hemminger
---
kernel/linux/kni/kni_net.c | 17 +++--
1 file changed, 3 insertions(+), 14 deletions(-)
diff --git a/kernel/linux/kni/kni_net.c b/kernel/linux/kni/kni_net.c
index c86337d099ab..cce5e7eb991f 100644
--- a/kernel/linux/kni/kni_net.c
+++ b/kernel/linux/kni/kni_net.c
@@ -340,16 +340,13 @@ kni_net_rx_normal(struct kni_dev *kni)
data_kva = kva2data_kva(kva);
kni->va[i] = pa2va(kni->pa[i], kva);
- skb = dev_alloc_skb(len + 2);
+ skb = netdev_alloc_skb(dev, len);
if (!skb) {
/* Update statistics */
kni->stats.rx_dropped++;
continue;
}
- /* Align IP on 16B boundary */
- skb_reserve(skb, 2);
-
if (kva->nb_segs == 1) {
memcpy(skb_put(skb, len), data_kva, len);
} else {
@@ -368,7 +365,6 @@ kni_net_rx_normal(struct kni_dev *kni)
}
}
- skb->dev = dev;
skb->protocol = eth_type_trans(skb, dev);
skb->ip_summed = CHECKSUM_UNNECESSARY;
@@ -512,26 +508,20 @@ kni_net_rx_lo_fifo_skb(struct kni_dev *kni)
data_kva = kva2data_kva(kva);
kni->va[i] = pa2va(kni->pa[i], kva);
- skb = dev_alloc_skb(len + 2);
+ skb = netdev_alloc_skb(dev, len);
if (skb) {
- /* Align IP on 16B boundary */
- skb_reserve(skb, 2);
memcpy(skb_put(skb, len), data_kva, len);
- skb->dev = dev;
skb->ip_summed = CHECKSUM_UNNECESSARY;
dev_kfree_skb(skb);
}
/* Simulate real usage, allocate/copy skb twice */
- skb = dev_alloc_skb(len + 2);
+ skb = netdev_alloc_skb(dev, len);
if (skb == NULL) {
kni->stats.rx_dropped++;
continue;
}
- /* Align IP on 16B boundary */
- skb_reserve(skb, 2);
-
if (kva->nb_segs == 1) {
memcpy(skb_put(skb, len), data_kva, len);
} else {
@@ -550,7 +540,6 @@ kni_net_rx_lo_fifo_skb(struct kni_dev *kni)
}
}
- skb->dev = dev;
skb->ip_summed = CHECKSUM_UNNECESSARY;
kni->stats.rx_bytes += len;
--
2.20.1
[dpdk-dev] [PATCH v5 3/9] kni: don't keep stats in kni_net
Since kernel 2.6.28 the network subsystem has provided
dev->stats for devices to use statistics handling and is the
default if no ndo_get_stats is provided.
This allow allows for 64 bit (rather than just 32 bit)
statistics with KNI.
Signed-off-by: Stephen Hemminger
---
kernel/linux/kni/kni_dev.h | 1 -
kernel/linux/kni/kni_net.c | 43 +-
2 files changed, 15 insertions(+), 29 deletions(-)
diff --git a/kernel/linux/kni/kni_dev.h b/kernel/linux/kni/kni_dev.h
index d57bce647e4a..21e4b0d92368 100644
--- a/kernel/linux/kni/kni_dev.h
+++ b/kernel/linux/kni/kni_dev.h
@@ -39,7 +39,6 @@ struct kni_dev {
/* kni list */
struct list_head list;
- struct net_device_stats stats;
int status;
uint16_t group_id; /* Group ID of a group of KNI devices */
uint32_t core_id;/* Core ID to bind */
diff --git a/kernel/linux/kni/kni_net.c b/kernel/linux/kni/kni_net.c
index cce5e7eb991f..06310fec57bb 100644
--- a/kernel/linux/kni/kni_net.c
+++ b/kernel/linux/kni/kni_net.c
@@ -291,15 +291,15 @@ kni_net_tx(struct sk_buff *skb, struct net_device *dev)
/* Free skb and update statistics */
dev_kfree_skb(skb);
- kni->stats.tx_bytes += len;
- kni->stats.tx_packets++;
+ dev->stats.tx_bytes += len;
+ dev->stats.tx_packets++;
return NETDEV_TX_OK;
drop:
/* Free skb and update statistics */
dev_kfree_skb(skb);
- kni->stats.tx_dropped++;
+ dev->stats.tx_dropped++;
return NETDEV_TX_OK;
}
@@ -343,7 +343,7 @@ kni_net_rx_normal(struct kni_dev *kni)
skb = netdev_alloc_skb(dev, len);
if (!skb) {
/* Update statistics */
- kni->stats.rx_dropped++;
+ dev->stats.rx_dropped++;
continue;
}
@@ -372,8 +372,8 @@ kni_net_rx_normal(struct kni_dev *kni)
netif_rx_ni(skb);
/* Update statistics */
- kni->stats.rx_bytes += len;
- kni->stats.rx_packets++;
+ dev->stats.rx_bytes += len;
+ dev->stats.rx_packets++;
}
/* Burst enqueue mbufs into free_q */
@@ -396,6 +396,7 @@ kni_net_rx_lo_fifo(struct kni_dev *kni)
void *data_kva;
struct rte_kni_mbuf *alloc_kva;
void *alloc_data_kva;
+ struct net_device *dev = kni->net_dev;
/* Get the number of entries in rx_q */
num_rq = kni_fifo_count(kni->rx_q);
@@ -443,8 +444,8 @@ kni_net_rx_lo_fifo(struct kni_dev *kni)
alloc_kva->pkt_len = len;
alloc_kva->data_len = len;
- kni->stats.tx_bytes += len;
- kni->stats.rx_bytes += len;
+ dev->stats.tx_bytes += len;
+ dev->stats.rx_bytes += len;
}
/* Burst enqueue mbufs into tx_q */
@@ -464,8 +465,8 @@ kni_net_rx_lo_fifo(struct kni_dev *kni)
* Update statistic, and enqueue/dequeue failure is impossible,
* as all queues are checked at first.
*/
- kni->stats.tx_packets += num;
- kni->stats.rx_packets += num;
+ dev->stats.tx_packets += num;
+ dev->stats.rx_packets += num;
}
/*
@@ -518,7 +519,7 @@ kni_net_rx_lo_fifo_skb(struct kni_dev *kni)
/* Simulate real usage, allocate/copy skb twice */
skb = netdev_alloc_skb(dev, len);
if (skb == NULL) {
- kni->stats.rx_dropped++;
+ dev->stats.rx_dropped++;
continue;
}
@@ -542,8 +543,8 @@ kni_net_rx_lo_fifo_skb(struct kni_dev *kni)
skb->ip_summed = CHECKSUM_UNNECESSARY;
- kni->stats.rx_bytes += len;
- kni->stats.rx_packets++;
+ dev->stats.rx_bytes += len;
+ dev->stats.rx_packets++;
/* call tx interface */
kni_net_tx(skb, dev);
@@ -573,12 +574,10 @@ kni_net_rx(struct kni_dev *kni)
static void
kni_net_tx_timeout(struct net_device *dev)
{
- struct kni_dev *kni = netdev_priv(dev);
-
pr_debug("Transmit timeout at %ld, latency %ld\n", jiffies,
jiffies - dev_trans_start(dev));
- kni->stats.tx_errors++;
+ dev->stats.tx_errors++;
netif_wake_queue(dev);
}
@@ -627,17 +626,6 @@ kni_net_poll_resp(struct kni_dev *kni)
wake_up_interruptible(&kni->wq);
}
-/*
- * Return statistics to the caller
- */
-static struct net_device_stats *
-kni_net_stats(struct net_device *dev)
-{
- struct kni_dev *kni = netdev_priv(dev);
-
- return &kni->stats;
-}
-
/*
* Fill the eth header
*/
@@ -730,7 +718,6 @@ static const struct net_device_ops kni_net_netdev_ops = {
.ndo_change_rx_flags = kni_net_set_promiscusity,
.ndo_sta
[dpdk-dev] [PATCH v5 4/9] kni: drop unused fields
Several fields were either totally unused or set and never used.
Signed-off-by: Stephen Hemminger
---
kernel/linux/kni/kni_dev.h | 5 -
kernel/linux/kni/kni_misc.c | 1 -
2 files changed, 6 deletions(-)
diff --git a/kernel/linux/kni/kni_dev.h b/kernel/linux/kni/kni_dev.h
index 21e4b0d92368..f3e6c3ca4efa 100644
--- a/kernel/linux/kni/kni_dev.h
+++ b/kernel/linux/kni/kni_dev.h
@@ -39,8 +39,6 @@ struct kni_dev {
/* kni list */
struct list_head list;
- int status;
- uint16_t group_id; /* Group ID of a group of KNI devices */
uint32_t core_id;/* Core ID to bind */
char name[RTE_KNI_NAMESIZE]; /* Network device name */
struct task_struct *pthread;
@@ -79,9 +77,6 @@ struct kni_dev {
/* mbuf size */
uint32_t mbuf_size;
- /* synchro for request processing */
- unsigned long synchro;
-
/* buffers */
void *pa[MBUF_BURST_SZ];
void *va[MBUF_BURST_SZ];
diff --git a/kernel/linux/kni/kni_misc.c b/kernel/linux/kni/kni_misc.c
index 1fc5eeb9c8ca..b59cf24c2184 100644
--- a/kernel/linux/kni/kni_misc.c
+++ b/kernel/linux/kni/kni_misc.c
@@ -346,7 +346,6 @@ kni_ioctl_create(struct net *net, uint32_t ioctl_num,
kni = netdev_priv(net_dev);
kni->net_dev = net_dev;
- kni->group_id = dev_info.group_id;
kni->core_id = dev_info.core_id;
strncpy(kni->name, dev_info.name, RTE_KNI_NAMESIZE);
--
2.20.1
[dpdk-dev] [PATCH v5 5/9] kni: use proper type for kni fifo's
Using void * instead of proper type is unsafe practice.
Signed-off-by: Stephen Hemminger
---
kernel/linux/kni/kni_dev.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/kernel/linux/kni/kni_dev.h b/kernel/linux/kni/kni_dev.h
index f3e6c3ca4efa..ceba5f73c1d9 100644
--- a/kernel/linux/kni/kni_dev.h
+++ b/kernel/linux/kni/kni_dev.h
@@ -51,22 +51,22 @@ struct kni_dev {
struct net_device *net_dev;
/* queue for packets to be sent out */
- void *tx_q;
+ struct rte_kni_fifo *tx_q;
/* queue for the packets received */
- void *rx_q;
+ struct rte_kni_fifo *rx_q;
/* queue for the allocated mbufs those can be used to save sk buffs */
- void *alloc_q;
+ struct rte_kni_fifo *alloc_q;
/* free queue for the mbufs to be freed */
- void *free_q;
+ struct rte_kni_fifo *free_q;
/* request queue */
- void *req_q;
+ struct rte_kni_fifo *req_q;
/* response queue */
- void *resp_q;
+ struct rte_kni_fifo *resp_q;
void *sync_kva;
void *sync_va;
--
2.20.1
[dpdk-dev] [PATCH v5 6/9] kni: return -EFAULT if copy_from_user fails
The correct thing to return if user gives a bad data
is to return -EFAULT. Logging is also discouraged because
it could be used as a DoS attack.
Signed-off-by: Stephen Hemminger
---
kernel/linux/kni/kni_misc.c | 16 +---
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/kernel/linux/kni/kni_misc.c b/kernel/linux/kni/kni_misc.c
index b59cf24c2184..be45f823408f 100644
--- a/kernel/linux/kni/kni_misc.c
+++ b/kernel/linux/kni/kni_misc.c
@@ -301,11 +301,8 @@ kni_ioctl_create(struct net *net, uint32_t ioctl_num,
return -EINVAL;
/* Copy kni info from user space */
- ret = copy_from_user(&dev_info, (void *)ioctl_param, sizeof(dev_info));
- if (ret) {
- pr_err("copy_from_user in kni_ioctl_create");
- return -EIO;
- }
+ if (copy_from_user(&dev_info, (void *)ioctl_param, sizeof(dev_info)))
+ return -EFAULT;
/* Check if name is zero-ended */
if (strnlen(dev_info.name, sizeof(dev_info.name)) ==
sizeof(dev_info.name)) {
@@ -427,15 +424,12 @@ kni_ioctl_release(struct net *net, uint32_t ioctl_num,
if (_IOC_SIZE(ioctl_num) > sizeof(dev_info))
return -EINVAL;
- ret = copy_from_user(&dev_info, (void *)ioctl_param, sizeof(dev_info));
- if (ret) {
- pr_err("copy_from_user in kni_ioctl_release");
- return -EIO;
- }
+ if (copy_from_user(&dev_info, (void *)ioctl_param, sizeof(dev_info)))
+ return -EFAULT;
/* Release the network device according to its name */
if (strlen(dev_info.name) == 0)
- return ret;
+ return -EINVAL;
down_write(&knet->kni_list_lock);
list_for_each_entry_safe(dev, n, &knet->kni_list_head, list) {
--
2.20.1
[dpdk-dev] [PATCH v5 8/9] kni: fix style issues
rte_kni does not follow standard style rules.
Noticed some extra \ line continuation etc.
Signed-off-by: Stephen Hemminger
---
kernel/linux/kni/kni_net.c | 7 ---
lib/librte_kni/rte_kni.c | 38 +++---
2 files changed, 23 insertions(+), 22 deletions(-)
diff --git a/kernel/linux/kni/kni_net.c b/kernel/linux/kni/kni_net.c
index 06310fec57bb..320d51d7fc83 100644
--- a/kernel/linux/kni/kni_net.c
+++ b/kernel/linux/kni/kni_net.c
@@ -401,7 +401,7 @@ kni_net_rx_lo_fifo(struct kni_dev *kni)
/* Get the number of entries in rx_q */
num_rq = kni_fifo_count(kni->rx_q);
- /* Get the number of free entrie in tx_q */
+ /* Get the number of free entries in tx_q */
num_tq = kni_fifo_free_count(kni->tx_q);
/* Get the number of entries in alloc_q */
@@ -755,6 +755,7 @@ kni_net_config_lo_mode(char *lo_str)
} else if (!strcmp(lo_str, "lo_mode_fifo_skb")) {
pr_debug("loopback mode=lo_mode_fifo_skb enabled");
kni_net_rx_func = kni_net_rx_lo_fifo_skb;
- } else
- pr_debug("Incognizant parameter, loopback disabled");
+ } else {
+ pr_debug("Unknown loopback parameter, disabled");
+ }
}
diff --git a/lib/librte_kni/rte_kni.c b/lib/librte_kni/rte_kni.c
index e29d0cc7df3c..9b6acc382fc3 100644
--- a/lib/librte_kni/rte_kni.c
+++ b/lib/librte_kni/rte_kni.c
@@ -59,7 +59,7 @@ struct rte_kni {
uint16_t group_id; /**< Group ID of KNI devices */
uint32_t slot_id; /**< KNI pool slot ID */
struct rte_mempool *pktmbuf_pool; /**< pkt mbuf mempool */
- unsigned mbuf_size; /**< mbuf size */
+ unsigned int mbuf_size; /**< mbuf size */
const struct rte_memzone *m_tx_q; /**< TX queue memzone */
const struct rte_memzone *m_rx_q; /**< RX queue memzone */
@@ -78,7 +78,7 @@ struct rte_kni {
/* For request & response */
struct rte_kni_fifo *req_q; /**< Request queue */
struct rte_kni_fifo *resp_q;/**< Response queue */
- void * sync_addr; /**< Req/Resp Mem address */
+ void *sync_addr; /**< Req/Resp Mem address */
struct rte_kni_ops ops; /**< operations for request */
};
@@ -473,7 +473,7 @@ kni_config_promiscusity(uint16_t port_id, uint8_t to_on)
int
rte_kni_handle_request(struct rte_kni *kni)
{
- unsigned ret;
+ unsigned int ret;
struct rte_kni_request *req = NULL;
if (kni == NULL)
@@ -498,8 +498,8 @@ rte_kni_handle_request(struct rte_kni *kni)
break;
case RTE_KNI_REQ_CFG_NETWORK_IF: /* Set network interface up/down */
if (kni->ops.config_network_if)
- req->result = kni->ops.config_network_if(\
- kni->ops.port_id, req->if_up);
+ req->result =
kni->ops.config_network_if(kni->ops.port_id,
+req->if_up);
break;
case RTE_KNI_REQ_CHANGE_MAC_ADDR: /* Change MAC Address */
if (kni->ops.config_mac_address)
@@ -534,7 +534,7 @@ rte_kni_handle_request(struct rte_kni *kni)
}
unsigned
-rte_kni_tx_burst(struct rte_kni *kni, struct rte_mbuf **mbufs, unsigned num)
+rte_kni_tx_burst(struct rte_kni *kni, struct rte_mbuf **mbufs, unsigned int
num)
{
void *phy_mbufs[num];
unsigned int ret;
@@ -552,9 +552,9 @@ rte_kni_tx_burst(struct rte_kni *kni, struct rte_mbuf
**mbufs, unsigned num)
}
unsigned
-rte_kni_rx_burst(struct rte_kni *kni, struct rte_mbuf **mbufs, unsigned num)
+rte_kni_rx_burst(struct rte_kni *kni, struct rte_mbuf **mbufs, unsigned int
num)
{
- unsigned ret = kni_fifo_get(kni->tx_q, (void **)mbufs, num);
+ unsigned int ret = kni_fifo_get(kni->tx_q, (void **)mbufs, num);
/* If buffers removed, allocate mbufs and then put them into alloc_q */
if (ret)
@@ -605,7 +605,7 @@ kni_allocate_mbufs(struct rte_kni *kni)
return;
}
- allocq_free = (kni->alloc_q->read - kni->alloc_q->write - 1) \
+ allocq_free = (kni->alloc_q->read - kni->alloc_q->write - 1)
& (MAX_MBUF_BURST_NUM - 1);
for (i = 0; i < allocq_free; i++) {
pkts[i] = rte_pktmbuf_alloc(kni->pktmbuf_pool);
@@ -659,35 +659,35 @@ static enum kni_ops_status
kni_check_request_register(struct rte_kni_ops *ops)
{
/* check if KNI request ops has been registered*/
- if( NULL == ops )
+ if (ops == NULL)
return KNI_REQ_NO_REGISTER;
- if ((ops->change_mtu == NULL)
- && (ops->config_network_if == NULL)
- && (ops->config_mac_address == NULL)
- && (ops->config_promiscusity == NULL))
+ if (ops->change_mtu == NULL
+ && ops->conf
[dpdk-dev] [PATCH v5 7/9] doc: update KNI documentation
Make the KNI documentation reflect modern kernel networking. Ifconfig has been superseded by iproute2 for 15 years. Iproute2 is well maintained, supports current feature set. Ethtool is no longer supported by KNI. Tshark is a better replacement for tcpdump. Signed-off-by: Stephen Hemminger --- .../sample_app_ug/kernel_nic_interface.rst | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/doc/guides/sample_app_ug/kernel_nic_interface.rst b/doc/guides/sample_app_ug/kernel_nic_interface.rst index a7e549d5213a..422bd8c98465 100644 --- a/doc/guides/sample_app_ug/kernel_nic_interface.rst +++ b/doc/guides/sample_app_ug/kernel_nic_interface.rst @@ -21,14 +21,14 @@ The FIFO queues contain pointers to data packets in the DPDK. This: * Provides a faster mechanism to interface with the kernel net stack and eliminates system calls -* Facilitates the DPDK using standard Linux* userspace net tools (tcpdump, ftp, and so on) +* Facilitates the DPDK using standard Linux* userspace net tools (tshark, rsync, and so on) * Eliminate the copy_to_user and copy_from_user operations on packets. The Kernel NIC Interface sample application is a simple example that demonstrates the use of the DPDK to create a path for packets to go through the Linux* kernel. This is done by creating one or more kernel net devices for each of the DPDK ports. -The application allows the use of standard Linux tools (ethtool, ifconfig, tcpdump) with the DPDK ports and +The application allows the use of standard Linux tools (iproute, tshark) with the DPDK ports and also the exchange of packets between the DPDK application and the Linux* kernel. The Kernel NIC Interface sample application requires that the @@ -220,13 +220,13 @@ Enable KNI interface and assign an IP address: .. code-block:: console -# ifconfig vEth0_0 192.168.0.1 +# ip addr add dev vEth0_0 192.168.0.1 Show KNI interface configuration and statistics: .. code-block:: console -# ifconfig vEth0_0 +# ip -s -d addr show vEth0_0 The user can also check and reset the packet statistics inside the ``kni`` application by sending the app the USR1 and USR2 signals: @@ -234,16 +234,16 @@ application by sending the app the USR1 and USR2 signals: .. code-block:: console # Print statistics -# kill -SIGUSR1 `pidof kni` +# pkill -USR1 kni # Zero statistics -# kill -SIGUSR2 `pidof kni` +# pkill -USR2 kni Dump network traffic: .. code-block:: console -# tcpdump -i vEth0_0 +# tshark -n -i vEth0_0 The normal Linux commands can also be used to change the MAC address and MTU size used by the physical NIC which corresponds to the KNI interface. @@ -254,13 +254,13 @@ Change the MAC address: .. code-block:: console -# ifconfig vEth0_0 hw ether 0C:01:02:03:04:08 +# ip link set dev vEth0_0 lladdr 0C:01:02:03:04:08 Change the MTU size: .. code-block:: console -# ifconfig vEth0_0 mtu 1450 +# ip link set dev vEth0_0 mtu 1450 When the ``kni`` application is closed, all the KNI interfaces are deleted from the Linux kernel. -- 2.20.1
[dpdk-dev] [PATCH v5 9/9] kni: add minimal ethtool
Some applications use ethtool so add the minimum ethtool ops.
Signed-off-by: Stephen Hemminger
---
kernel/linux/kni/kni_dev.h | 2 ++
kernel/linux/kni/kni_misc.c | 1 +
kernel/linux/kni/kni_net.c | 14 ++
3 files changed, 17 insertions(+)
diff --git a/kernel/linux/kni/kni_dev.h b/kernel/linux/kni/kni_dev.h
index ceba5f73c1d9..c1ca6789ce12 100644
--- a/kernel/linux/kni/kni_dev.h
+++ b/kernel/linux/kni/kni_dev.h
@@ -11,6 +11,8 @@
#endif
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+#define KNI_VERSION"1.0"
+
#include "compat.h"
#include
diff --git a/kernel/linux/kni/kni_misc.c b/kernel/linux/kni/kni_misc.c
index be45f823408f..2b75502a8b0e 100644
--- a/kernel/linux/kni/kni_misc.c
+++ b/kernel/linux/kni/kni_misc.c
@@ -21,6 +21,7 @@
#include "compat.h"
#include "kni_dev.h"
+MODULE_VERSION(KNI_VERSION);
MODULE_LICENSE("Dual BSD/GPL");
MODULE_AUTHOR("Intel Corporation");
MODULE_DESCRIPTION("Kernel Module for managing kni devices");
diff --git a/kernel/linux/kni/kni_net.c b/kernel/linux/kni/kni_net.c
index 320d51d7fc83..319ee2dcb19a 100644
--- a/kernel/linux/kni/kni_net.c
+++ b/kernel/linux/kni/kni_net.c
@@ -13,6 +13,7 @@
#include
#include
#include /* eth_type_trans */
+#include
#include
#include
#include
@@ -725,6 +726,18 @@ static const struct net_device_ops kni_net_netdev_ops = {
#endif
};
+static void kni_get_drvinfo(struct net_device *dev,
+ struct ethtool_drvinfo *info)
+{
+ strlcpy(info->version, KNI_VERSION, sizeof(info->version));
+ strlcpy(info->driver, "kni", sizeof(info->driver));
+}
+
+static const struct ethtool_ops kni_net_ethtool_ops = {
+ .get_drvinfo= kni_get_drvinfo,
+ .get_link = ethtool_op_get_link,
+};
+
void
kni_net_init(struct net_device *dev)
{
@@ -736,6 +749,7 @@ kni_net_init(struct net_device *dev)
ether_setup(dev); /* assign some of the fields */
dev->netdev_ops = &kni_net_netdev_ops;
dev->header_ops = &kni_net_header_ops;
+ dev->ethtool_ops = &kni_net_ethtool_ops;
dev->watchdog_timeo = WD_TIMEOUT;
}
--
2.20.1
Re: [dpdk-dev] [PATCH] eal: promote some service core functions to stable
On Thu, Jun 20, 2019 at 8:26 PM Aaron Conole wrote: > Gage Eads writes: > > > The functions rte_service_may_be_active(), rte_service_lcore_attr_get(), > > and rte_service_attr_reset_all() were introduced nearly a year ago in > DPDK > > 18.08. They can be considered non-experimental for the 19.08 release. > > > > rte_service_may_be_active() is used by eventdev and the sw PMD, and this > > commit allows them to not need any experimental API. > > > > Signed-off-by: Gage Eads > > --- > > drivers/event/sw/Makefile | 1 - > > drivers/event/sw/meson.build| 1 - > > lib/librte_eal/common/include/rte_service.h | 15 +++ > > lib/librte_eal/common/rte_service.c | 6 +++--- > > lib/librte_eal/rte_eal_version.map | 6 +++--- > > lib/librte_eventdev/Makefile| 1 - > > lib/librte_eventdev/meson.build | 1 - > > 7 files changed, 9 insertions(+), 22 deletions(-) > > > > diff --git a/drivers/event/sw/Makefile b/drivers/event/sw/Makefile > > index 81236a392..c6600e836 100644 > > --- a/drivers/event/sw/Makefile > > +++ b/drivers/event/sw/Makefile > > @@ -7,7 +7,6 @@ include $(RTE_SDK)/mk/rte.vars.mk > > LIB = librte_pmd_sw_event.a > > > > # build flags > > -CFLAGS += -DALLOW_EXPERIMENTAL_API > > CFLAGS += -O3 > > CFLAGS += $(WERROR_FLAGS) > > # for older GCC versions, allow us to initialize an event using > > diff --git a/drivers/event/sw/meson.build b/drivers/event/sw/meson.build > > index 30d221647..985012219 100644 > > --- a/drivers/event/sw/meson.build > > +++ b/drivers/event/sw/meson.build > > @@ -1,7 +1,6 @@ > > # SPDX-License-Identifier: BSD-3-Clause > > # Copyright(c) 2017 Intel Corporation > > > > -allow_experimental_apis = true > > I don't think you can remove these. There are still some experimental > APIs (f.e. the rename for rte_cryptodev_sym_session_get_private_data > marked that function as experimental and it will cause build breakage). > > Maybe I'm mis understanding it? It would be good to get verification > from Bruce whether that API should not be marked as experimental (it was > just a rename, so not sure...) - maybe that's a follow up for this > patch? > > See: https://travis-ci.com/ovsrobot/dpdk/jobs/209722145 for an example > > The odd thing is I only see it on the clang builds - perhaps it's a > missing definition for the clang compiler. > Erf, it looks like the __rte_experimental tag is affected by the order in the declaration of the symbol. --- a/lib/librte_cryptodev/rte_cryptodev.h +++ b/lib/librte_cryptodev/rte_cryptodev.h @@ -1245,7 +1245,7 @@ struct rte_cryptodev_asym_session * __rte_experimental * - On success return pointer to user data. * - On failure returns NULL. */ -void * __rte_experimental +__rte_experimental void * rte_cryptodev_sym_session_get_user_data( struct rte_cryptodev_sym_session *sess); With this, I get the proper warning... -- David Marchand
[dpdk-dev] [PATCH] vhost: log Virtio and Vhost-user negotiated features
Having this info logged by default when analysing bug reports
has proved to be useful.
Signed-off-by: Maxime Coquelin
---
lib/librte_vhost/vhost_user.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c
index c9e29ece8..370864865 100644
--- a/lib/librte_vhost/vhost_user.c
+++ b/lib/librte_vhost/vhost_user.c
@@ -284,6 +284,8 @@ vhost_user_set_features(struct virtio_net **pdev, struct
VhostUserMsg *msg,
} else {
dev->vhost_hlen = sizeof(struct virtio_net_hdr);
}
+ RTE_LOG(INFO, VHOST_CONFIG,
+ "Negotiated Virtio features: 0x%" PRIx64 "\n", dev->features);
VHOST_LOG_DEBUG(VHOST_CONFIG,
"(%d) mergeable RX buffers %s, virtio 1 %s\n",
dev->vid,
@@ -1406,6 +1408,9 @@ vhost_user_set_protocol_features(struct virtio_net **pdev,
}
dev->protocol_features = protocol_features;
+ RTE_LOG(INFO, VHOST_CONFIG,
+ "Negotiated Vhost-user protocol features: 0x%" PRIx64 "\n",
+ dev->protocol_features);
return RTE_VHOST_MSG_RESULT_OK;
}
--
2.21.0
Re: [dpdk-dev] [PATCH] eal: promote some service core functions to stable
On Thu, Jun 20, 2019 at 9:45 PM David Marchand wrote: > > > On Thu, Jun 20, 2019 at 8:26 PM Aaron Conole wrote: > >> Gage Eads writes: >> >> > The functions rte_service_may_be_active(), rte_service_lcore_attr_get(), >> > and rte_service_attr_reset_all() were introduced nearly a year ago in >> DPDK >> > 18.08. They can be considered non-experimental for the 19.08 release. >> > >> > rte_service_may_be_active() is used by eventdev and the sw PMD, and this >> > commit allows them to not need any experimental API. >> > >> > Signed-off-by: Gage Eads >> > --- >> > drivers/event/sw/Makefile | 1 - >> > drivers/event/sw/meson.build| 1 - >> > lib/librte_eal/common/include/rte_service.h | 15 +++ >> > lib/librte_eal/common/rte_service.c | 6 +++--- >> > lib/librte_eal/rte_eal_version.map | 6 +++--- >> > lib/librte_eventdev/Makefile| 1 - >> > lib/librte_eventdev/meson.build | 1 - >> > 7 files changed, 9 insertions(+), 22 deletions(-) >> > >> > diff --git a/drivers/event/sw/Makefile b/drivers/event/sw/Makefile >> > index 81236a392..c6600e836 100644 >> > --- a/drivers/event/sw/Makefile >> > +++ b/drivers/event/sw/Makefile >> > @@ -7,7 +7,6 @@ include $(RTE_SDK)/mk/rte.vars.mk >> > LIB = librte_pmd_sw_event.a >> > >> > # build flags >> > -CFLAGS += -DALLOW_EXPERIMENTAL_API >> > CFLAGS += -O3 >> > CFLAGS += $(WERROR_FLAGS) >> > # for older GCC versions, allow us to initialize an event using >> > diff --git a/drivers/event/sw/meson.build b/drivers/event/sw/meson.build >> > index 30d221647..985012219 100644 >> > --- a/drivers/event/sw/meson.build >> > +++ b/drivers/event/sw/meson.build >> > @@ -1,7 +1,6 @@ >> > # SPDX-License-Identifier: BSD-3-Clause >> > # Copyright(c) 2017 Intel Corporation >> > >> > -allow_experimental_apis = true >> >> I don't think you can remove these. There are still some experimental >> APIs (f.e. the rename for rte_cryptodev_sym_session_get_private_data >> marked that function as experimental and it will cause build breakage). >> >> Maybe I'm mis understanding it? It would be good to get verification >> from Bruce whether that API should not be marked as experimental (it was >> just a rename, so not sure...) - maybe that's a follow up for this >> patch? >> >> See: https://travis-ci.com/ovsrobot/dpdk/jobs/209722145 for an example >> >> The odd thing is I only see it on the clang builds - perhaps it's a >> missing definition for the clang compiler. >> > > Erf, it looks like the __rte_experimental tag is affected by the order in > the declaration of the symbol. > > --- a/lib/librte_cryptodev/rte_cryptodev.h > +++ b/lib/librte_cryptodev/rte_cryptodev.h > @@ -1245,7 +1245,7 @@ struct rte_cryptodev_asym_session * > __rte_experimental > * - On success return pointer to user data. > * - On failure returns NULL. > */ > -void * __rte_experimental > +__rte_experimental void * > rte_cryptodev_sym_session_get_user_data( > struct rte_cryptodev_sym_session > *sess); > > https://hastebin.com/micomogoqi.cs Does it mean that the "void *" type had been marked as deprecated with the previous syntax? Requesting compiler experts assistance :-) -- David Marchand
Re: [dpdk-dev] [PATCH v3 00/69] shared code update
On 6/20/2019 2:55 AM, Zhang, Qi Z wrote: > > >> -Original Message- >> From: Rong, Leyi >> Sent: Wednesday, June 19, 2019 11:18 PM >> To: Zhang, Qi Z >> Cc: dev@dpdk.org; Rong, Leyi >> Subject: [PATCH v3 00/69] shared code update >> >> Main changes: >> 1. Advanced switch rule support. >> 2. Add more APIs for tunnel management. >> 3. Add some minor features. >> 4. Code clean and bug fix. >> > > Acked-by: Qi Zhang > > Applied to dpdk-next-net-intel with below changes > > 1. patch 66 and 69 fixes patch 54, so merged to patch 54 > patch 64 fixes patch 06, so merged to patch 06 > so totally 66 patch merged. > 2. fix Camel title in patch 27, 39, > > Thanks > Qi There is a 32 bits build error, can you please check? In file included from .../dpdk/drivers/net/ice/base/ice_flow.c:6: .../dpdk/drivers/net/ice/base/ice_flow.c: In function ‘ice_flow_find_entry’: .../dpdk/drivers/net/ice/base/ice_flow.h:239:33: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] 239 | #define ICE_FLOW_ENTRY_HNDL(e) ((u64)e) | ^ .../dpdk/drivers/net/ice/base/ice_flow.c:1309:17: note: in expansion of macro ‘ICE_FLOW_ENTRY_HNDL’ 1309 | return found ? ICE_FLOW_ENTRY_HNDL(found) : ICE_FLOW_ENTRY_HANDLE_INVAL; | ^~~ .../dpdk/drivers/net/ice/base/ice_flow.c: In function ‘ice_flow_add_entry’: .../dpdk/drivers/net/ice/base/ice_flow.h:239:33: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] 239 | #define ICE_FLOW_ENTRY_HNDL(e) ((u64)e) | ^ .../dpdk/drivers/net/ice/base/ice_flow.c:1387:13: note: in expansion of macro ‘ICE_FLOW_ENTRY_HNDL’ 1387 | *entry_h = ICE_FLOW_ENTRY_HNDL(e); | ^~~ .../dpdk/drivers/net/ice/base/ice_flow.c: In function ‘ice_flow_rem_entry’: .../dpdk/drivers/net/ice/base/ice_flow.h:240:32: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] 240 | #define ICE_FLOW_ENTRY_PTR(h) ((struct ice_flow_entry *)(h)) |^ .../dpdk/drivers/net/ice/base/ice_flow.c:1413:10: note: in expansion of macro ‘ICE_FLOW_ENTRY_PTR’ 1413 | entry = ICE_FLOW_ENTRY_PTR(entry_h); | ^~ cc1: all warnings being treated as errors make[7]: *** [.../dpdk/mk/internal/rte.compile-pre.mk:114: ice_flow.o] Error 1 make[7]: *** Waiting for unfinished jobs In file included from .../dpdk/drivers/net/ice/base/ice_flex_pipe.c:8: .../dpdk/drivers/net/ice/base/ice_flex_pipe.c: In function ‘ice_free_flow_profs’: .../dpdk/drivers/net/ice/base/ice_flow.h:239:33: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] 239 | #define ICE_FLOW_ENTRY_HNDL(e) ((u64)e) | ^ .../dpdk/drivers/net/ice/base/ice_flex_pipe.c:3027:27: note: in expansion of macro ‘ICE_FLOW_ENTRY_HNDL’ 3027 |ice_flow_rem_entry(hw, ICE_FLOW_ENTRY_HNDL(e)); | ^~~ cc1: all warnings being treated as errors
[dpdk-dev] [PATCH v2] doc: add multi-proc shared lib mempool note
The mempool library assigns handler ops indexes based on the dynamic load
order of mempool handlers. Indexes are used so a mempool can be used by
multiple processes, but this only works if all processes agree on the
mapping from index to mempool handler.
When using the '-d' argument, it's possible for different processes to load
mempool handlers in different orders, and thus have different
index->handler mappings. Using a mempool in multiple of such processes will
result in undefined behavior.
This commit adds a note to the mempool library programmer's guide warning
users against this.
Fixes: 449c49b93a6b ("mempool: support handler operations")
Cc: sta...@dpdk.org
Signed-off-by: Gage Eads
Acked-by: Andrew Rybchenko
---
doc/guides/prog_guide/mempool_lib.rst | 8
1 file changed, 8 insertions(+)
v2: add another empty line
diff --git a/doc/guides/prog_guide/mempool_lib.rst
b/doc/guides/prog_guide/mempool_lib.rst
index 52a569f57..3bb84b0a6 100644
--- a/doc/guides/prog_guide/mempool_lib.rst
+++ b/doc/guides/prog_guide/mempool_lib.rst
@@ -133,6 +133,14 @@ For applications that use ``rte_pktmbuf_create()``, there
is a config setting
(``RTE_MBUF_DEFAULT_MEMPOOL_OPS``) that allows the application to make use of
an alternative mempool handler.
+ .. note::
+
+When running a DPDK application with shared libraries, mempool handler
+shared objects specified with the '-d' EAL command-line parameter are
+dynamically loaded. When running a multi-process application with shared
+libraries, the -d arguments for mempool handlers *must be specified in the
+same order for all processes* to ensure correct operation.
+
Use Cases
-
--
2.13.6
[dpdk-dev] [PATCH 2/2] net/netvsc: fix xstats for VF device
The id values for VF stats were not being offset correctly.
And getting xstats for VF device only worked if VF device supported
it; it did not support the generic stats.
Fixes: dc7680e8597c ("net/netvsc: support integrated VF")
Signed-off-by: Stephen Hemminger
---
drivers/net/netvsc/hn_ethdev.c | 2 +-
drivers/net/netvsc/hn_var.h| 2 +-
drivers/net/netvsc/hn_vf.c | 26 ++
3 files changed, 20 insertions(+), 10 deletions(-)
diff --git a/drivers/net/netvsc/hn_ethdev.c b/drivers/net/netvsc/hn_ethdev.c
index d37db7c6a232..2b1b2ba3b845 100644
--- a/drivers/net/netvsc/hn_ethdev.c
+++ b/drivers/net/netvsc/hn_ethdev.c
@@ -598,7 +598,7 @@ hn_dev_xstats_get(struct rte_eth_dev *dev,
}
}
- ret = hn_vf_xstats_get(dev, xstats + count, n - count);
+ ret = hn_vf_xstats_get(dev, xstats, count, n);
if (ret < 0)
return ret;
diff --git a/drivers/net/netvsc/hn_var.h b/drivers/net/netvsc/hn_var.h
index bf94d90a7635..be657af0982a 100644
--- a/drivers/net/netvsc/hn_var.h
+++ b/drivers/net/netvsc/hn_var.h
@@ -237,5 +237,5 @@ int hn_vf_xstats_get_names(struct rte_eth_dev *dev,
unsigned int size);
inthn_vf_xstats_get(struct rte_eth_dev *dev,
struct rte_eth_xstat *xstats,
-unsigned int n);
+unsigned int offset, unsigned int n);
void hn_vf_xstats_reset(struct rte_eth_dev *dev);
diff --git a/drivers/net/netvsc/hn_vf.c b/drivers/net/netvsc/hn_vf.c
index 27ac87e7e975..3a833d447ac1 100644
--- a/drivers/net/netvsc/hn_vf.c
+++ b/drivers/net/netvsc/hn_vf.c
@@ -506,17 +506,19 @@ int hn_vf_xstats_get_names(struct rte_eth_dev *dev,
struct hn_data *hv = dev->data->dev_private;
struct rte_eth_dev *vf_dev;
int i, count = 0;
- char tmp[RTE_ETH_XSTATS_NAME_SIZE];
rte_spinlock_lock(&hv->vf_lock);
vf_dev = hn_get_vf_dev(hv);
- if (vf_dev && vf_dev->dev_ops->xstats_get_names)
- count = vf_dev->dev_ops->xstats_get_names(vf_dev, names, n);
+ if (vf_dev)
+ count = rte_eth_xstats_get_names(vf_dev->data->port_id,
+names, n);
rte_spinlock_unlock(&hv->vf_lock);
/* add vf_ prefix to xstat names */
if (names) {
for (i = 0; i < count; i++) {
+ char tmp[RTE_ETH_XSTATS_NAME_SIZE];
+
snprintf(tmp, sizeof(tmp), "vf_%s", names[i].name);
strlcpy(names[i].name, tmp, sizeof(names[i].name));
}
@@ -527,18 +529,26 @@ int hn_vf_xstats_get_names(struct rte_eth_dev *dev,
int hn_vf_xstats_get(struct rte_eth_dev *dev,
struct rte_eth_xstat *xstats,
+unsigned int offset,
unsigned int n)
{
struct hn_data *hv = dev->data->dev_private;
struct rte_eth_dev *vf_dev;
- int count = 0;
+ int i, count = 0;
rte_spinlock_lock(&hv->vf_lock);
vf_dev = hn_get_vf_dev(hv);
- if (vf_dev && vf_dev->dev_ops->xstats_get)
- count = vf_dev->dev_ops->xstats_get(vf_dev, xstats, n);
+ if (vf_dev)
+ count = rte_eth_xstats_get(vf_dev->data->port_id,
+ xstats + offset, n - offset);
rte_spinlock_unlock(&hv->vf_lock);
+ /* Offset id's for VF stats */
+ if (count > 0) {
+ for (i = 0; i < count; i++)
+ xstats[i + offset].id += offset;
+ }
+
return count;
}
@@ -549,7 +559,7 @@ void hn_vf_xstats_reset(struct rte_eth_dev *dev)
rte_spinlock_lock(&hv->vf_lock);
vf_dev = hn_get_vf_dev(hv);
- if (vf_dev && vf_dev->dev_ops->xstats_reset)
- vf_dev->dev_ops->xstats_reset(vf_dev);
+ if (vf_dev)
+ rte_eth_xstats_reset(vf_dev->data->port_id);
rte_spinlock_unlock(&hv->vf_lock);
}
--
2.20.1
[dpdk-dev] [PATCH 0/2] net/netvsc: xstat fixes
A couple of fixes for the xstats functionality in netvsc PMD. Mohsin Mazhar Shaikh (1): net/netvsc: set id in xstats_get Stephen Hemminger (1): net/netvsc: fix xstats for VF device drivers/net/netvsc/hn_ethdev.c | 14 +- drivers/net/netvsc/hn_var.h| 2 +- drivers/net/netvsc/hn_vf.c | 26 ++ 3 files changed, 28 insertions(+), 14 deletions(-) -- 2.20.1
[dpdk-dev] [PATCH 1/2] net/netvsc: set id in xstats_get
From: Mohsin Mazhar Shaikh
The xstats_get was not setting id correctly for each entry.
Fixes: 4e9c73e96e83 ("net/netvsc: add Hyper-V network device")
Signed-off-by: Mohsin Mazhar Shaikh
Signed-off-by: Stephen Hemminger
---
drivers/net/netvsc/hn_ethdev.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/net/netvsc/hn_ethdev.c b/drivers/net/netvsc/hn_ethdev.c
index 9e7cf2df5472..d37db7c6a232 100644
--- a/drivers/net/netvsc/hn_ethdev.c
+++ b/drivers/net/netvsc/hn_ethdev.c
@@ -577,9 +577,11 @@ hn_dev_xstats_get(struct rte_eth_dev *dev,
continue;
stats = (const char *)&txq->stats;
- for (t = 0; t < RTE_DIM(hn_stat_strings); t++)
- xstats[count++].value = *(const uint64_t *)
+ for (t = 0; t < RTE_DIM(hn_stat_strings); t++, count++) {
+ xstats[count].id = count;
+ xstats[count].value = *(const uint64_t *)
(stats + hn_stat_strings[t].offset);
+ }
}
for (i = 0; i < dev->data->nb_rx_queues; i++) {
@@ -589,9 +591,11 @@ hn_dev_xstats_get(struct rte_eth_dev *dev,
continue;
stats = (const char *)&rxq->stats;
- for (t = 0; t < RTE_DIM(hn_stat_strings); t++)
- xstats[count++].value = *(const uint64_t *)
+ for (t = 0; t < RTE_DIM(hn_stat_strings); t++, count++) {
+ xstats[count].id = count;
+ xstats[count].value = *(const uint64_t *)
(stats + hn_stat_strings[t].offset);
+ }
}
ret = hn_vf_xstats_get(dev, xstats + count, n - count);
--
2.20.1
Re: [dpdk-dev] [PATCH] Revert "net/mlx: support IOVA VA mode"
On Fri, 7 Jun 2019 16:08:41 -0700 Stephen Hemminger wrote: > From: Stephen Hemminger > > This reverts commit 69c06d0e357ed0064b498d510d169603cf7308cd. > That commit breaks support for netvsc PMD with MLX SRIOV > on both Hyper-V and Azure. > > Signed-off-by: Stephen Hemminger Could one of the MLX maintainers review this. DPDK 19.08 is broken right now on Hyper-V/Azure.
Re: [dpdk-dev] [PATCH v7 1/3] baseband/turbo_sw: option to build turbosw PMD without SDK
> -Original Message- > From: Chautru, Nicolas > Sent: Wednesday 19 June 2019 18:49 > To: akhil.go...@nxp.com; dev@dpdk.org > Cc: Yigit, Ferruh ; tho...@monjalon.net; > Mokhtar, Amr ; Chalupnik, KamilX > ; acon...@redhat.com; Chautru, Nicolas > > Subject: [PATCH v7 1/3] baseband/turbo_sw: option to build turbosw PMD > without SDK > > Adding compile flag to allow to build the turbo_sw PMD > without dependency to have the SDK libraries installed. > > Signed-off-by: Nicolas Chautru > --- Acked-by: Amr Mokhtar
Re: [dpdk-dev] [PATCH 00/28] vhost: add virtio-vhost-user transport
On 20/6/19 2:32 μ.μ., Ilya Maximets wrote: > On 19.06.2019 18:14, Nikos Dragazis wrote: >> Hi everyone, > Hi. I didn't look at the code, just a few comments inline. > >> this patch series introduces the concept of the virtio-vhost-user >> transport. This is actually a revised version of an earlier RFC >> implementation that has been proposed by Stefan Hajnoczi [1]. Though >> this is a great feature, it seems to have been stalled, so I’d like to >> restart the conversation on this and hopefully get it merged with your >> help. Let me give you an overview. >> >> The virtio-vhost-user transport is a vhost-user transport implementation >> that is based on the virtio-vhost-user device. Its key difference with >> the existing transport is that it allows deploying vhost-user targets >> inside dedicated Storage Appliance VMs instead of host user space. In >> other words, it allows having guests that act as vhost-user backends for >> other guests. >> >> The virtio-vhost-user device implements the vhost-user control plane >> (master-slave communication) as follows: >> >> 1. it parses the vhost-user messages from the vhost-user unix domain >>socket and forwards them to the slave guest through virtqueues >> >> 2. it maps the vhost memory regions in QEMU’s process address space and >>exposes them to the slave guest as a RAM-backed PCI MMIO region >> >> 3. it hooks up doorbells to the callfds. The slave guest can use these >>doorbells to interrupt the master guest driver >> >> The device code has not yet been merged into upstream QEMU, but this is >> definitely the end goal. The current state is that we are awaiting for >> the approval of the virtio spec. >> >> I have Cced Darek from the SPDK community who has helped me a lot by >> reviewing this series. Note that any device type could be implemented >> over this new transport. So, adding the virtio-vhost-user transport in >> DPDK would allow using it from SPDK as well. >> >> Getting into the code internals, this patch series makes the following >> changes: >> >> 1. introduce a generic interface for the transport-specific operations. >>Each of the two available transports, the pre-existing AF_UNIX >>transport and the virtio-vhost-user transport, is going to implement >>this interface. The AF_UNIX-specific code has been extracted from the >>core vhost-user code and is now part of the AF_UNIX transport >>implementation in trans_af_unix.c. >> >> 2. introduce the virtio-vhost-user transport. The virtio-vhost-user >>transport requires a driver for the virtio-vhost-user devices. The >>driver along with the transport implementation have been packed into >>a separate library in `drivers/virtio_vhost_user/`. The necessary >>virtio-pci code has been copied from `drivers/net/virtio/`. Some >>additional changes have been made so that the driver can utilize the >>additional resources of the virtio-vhost-user device. >> >> 3. update librte_vhost public API to enable choosing transport for each >>new vhost device. Extend the vhost net driver and vhost-scsi example >>application to export this new API to the end user. >> >> The primary changes I did to Stefan’s RFC implementation are the >> following: >> >> 1. moved postcopy live migration code into trans_af_unix.c. Postcopy >>live migration relies on the userfault fd mechanism, which cannot be >>supported by virtio-vhost-user. >> >> 2. moved setup of the log memory region into trans_af_unix.c. Setting up >>the log memory region involves mapping/unmapping guest memory. This >>is an AF_UNIX transport-specific operation. > Logging dirty pages is the main concept of live migration support. Does it > mean that the live migration is not supported for virtio-vhost-user at all? No, it is supported. To be more precise, it can be supported, it is part of the on-going virtio device specification: https://lists.oasis-open.org/archives/virtio-dev/201905/msg00022.html and it is in my TODO list for the device code. Here is how it works: the log memory region, just like the other vhost memory regions, is a portion of the master guest memory. In case of the AF_UNIX transport, the master sends a VHOST_USER_SET_LOG_BASE message and the vhost target mmaps the log memory region into the process' virtual address space. In case of the virtio-vhost-user transport, the virtio-vhost-user device parses the VHOST_USER_SET_LOG_BASE message and maps the log memory region into QEMU's process address space. It then exposes the log memory region to the slave guest as a RAM-backed PCI MMIO region. So, from the vhost target's viewpoint, the only difference is the means of accessing the log memory region. In case of the AF_UNIX transport, the vhost target receives a file descriptor and mmaps this file. In case of the virtio-vhost-user transport, the device exports the log memory region to the vhost target (running in slave guest user space) via an MMIO BAR. To recap, just to make sure
[dpdk-dev] [PATCH v4 2/5] raw/ifpga_rawdev: fix logically dead code
add temporary variable in max10_reg_write().
Coverity issue: 337927
Fixes: 96ebfcf ("raw/ifpga/base: add SPI and MAX10 device driver")
Cc: sta...@dpdk.org
Signed-off-by: Tianfei zhang
Acked-by: Rosen Xu
---
drivers/raw/ifpga_rawdev/base/opae_intel_max10.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/raw/ifpga_rawdev/base/opae_intel_max10.c
b/drivers/raw/ifpga_rawdev/base/opae_intel_max10.c
index f354ee4b6..3ff6575d7 100644
--- a/drivers/raw/ifpga_rawdev/base/opae_intel_max10.c
+++ b/drivers/raw/ifpga_rawdev/base/opae_intel_max10.c
@@ -17,11 +17,13 @@ int max10_reg_read(unsigned int reg, unsigned int *val)
int max10_reg_write(unsigned int reg, unsigned int val)
{
+ unsigned int tmp = val;
+
if (!g_max10)
return -ENODEV;
return spi_transaction_write(g_max10->spi_tran_dev,
- reg, 4, (unsigned char *)&val);
+ reg, 4, (unsigned char *)&tmp);
}
struct intel_max10_device *
@@ -57,7 +59,7 @@ intel_max10_device_probe(struct altera_spi_device *spi,
/* set PKVL Polling manually in BBS */
ret = max10_reg_write(PKVL_POLLING_CTRL, 0x3);
- if (ret) {
+ if (ret != 0) {
dev_err(dev, "%s set PKVL polling fail\n", __func__);
goto spi_tran_fail;
}
--
2.17.1
Re: [dpdk-dev] [RFC] ethdev: reserve the RX offload most-significant bits for PMD scartch
Hi > -Original Message- > From: Stephen Hemminger [mailto:step...@networkplumber.org] > Sent: Friday, June 21, 2019 02:36 > To: Wang, Haiyue > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [RFC] ethdev: reserve the RX offload most-significant > bits for PMD scartch > > On Thu, 20 Jun 2019 15:25:52 +0800 > Haiyue Wang wrote: > > > Generally speaking, the DEV_RX_OFFLOAD_xxx for RX offload capabilities > > of a device is one-bit field definition, it has 64 different values at > > most. > > > > Nowdays the receiving queue of NIC has rich features not just checksum > > offload, like it can extract the network protocol header fields to its > > RX descriptors for quickly handling. But this kind of feature is not so > > common, and it is hardware related. Normally, this can be done through > > rte_devargs driver parameters, but the scope is per device. This is not > > so nice for per queue design. > > > > The per queue API 'rte_eth_rx_queue_setup' and data structure 'struct > > rte_eth_rxconf' are stable now, and be common for all PMDs. For keeping > > the ethdev API & ABI compatibility, and the application can make good > > use of the NIC's specific features, reserving the most-significant bits > > of RX offload seems an compromise method. > > > > Then the PMDs redefine these bits as they want, all PMDs share the same > > bit positions and expose their new definitions with the header file. > > > > The experimental reserved bits number is 6 currently. Tt can be one-bit > > for each features up to the the maximum number 6. It can also be some > > bits encoding: e.g, 6 bits can stand for 63 maximum number of features. > > > > We call these reserved bits as DEV_RX_OFFLOAD_PMD_SCRATCH. And the left > > unused bits number is : 64 - 19 (currently defined) - 6 (PMD scartch) = > > 39. > > > > This is not so nice for applications, they need to check PMD's driver > > name for lookuping their DEV_RX_OFFLOAD_PMD_SCRATCH definitions. But it > > is good for the applications to make use of the hardware compatibility. > > > > Signed-off-by: Haiyue Wang > > --- > > Anything that is per device type is useless for a generic application. > The goal of the DPDK should be to provide a high performance platform > that works for many device types. Too often, I see patches from hardware > vendors that are just "we can enable are cool proprietary hardware > feature in DPDK". This would just encourage that bad practice. Understand the DPDK's dream. :) This patch wants to make the bad application and bad vender to use the DPDK's generic high performance platform features, plus some bad practice like doing special hardware optimization. Very appreciate your feedback. The PMDs should limit their desires. ;-)
[dpdk-dev] [PATCH v4 3/5] raw/ifpga_rawdev/base: fix bit fields definition
Fix CTRL_DEV_SELECT bit fields definition about eth_group devices.
Fixes: 8a256bef32 ("raw/ifpga/base: add eth group driver")
Cc: sta...@dpdk.org
Signed-off-by: Tianfei zhang
Acked-by: Rosen Xu
---
drivers/raw/ifpga_rawdev/base/opae_eth_group.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/raw/ifpga_rawdev/base/opae_eth_group.h
b/drivers/raw/ifpga_rawdev/base/opae_eth_group.h
index 8d695cc8e..a66d77e27 100644
--- a/drivers/raw/ifpga_rawdev/base/opae_eth_group.h
+++ b/drivers/raw/ifpga_rawdev/base/opae_eth_group.h
@@ -31,7 +31,7 @@
#define CMD_NOP0ULL
#define CMD_RD 1ULL
#define CMD_WR 2ULL
-#define CTRL_DEV_SELECTGENMASK_ULL(52, 49)
+#define CTRL_DEV_SELECTGENMASK_ULL(53, 49)
#define CTRL_DS_SHIFT 49
#define CTRL_FEAT_SELECT BIT_ULL(48)
#define SELECT_IP 0
--
2.17.1
[dpdk-dev] [PATCH v4 1/5] raw/ifpga_rawdev: fix use of untrusted scalar value
Add checking the buffer size and use
const char * for buffer declaration.
Coverity issue: 279449
Fixes: ef1e8ede ("raw/ifpga: add Intel FPGA bus rawdev driver")
Cc: sta...@dpdk.org
Signed-off-by: Tianfei zhang
Acked-by: Rosen Xu
---
drivers/raw/ifpga_rawdev/base/ifpga_api.c | 4 +--
drivers/raw/ifpga_rawdev/base/ifpga_api.h | 2 +-
.../raw/ifpga_rawdev/base/ifpga_feature_dev.h | 2 +-
drivers/raw/ifpga_rawdev/base/ifpga_fme_pr.c | 27 +++
drivers/raw/ifpga_rawdev/base/opae_hw_api.c | 4 +--
drivers/raw/ifpga_rawdev/base/opae_hw_api.h | 4 +--
drivers/raw/ifpga_rawdev/ifpga_rawdev.c | 7 -
7 files changed, 30 insertions(+), 20 deletions(-)
diff --git a/drivers/raw/ifpga_rawdev/base/ifpga_api.c
b/drivers/raw/ifpga_rawdev/base/ifpga_api.c
index 3ddbcdc2a..53d101daf 100644
--- a/drivers/raw/ifpga_rawdev/base/ifpga_api.c
+++ b/drivers/raw/ifpga_rawdev/base/ifpga_api.c
@@ -182,7 +182,7 @@ struct opae_bridge_ops ifpga_br_ops = {
};
/* Manager APIs */
-static int ifpga_mgr_flash(struct opae_manager *mgr, int id, void *buf,
+static int ifpga_mgr_flash(struct opae_manager *mgr, int id, const char *buf,
u32 size, u64 *status)
{
struct ifpga_fme_hw *fme = mgr->data;
@@ -324,7 +324,7 @@ struct opae_adapter_ops ifpga_adapter_ops = {
* - 0: Success, partial reconfiguration finished.
* - <0: Error code returned in partial reconfiguration.
**/
-int ifpga_pr(struct ifpga_hw *hw, u32 port_id, void *buffer, u32 size,
+int ifpga_pr(struct ifpga_hw *hw, u32 port_id, const char *buffer, u32 size,
u64 *status)
{
if (!is_valid_port_id(hw, port_id))
diff --git a/drivers/raw/ifpga_rawdev/base/ifpga_api.h
b/drivers/raw/ifpga_rawdev/base/ifpga_api.h
index 4a247698c..051ab8276 100644
--- a/drivers/raw/ifpga_rawdev/base/ifpga_api.h
+++ b/drivers/raw/ifpga_rawdev/base/ifpga_api.h
@@ -23,7 +23,7 @@ int ifpga_set_irq(struct ifpga_hw *hw, u32 fiu_id, u32
port_id,
u32 feature_id, void *irq_set);
/* FME APIs */
-int ifpga_pr(struct ifpga_hw *hw, u32 port_id, void *buffer, u32 size,
+int ifpga_pr(struct ifpga_hw *hw, u32 port_id, const char *buffer, u32 size,
u64 *status);
#endif /* _IFPGA_API_H_ */
diff --git a/drivers/raw/ifpga_rawdev/base/ifpga_feature_dev.h
b/drivers/raw/ifpga_rawdev/base/ifpga_feature_dev.h
index bb9fcc289..e243d4273 100644
--- a/drivers/raw/ifpga_rawdev/base/ifpga_feature_dev.h
+++ b/drivers/raw/ifpga_rawdev/base/ifpga_feature_dev.h
@@ -149,7 +149,7 @@ static inline int fpga_port_reset(struct ifpga_port_hw
*port)
return ret;
}
-int do_pr(struct ifpga_hw *hw, u32 port_id, void *buffer, u32 size,
+int do_pr(struct ifpga_hw *hw, u32 port_id, const char *buffer, u32 size,
u64 *status);
int fme_get_prop(struct ifpga_fme_hw *fme, struct feature_prop *prop);
diff --git a/drivers/raw/ifpga_rawdev/base/ifpga_fme_pr.c
b/drivers/raw/ifpga_rawdev/base/ifpga_fme_pr.c
index efa72660f..9997942d2 100644
--- a/drivers/raw/ifpga_rawdev/base/ifpga_fme_pr.c
+++ b/drivers/raw/ifpga_rawdev/base/ifpga_fme_pr.c
@@ -223,8 +223,8 @@ static int fpga_pr_buf_load(struct ifpga_fme_hw *fme_dev,
return 0;
}
-static int fme_pr(struct ifpga_hw *hw, u32 port_id, void *buffer, u32 size,
- u64 *status)
+static int fme_pr(struct ifpga_hw *hw, u32 port_id, const char *buffer,
+ u32 size, u64 *status)
{
struct feature_fme_header *fme_hdr;
struct feature_fme_capability fme_capability;
@@ -269,7 +269,7 @@ static int fme_pr(struct ifpga_hw *hw, u32 port_id, void
*buffer, u32 size,
/* Disable Port before PR */
fpga_port_disable(port);
- ret = fpga_pr_buf_load(fme, &info, (void *)buffer, size);
+ ret = fpga_pr_buf_load(fme, &info, buffer, size);
*status = info.pr_err;
@@ -280,27 +280,32 @@ static int fme_pr(struct ifpga_hw *hw, u32 port_id, void
*buffer, u32 size,
return ret;
}
-int do_pr(struct ifpga_hw *hw, u32 port_id, void *buffer, u32 size, u64
*status)
+int do_pr(struct ifpga_hw *hw, u32 port_id, const char *buffer,
+ u32 size, u64 *status)
{
- struct bts_header *bts_hdr;
- void *buf;
+ const struct bts_header *bts_hdr;
+ const char *buf;
struct ifpga_port_hw *port;
int ret;
+ u32 header_size;
if (!buffer || size == 0) {
dev_err(hw, "invalid parameter\n");
return -EINVAL;
}
- bts_hdr = (struct bts_header *)buffer;
+ bts_hdr = (const struct bts_header *)buffer;
if (is_valid_bts(bts_hdr)) {
dev_info(hw, "this is a valid bitsteam..\n");
- size -= (sizeof(struct bts_header) +
-bts_hdr->metadata_len);
- buf = (u8 *)buffer + sizeof(struct bts_header) +
- bts_hdr->metadata_len;
+ header_size = sizeof(struct bts_hea
[dpdk-dev] [PATCH v4 5/5] raw/ifpga_rawdev/base: fix retimer link status issue
Fix the readout retimer link status incorrectly when we
remove the linux intel-fpga-driver and run the DPDK application.
The linux driver will stop the retimer when remove the kernel
modules.
Fixes: 8a256bef ("raw/ifpga/base: add eth group driver")
Cc: sta...@dpdk.org
Reported-by: Sampath Amrutha
Signed-off-by: Tianfei zhang
---
.../raw/ifpga_rawdev/base/opae_eth_group.c| 172 ++
.../raw/ifpga_rawdev/base/opae_eth_group.h| 6 +
.../raw/ifpga_rawdev/base/opae_intel_max10.c | 7 -
3 files changed, 178 insertions(+), 7 deletions(-)
diff --git a/drivers/raw/ifpga_rawdev/base/opae_eth_group.c
b/drivers/raw/ifpga_rawdev/base/opae_eth_group.c
index 8db6693b1..d189dd578 100644
--- a/drivers/raw/ifpga_rawdev/base/opae_eth_group.c
+++ b/drivers/raw/ifpga_rawdev/base/opae_eth_group.c
@@ -113,6 +113,171 @@ int eth_group_read_reg(struct eth_group_device *dev,
return 0;
}
+static int eth_group_reset_mac(struct eth_group_device *dev, u8 index,
+ bool enable)
+{
+ u32 val;
+ int ret;
+
+ /*
+* only support 25G & 40G mac reset for now. It uses internal reset.
+* as PHY and MAC are integrated together, below action will trigger
+* PHY reset too.
+*/
+ if (dev->speed != 25 && dev->speed != 40)
+ return 0;
+
+ ret = eth_group_read_reg(dev, ETH_GROUP_MAC, index, MAC_CONFIG,
+&val);
+ if (ret) {
+ dev_err(dev, "fail to read PHY_CONFIG: %d\n", ret);
+ return ret;
+ }
+
+ /* skip if mac is in expected state already */
+ if val & MAC_RESET_MASK) == MAC_RESET_MASK) && enable) ||
+ (((val & MAC_RESET_MASK) == 0) && !enable))
+ return 0;
+
+ if (enable)
+ val |= MAC_RESET_MASK;
+ else
+ val &= ~MAC_RESET_MASK;
+
+ ret = eth_group_write_reg(dev, ETH_GROUP_MAC, index, MAC_CONFIG,
+ val);
+ if (ret)
+ dev_err(dev, "fail to write PHY_CONFIG: %d\n", ret);
+
+ return ret;
+}
+
+static void eth_group_mac_uinit(struct eth_group_device *dev)
+{
+ u8 i;
+
+ for (i = 0; i < dev->mac_num; i++) {
+ if (eth_group_reset_mac(dev, i, true))
+ dev_err(dev, "fail to disable mac %d\n", i);
+ }
+}
+
+static int eth_group_mac_init(struct eth_group_device *dev)
+{
+ int ret;
+ u8 i;
+
+ for (i = 0; i < dev->mac_num; i++) {
+ ret = eth_group_reset_mac(dev, i, false);
+ if (ret) {
+ dev_err(dev, "fail to enable mac %d\n", i);
+ goto exit;
+ }
+ }
+
+ return 0;
+
+exit:
+ while (i--)
+ eth_group_reset_mac(dev, i, true);
+
+ return ret;
+}
+
+static int eth_group_reset_phy(struct eth_group_device *dev, u8 index,
+ bool enable)
+{
+ u32 val;
+ int ret;
+
+ /* only support 10G PHY reset for now. It uses external reset. */
+ if (dev->speed != 10)
+ return 0;
+
+ ret = eth_group_read_reg(dev, ETH_GROUP_PHY, index,
+ ADD_PHY_CTRL, &val);
+ if (ret) {
+ dev_err(dev, "fail to read ADD_PHY_CTRL reg: %d\n", ret);
+ return ret;
+ }
+
+ /* return if PHY is already in expected state */
+ if ((val & PHY_RESET && enable) || (!(val & PHY_RESET) && !enable))
+ return 0;
+
+ if (enable)
+ val |= PHY_RESET;
+ else
+ val &= ~PHY_RESET;
+
+ ret = eth_group_write_reg(dev, ETH_GROUP_PHY, index,
+ ADD_PHY_CTRL, val);
+ if (ret)
+ dev_err(dev, "fail to write ADD_PHY_CTRL reg: %d\n", ret);
+
+ return ret;
+}
+
+static int eth_group_phy_init(struct eth_group_device *dev)
+{
+ int ret;
+ int i;
+
+ for (i = 0; i < dev->phy_num; i++) {
+ ret = eth_group_reset_phy(dev, i, false);
+ if (ret) {
+ dev_err(dev, "fail to enable phy %d\n", i);
+ goto exit;
+ }
+ }
+
+ return 0;
+exit:
+ while (i--)
+ eth_group_reset_phy(dev, i, true);
+
+ return ret;
+}
+
+static void eth_group_phy_uinit(struct eth_group_device *dev)
+{
+ int i;
+
+ for (i = 0; i < dev->phy_num; i++) {
+ if (eth_group_reset_phy(dev, i, true))
+ dev_err(dev, "fail to disable phy %d\n", i);
+ }
+}
+
+static int eth_group_hw_init(struct eth_group_device *dev)
+{
+ int ret;
+
+ ret = eth_group_phy_init(dev);
+ if (ret) {
+ dev_err(dev, "fail to init eth group phys\n");
+ return ret;
+ }
+
+ ret = eth_group_mac_init(dev);
+ if (ret) {
+ dev_err(priv->dev, "fail to init eth gr
[dpdk-dev] [PATCH v4 4/5] raw/ifpga_rawdev/base: fix miss physical address
Fix miss phy_addr on ifpga_acc_get_region_info() function.
Fixes: 56bb54ea1bd ("raw/ifpga/base: add Intel FPGA OPAE share code")
Cc: sta...@dpdk.org
Signed-off-by: Tianfei zhang
Acked-by: Rosen Xu
---
drivers/raw/ifpga_rawdev/base/ifpga_api.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/raw/ifpga_rawdev/base/ifpga_api.c
b/drivers/raw/ifpga_rawdev/base/ifpga_api.c
index 53d101daf..7ae626d64 100644
--- a/drivers/raw/ifpga_rawdev/base/ifpga_api.c
+++ b/drivers/raw/ifpga_rawdev/base/ifpga_api.c
@@ -76,6 +76,7 @@ static int ifpga_acc_get_region_info(struct opae_accelerator
*acc,
info->flags = ACC_REGION_READ | ACC_REGION_WRITE | ACC_REGION_MMIO;
info->len = afu_info->region[info->index].len;
info->addr = afu_info->region[info->index].addr;
+ info->phys_addr = afu_info->region[info->index].phys_addr;
return 0;
}
--
2.17.1
