[dpdk-dev] [PATCH 0/4] Translate packet types for i40e
> -Original Message- > From: Ananyev, Konstantin > Sent: Tuesday, November 18, 2014 11:26 PM > To: Zhang, Helin; Liu, Jijiang; dev at dpdk.org > Subject: RE: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e > > > > > -Original Message- > > From: Zhang, Helin > > Sent: Tuesday, November 18, 2014 2:12 PM > > To: Ananyev, Konstantin; Liu, Jijiang; dev at dpdk.org > > Subject: RE: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e > > > > > > > > > -Original Message- > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ananyev, > > > Konstantin > > > Sent: Tuesday, November 18, 2014 7:33 PM > > > To: Liu, Jijiang; dev at dpdk.org > > > Subject: Re: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e > > > > > > Hi Frank, > > > > > > > -Original Message- > > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jijiang Liu > > > > Sent: Tuesday, November 18, 2014 7:37 AM > > > > To: dev at dpdk.org > > > > Subject: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e > > > > > > > > The i40e NIC can recognize many packet types, including ordinary > > > > L2 packet format and tunneling packet format such as IP in IP, IP > > > > in GRE, MAC in > > > GRE and MAC in UDP. > > > > > > > > This patch set provides abstract definitions of packet types, > > > > which can help user to use these packet types directly in their > > > > applications to speed > > > up receive packet analysis. > > > > > > > > Moreover, this patch set translates i40e packet types to abstract > > > > packet types in i40e driver, and make the corresponding changes in > > > > test > > > applications. > > > > > > > > Jijiang Liu (4): > > > > Add packet type and IP header check in rte_mbuf > > > > Remove the PKT_RX_TUNNEL_IPV4_HDR and the > > > PKT_RX_TUNNEL_IPV6_HDR > > > > Translate i40e packet types > > > > Make the corresponding changes in test-pmd > > > > > > > > app/test-pmd/csumonly.c | 12 +- > > > > app/test-pmd/rxonly.c | 15 +- > > > > lib/librte_mbuf/rte_mbuf.h | 225 ++- > > > > lib/librte_pmd_i40e/i40e_rxtx.c | 604 > > > > +-- > > > > 4 files changed, 569 insertions(+), 287 deletions(-) > > > > > > > > > > The patch looks good to me in general. > > > Though I think it is not complete: we need to make sure that all > > > PMDs RX functions will set mbuf's packet_type to the defined value. > > We met quite a lot of similar situations, we designed a new way for > > i40e, then have to rework igb/ixgbe. E.g. configuring reta, flow director, > > etc. > > If possible, send the patch set as smaller as possible might be > > better. I guess igb/ixgbe will be done soon later. > > > > > As right now, only i40e implementation can distinguish packet_type > > > properly, I think all other PMDs for the freshly received packet should > > > do: > > > mbuf->packet_type = RTE_PTYPE_UNDEF; > > If I am not wrong, RTE_PTYPE_UNDEF can be 0, is packet_type in mbuf > initialized to 0? > > Yes RTE_PTYPE_UNDEF == 0 > > > If yes, nothing needs to be done in igb/ixgbe for now. > > Could you explain to me why is that? > As I remember none of our RX functions reset the whole mbuf to all zeroes. > None of them even call rte_pktmbuf_reset() for performance reasons. > So what/who would prevent reset packet_type of the freshly received > packet_type to zero? So mbuf header fields are not zero-ed by default? That might not be what I guessed. > BTW, I think that rte_pktmbuf_reset() need to reset packet_type too. > > > > > > > > > Another thing: right now mbuf's packet_type is uint16_t. > > > While enum rte_eth_packet_type will be interpreted by the compiler as > > > 'int' > > > (32bits). > > > We can either change enum to a lot of defines (which I don't really > > > like to do) or probably just add a comment somewhere that enum > > > rte_eth_packet_type should never exceed UINT16_MAX value? > > > > > > Konstantin > > > > > > > -- > > > > 1.7.7.6 > > > > Regards, > > Helin
[dpdk-dev] [PATCH v4 3/5] hash: add fallback to software CRC32 implementation
19.11.2014 3:36, Neil Horman ?: > On Tue, Nov 18, 2014 at 05:52:27PM +, Bruce Richardson wrote: >> On Tue, Nov 18, 2014 at 12:46:19PM -0500, Neil Horman wrote: >>> On Tue, Nov 18, 2014 at 11:13:17PM +0600, Yerden Zhumabekov wrote: Everybody's up for the second option? :) >>> Crud, you're right, I didn't think about the header inclusion issue. Is it >>> worth adding the jump to enable the dynamic hash selection? >>> Neil >> Maybe for cases where SSE4.2 is not currently available, i.e. for generic >> builds. >> For builds where we have hardware support confirmed at compile time, just use >> the function from the header file. >> Does that make sense? >> > I'm not certain of that, as I don't think anything can be 'confirmed' at > compile > time. I.e. just because you have sse42 at compile time doesn't guarantee you > have it at run time with a DSO. If you have these as macros, you need to > enable > sse42 whereever you include the file so that the intrinsic works properly. > > an alternate option would be to not use the intrinsic, and craft some explicit > __asm__ statement that executes the right sse42 instructions. That way the > asm > is directly emitted, without requiring the -msse42 flag at all, and it will > just > work in all the files that call it. Thanks for the discussion. To summarize it with my suggestions for 'v5': 1) replace intrinsics with asm code and give up including nmmintrin.h; 2) detect arch (EM64T flag) on runtime because crc32 for 64-bit operand doesn't work on 32-bit x86; 3) separate function prototypes (leaving them in header) and bodies, add to SRCS in Makefile. -- Sincerely, Yerden Zhumabekov State Technical Service Astana, KZ
[dpdk-dev] [PATCH v4 3/5] hash: add fallback to software CRC32 implementation
18.11.2014 23:29, Wang, Shawn ?: > I have a general question about using CPUID to detect supported instruction > set. > What if we are compiling the software with some old hardware which does not > support SSE4.2, but run it on new hardware which does support SSE4.2. Is > there still a static way to force the compiler to turn on the SSE4.2 support? > I guess for SSE4.2, most of the CPU has support for it now. But for AVX2, > this might not be the case. According to gcc 4.7 changes (https://gcc.gnu.org/gcc-4.7/changes.html) they've added support for AVX2 instructions since that version. Use -mavx2 or -march=core-avx2. The latter seems to be supported by ICC as well, according to Google :) -- Sincerely, Yerden Zhumabekov State Technical Service Astana, KZ
[dpdk-dev] [PATCH] i40e: fixed tx stats bug
From: zzang Fixed tx stats bug in i40e Signed-off-by: zzang --- lib/librte_pmd_i40e/i40e_ethdev.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/lib/librte_pmd_i40e/i40e_ethdev.c b/lib/librte_pmd_i40e/i40e_ethdev.c index 4b7a827..e01590c 100644 --- a/lib/librte_pmd_i40e/i40e_ethdev.c +++ b/lib/librte_pmd_i40e/i40e_ethdev.c @@ -1102,6 +1102,7 @@ i40e_dev_stats_get(struct rte_eth_dev *dev, struct rte_eth_stats *stats) struct i40e_hw *hw = I40E_DEV_PRIVATE_TO_HW(dev->data->dev_private); struct i40e_hw_port_stats *ns = &pf->stats; /* new stats */ struct i40e_hw_port_stats *os = &pf->stats_offset; /* old stats */ + struct i40e_eth_stats *ves = &pf->main_vsi->eth_stats; /* vsi stats */ /* Get statistics of struct i40e_eth_stats */ i40e_stat_update_48(hw, I40E_GLPRT_GORCH(hw->port), @@ -1284,8 +1285,8 @@ i40e_dev_stats_get(struct rte_eth_dev *dev, struct rte_eth_stats *stats) stats->ipackets = ns->eth.rx_unicast + ns->eth.rx_multicast + ns->eth.rx_broadcast; - stats->opackets = ns->eth.tx_unicast + ns->eth.tx_multicast + - ns->eth.tx_broadcast; + stats->opackets = ves->tx_unicast + ves->tx_multicast + + ves->tx_broadcast; stats->ibytes = ns->eth.rx_bytes; stats->obytes = ns->eth.tx_bytes; stats->oerrors = ns->eth.tx_errors; -- 1.9.3
[dpdk-dev] [PATCH] i40e: fixed tx stats bug
On 11/19/2014 4:43 PM, zhida zang wrote: > From: zzang > > Fixed tx stats bug in i40e Would you mind to give more details about this bug in the commit log? This can really help reviewer to get the initial idea about your patch without go through the code it self. Thanks, Michael > > Signed-off-by: zzang > --- > lib/librte_pmd_i40e/i40e_ethdev.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/lib/librte_pmd_i40e/i40e_ethdev.c > b/lib/librte_pmd_i40e/i40e_ethdev.c > index 4b7a827..e01590c 100644 > --- a/lib/librte_pmd_i40e/i40e_ethdev.c > +++ b/lib/librte_pmd_i40e/i40e_ethdev.c > @@ -1102,6 +1102,7 @@ i40e_dev_stats_get(struct rte_eth_dev *dev, struct > rte_eth_stats *stats) > struct i40e_hw *hw = I40E_DEV_PRIVATE_TO_HW(dev->data->dev_private); > struct i40e_hw_port_stats *ns = &pf->stats; /* new stats */ > struct i40e_hw_port_stats *os = &pf->stats_offset; /* old stats */ > + struct i40e_eth_stats *ves = &pf->main_vsi->eth_stats; /* vsi stats */ > > /* Get statistics of struct i40e_eth_stats */ > i40e_stat_update_48(hw, I40E_GLPRT_GORCH(hw->port), > @@ -1284,8 +1285,8 @@ i40e_dev_stats_get(struct rte_eth_dev *dev, struct > rte_eth_stats *stats) > > stats->ipackets = ns->eth.rx_unicast + ns->eth.rx_multicast + > ns->eth.rx_broadcast; > - stats->opackets = ns->eth.tx_unicast + ns->eth.tx_multicast + > - ns->eth.tx_broadcast; > + stats->opackets = ves->tx_unicast + ves->tx_multicast + > + ves->tx_broadcast; > stats->ibytes = ns->eth.rx_bytes; > stats->obytes = ns->eth.tx_bytes; > stats->oerrors = ns->eth.tx_errors;
[dpdk-dev] [PATCH 0/4] Translate packet types for i40e
> -Original Message- > From: Ananyev, Konstantin > Sent: Tuesday, November 18, 2014 11:29 PM > To: Richardson, Bruce > Cc: Liu, Jijiang; dev at dpdk.org > Subject: RE: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e > > > > > -Original Message- > > From: Richardson, Bruce > > Sent: Tuesday, November 18, 2014 1:08 PM > > To: Ananyev, Konstantin > > Cc: Liu, Jijiang; dev at dpdk.org > > Subject: Re: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e > > > > On Tue, Nov 18, 2014 at 11:33:24AM +, Ananyev, Konstantin wrote: > > > Hi Frank, > > > > > > > -Original Message- > > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jijiang Liu > > > > Sent: Tuesday, November 18, 2014 7:37 AM > > > > To: dev at dpdk.org > > > > Subject: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e > > > > > > > > The i40e NIC can recognize many packet types, including ordinary > > > > L2 packet format and tunneling packet format such as IP in IP, IP > > in > > > > GRE, MAC in GRE and MAC in UDP. > > > > > > > > This patch set provides abstract definitions of packet types, > > > > which can help user to use these packet types directly in their > > > > applications > to speed up receive packet analysis. > > > > > > > > Moreover, this patch set translates i40e packet types to abstract > > > > packet types in i40e driver, and make the corresponding changes in test > applications. > > > > > > > > Jijiang Liu (4): > > > > Add packet type and IP header check in rte_mbuf > > > > Remove the PKT_RX_TUNNEL_IPV4_HDR and the > PKT_RX_TUNNEL_IPV6_HDR > > > > Translate i40e packet types > > > > Make the corresponding changes in test-pmd > > > > > > > > app/test-pmd/csumonly.c | 12 +- > > > > app/test-pmd/rxonly.c | 15 +- > > > > lib/librte_mbuf/rte_mbuf.h | 225 ++- > > > > lib/librte_pmd_i40e/i40e_rxtx.c | 604 > > > > +-- > > > > 4 files changed, 569 insertions(+), 287 deletions(-) > > > > > > > > > > The patch looks good to me in general. > > > Though I think it is not complete: we need to make sure that all > > > PMDs RX functions will set mbuf's packet_type to the defined value. > > > As right now, only i40e implementation can distinguish packet_type > > > properly, I think all other PMDs for the freshly received packet should > > > do: > > > mbuf->packet_type = RTE_PTYPE_UNDEF; In current codes, the mbuf->packet_type = 0 has already been done in rte_pktmbuf_reset(). > > > Another thing: right now mbuf's packet_type is uint16_t. > > > While enum rte_eth_packet_type will be interpreted by the compiler as > > > 'int' > (32bits). > > > We can either change enum to a lot of defines (which I don't really > > > like to do) or probably just add a comment somewhere that enum > rte_eth_packet_type should never exceed UINT16_MAX value? > > > > > Add a RTE_PTYPE_MAX value = UINT16_MAX to the enum, perhaps? > > Yep, add something like RTE_PTYPE_MAX = UINT16_MAX and RTE_PTYPE_MIN > == 0 seems like a good thing to me too. Ok, will add RTE_PTYPE_MAX = UINT16_MAX into rte_eth_packet_type. Currently, RTE_PTYPE_UNDEF is 0, if the RTE_PTYPE_MIN needed, and RTE_PTYPE_MIN = 1, but I think it is not necessary to add RTE_PTYPE_MIN. Moreover, there won't be an icc compilation error for the following codes, so we can set mb-> packet_type using enum paket_type directly in i40e driver. enum rte_eth_packet_type paket_type; mb-> packet_type = paket_type;//packet_type is uint16 in mbuf. But there will be an icc compilation error for the following codes, we must convert packet_type in mbuf . enum rte_eth_packet_type paket_type; paket_type = mb-> packet_type ;//packet_type is uint16 in mbuf. and it needs to change as follows to avoid compilation error using icc. paket_type =(rte_eth_packet_type) mb-> packet_type; > > > > > /Bruce
[dpdk-dev] [PATCH v4 00/21] Support flow director programming on Fortville
Tested-by: Min Cao Patch name: [PATCH v4 00/21] Support flow director programming on Fortville Test Flag: Tested-by Tester name:min.cao at intel.com Result summary: total 3 cases, 3 passed, 0 failed Test Case 1: Name: Fortville flow director with no flexible playload(IPv4/IPv6) Environment:OS: Fedora20 3.11.10-301.fc20.x86_64 gcc (GCC) 4.8.2 CPU: Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz NIC: Fortville eagle/spirit Test result:PASSED Test Case 2: Name: Fortville flow director with flexible playload(IPv4/IPv6) Environment:OS: Fedora20 3.11.10-301.fc20.x86_64 gcc (GCC) 4.8.2 CPU: Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz NIC: Fortville eagle/spirit Test result:PASSED Test Case 3: Name: Fortville flow director flush Environment:OS: Fedora20 3.11.10-301.fc20.x86_64 gcc (GCC) 4.8.2 CPU: Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz NIC: Fortville eagle/spirit Test result:PASSED Test Case 4: Name: Fortville flow director performance Environment:OS: Fedora20 3.11.10-301.fc20.x86_64 gcc (GCC) 4.8.2 CPU: Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz NIC: Fortville eagle/spirit Test result:PASSED -Original Message- From: Wu, Jingjing Sent: Wednesday, October 22, 2014 9:01 AM To: dev at dpdk.org Cc: Wu, Jingjing; Cao, Min Subject: [PATCH v4 00/21] Support flow director programming on Fortville The patch set supports flow director on fortville. It includes: - set up/tear down fortville resources to support flow director, such as queue and vsi. - support operation to add or delete 8 flow types of the flow director filters, they are ipv4, tcpv4, udpv4, sctpv4, ipv6, tcpv6, udpv6, sctpv6. - support flushing flow director table (all filters). - support operation to get flow director information. - match status statistics, FD_ID report. - support operation to configure flexible payload and its mask - support flexible payload involved in comparison and flex bytes report. v2 changes: - create real fdir vsi and assign queue 0 pair to it. - check filter status report on the rx queue 0 v3 changes: - redefine filter APIs to support multi-kind filters - support sctpv4 and sctpv6 type flows - support flexible payload involved in comparison v4 changes: - strip the filter APIs definitions from this patch set - extend mbuf field to support flex bytes report - fix typos Jingjing Wu (21): i40e: set up and initialize flow director i40e: tear down flow director i40e: initialize flexible payload setting ethdev: define structures for adding/deleting flow director i40e: implement operations to add/delete flow director testpmd: add test commands to add/delete flow director filter i40e: match counter for flow director mbuf: extend fdir field i40e: report flow director match info to mbuf testpmd: print extended fdir info in mbuf ethdev: define structures for getting flow director information i40e: implement operations to get fdir info testpmd: display fdir statistics i40e: implement operation to flush flow director table testpmd: add test command to flush flow director table ethdev: define structures for configuring flexible payload i40e: implement operations to configure flexible payload testpmd: add test command to configure flexible payload ethdev: define structures for configuring flex masks i40e: implement operations to configure flexible masks testpmd: add test command to configure flexible masks app/test-pmd/cmdline.c| 812 app/test-pmd/config.c | 38 +- app/test-pmd/rxonly.c | 14 +- app/test-pmd/testpmd.h|3 + lib/librte_ether/rte_eth_ctrl.h | 266 lib/librte_ether/rte_ethdev.h | 23 - lib/librte_mbuf/rte_mbuf.h| 12 +- lib/librte_pmd_i40e/Makefile |2 + lib/librte_pmd_i40e/i40e_ethdev.c | 127 +++- lib/librte_pmd_i40e/i40e_ethdev.h | 34 +- lib/librte_pmd_i40e/i40e_fdir.c | 1222 + lib/librte_pmd_i40e/i40e_rxtx.c | 225 ++- 12 files changed, 2723 insertions(+), 55 deletions(-) create mode 100644 lib/librte_pmd_i40e/i40e_fdir.c -- 1.8.1.4
[dpdk-dev] [PATCH v5 02/21] i40e: tear down flow director
Tested-by: Min Cao
Patch name: [PATCH v5 00/21] Support flow director programming on
Fortville
Test Flag: Tested-by
Tester name:min.cao at intel.com
Result summary: total 3 cases, 3 passed, 0 failed
Test Case 1:
Name: Fortville flow director with no flexible
playload(IPv4/IPv6)
Environment:OS: Fedora20 3.11.10-301.fc20.x86_64
gcc (GCC) 4.8.2
CPU: Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz
NIC: Fortville eagle/spirit
Test result:PASSED
Test Case 2:
Name: Fortville flow director with flexible
playload(IPv4/IPv6)
Environment:OS: Fedora20 3.11.10-301.fc20.x86_64
gcc (GCC) 4.8.2
CPU: Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz
NIC: Fortville eagle/spirit
Test result:PASSED
Test Case 3:
Name: Fortville flow director flush
Environment:OS: Fedora20 3.11.10-301.fc20.x86_64
gcc (GCC) 4.8.2
CPU: Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz
NIC: Fortville eagle/spirit
Test result:PASSED
Test Case 4:
Name: Fortville flow director performance
Environment:OS: Fedora20 3.11.10-301.fc20.x86_64
gcc (GCC) 4.8.2
CPU: Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz
NIC: Fortville eagle/spirit
Test result:PASSED
-Original Message-
From: Wu, Jingjing
Sent: Thursday, October 30, 2014 3:26 PM
To: dev at dpdk.org
Cc: Wu, Jingjing; Cao, Min
Subject: [PATCH v5 02/21] i40e: tear down flow director
To support flow director tear down, this patch includes
- queue 0 pair release
- release vsi
Signed-off-by: Jingjing Wu
---
lib/librte_pmd_i40e/i40e_ethdev.c | 4 +++-
lib/librte_pmd_i40e/i40e_ethdev.h | 1 +
lib/librte_pmd_i40e/i40e_fdir.c | 19 +++
3 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/lib/librte_pmd_i40e/i40e_ethdev.c
b/lib/librte_pmd_i40e/i40e_ethdev.c
index cea7725..812c91d 100644
--- a/lib/librte_pmd_i40e/i40e_ethdev.c
+++ b/lib/librte_pmd_i40e/i40e_ethdev.c
@@ -514,7 +514,8 @@ eth_i40e_dev_init(__rte_unused struct eth_driver *eth_drv,
return 0;
err_setup_pf_switch:
- rte_free(pf->main_vsi);
+ i40e_fdir_teardown(pf);
+ i40e_vsi_release(pf->main_vsi);
err_get_mac_addr:
err_configure_lan_hmc:
(void)i40e_shutdown_lan_hmc(hw);
@@ -849,6 +850,7 @@ i40e_dev_close(struct rte_eth_dev *dev)
i40e_shutdown_lan_hmc(hw);
/* release all the existing VSIs and VEBs */
+ i40e_fdir_teardown(pf);
i40e_vsi_release(pf->main_vsi);
/* shutdown the adminq */
diff --git a/lib/librte_pmd_i40e/i40e_ethdev.h
b/lib/librte_pmd_i40e/i40e_ethdev.h
index 6d30f75..35fcc46 100644
--- a/lib/librte_pmd_i40e/i40e_ethdev.h
+++ b/lib/librte_pmd_i40e/i40e_ethdev.h
@@ -379,6 +379,7 @@ enum i40e_status_code i40e_fdir_setup_tx_resources(struct
i40e_pf *pf,
enum i40e_status_code i40e_fdir_setup_rx_resources(struct i40e_pf *pf,
unsigned int socket_id);
int i40e_fdir_setup(struct i40e_pf *pf);
+void i40e_fdir_teardown(struct i40e_pf *pf);
/* I40E_DEV_PRIVATE_TO */
#define I40E_DEV_PRIVATE_TO_PF(adapter) \
diff --git a/lib/librte_pmd_i40e/i40e_fdir.c b/lib/librte_pmd_i40e/i40e_fdir.c
index a44bb73..bb474d2 100644
--- a/lib/librte_pmd_i40e/i40e_fdir.c
+++ b/lib/librte_pmd_i40e/i40e_fdir.c
@@ -219,4 +219,23 @@ fail_setup_tx:
i40e_vsi_release(vsi);
pf->fdir.fdir_vsi = NULL;
return err;
+}
+
+/*
+ * i40e_fdir_teardown - release the Flow Director resources
+ * @pf: board private structure
+ */
+void
+i40e_fdir_teardown(struct i40e_pf *pf)
+{
+ struct i40e_vsi *vsi;
+
+ vsi = pf->fdir.fdir_vsi;
+ i40e_dev_rx_queue_release(pf->fdir.rxq);
+ pf->fdir.rxq = NULL;
+ i40e_dev_tx_queue_release(pf->fdir.txq);
+ pf->fdir.txq = NULL;
+ i40e_vsi_release(vsi);
+ pf->fdir.fdir_vsi = NULL;
+ return;
}
\ No newline at end of file
--
1.8.1.4
[dpdk-dev] [PATCH v6 0/8] support of multiple sizes of redirection table
Tested-by: Erlu Chen - Tested Commit: 951ac486a6bb9499cbaa605bd4bde2b5e52e - OS: Linux fc20 3.11.10-301.fc20.x86_64 - CPU: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz - GCC: gcc version 4.8.3 20140624 - NIC: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ [8086:1572] Intel Corporation Ethernet Controller XL710 for 40GbE QSFP+ [8086:1584] Intel Corporation Ethernet Controller XL710 for 40GbE QSFP+ [8086:1583] - Default x86_64-native-linuxapp-gcc configuration - Total 1 cases, 1 passed, 0 failed - Case: pmdrss_reta Description: pmdrss_reta is designed to improve networking performance by load balancing the packets received from a NIC port to multiple NIC RX queues, with each queue handled by a different logical core. Command / instruction: #1. set up testpmd with fortville NICs:: ./testpmd -c f -n %d -- -i --coremask=0xe --rxq=16 --txq=16 #2. verbose configuration:: testpmd command: set verbose 8 #3. PMD fwd only receive the packets:: testpmd command: set fwd rxonly #4. Reta Configuration. 128 or 512 reta entries configuration:: testpmd command: port config 0 rss reta (hash_index,queue_id) #5. start packet receive:: testpmd command: start tester Configuration --- #1. set up scapy #2. send packets with different type ipv4/ipv4 with tcp/ipv4 with udp/ipv6/ipv6 with tcp/ipv6 with udp:: sendp([Ether(dst="90:e2:ba:36:99:3c")/IP(src="192.168.0.4", dst="192.168.0.5")], iface="eth3") Expected test result: The testpmd will print the hash value and actual queue of every packet. #1. Calaute the queue id: hash value%128or512, then refer to the redirection table to get the theoretical queue id. #2. The theoretical queue id is the same with the actual queue id. -Original Message- From: Zhang, Helin Sent: Sunday, November 16, 2014 12:04 AM To: dev at dpdk.org Cc: Cao, Waterman; Cao, Min; Wu, Jingjing; Liu, Jijiang; Chen, Erlu; Ananyev, Konstantin; Zhang, Helin Subject: [PATCH v6 0/8] support of multiple sizes of redirection table As e1000, ixgbe and i40e hardware use different sizes of redirection table in PF or VF, ethdev and PMDs need to be reworked to support multiple sizes of that table. In addition, commands in testpmd also need to be reworked to support these changes. v2 changes: * Reorganized the patches. * Added code style fixes. * Added support of reta updating/querying in i40e VF. v3 changes: * Reorganized the patch set. * Added returning default RX/TX configurations in VF (igb/ixgbe/i40e), as the patch set of it for PF has been accepted recently. v4 changes: * Renamed RTE_BIT_WIDTH_64 to RTE_RETA_GROUP_SIZE. * Added more comments to rte_eth_dev_rss_reta_update() and rte_eth_dev_rss_reta_query(). v5 changes: * Reworked the annotations of macros of RETA sizes in rte_ethdev.h. v6 changes: * Checking if the input number of reta size is 64 aligned has been added in rte_ethdev.c. * Use macros to replace numeric in all igb, ixgbe and i40e PMDs of updating/querying reta. Helin Zhang (8): app/testpmd: code style fix i40evf: code style fix i40e: support of setting hash lookup table size igb: implement ops of 'dev_infos_get' for PF and VF respectively ixgbe: implement ops of 'dev_infos_get' for PF and VF respectively i40e: rework of ops of 'dev_infos_get' for both PF and VF ethdev: support of multiple sizes of redirection table i40evf: support of updating/querying redirection table app/test-pmd/cmdline.c | 166 app/test-pmd/config.c| 37 +++ app/test-pmd/testpmd.h | 4 +- lib/librte_ether/rte_ethdev.c| 121 lib/librte_ether/rte_ethdev.h| 51 ++--- lib/librte_pmd_e1000/igb_ethdev.c| 179 +++--- lib/librte_pmd_i40e/i40e_ethdev.c| 122 +++- lib/librte_pmd_i40e/i40e_ethdev.h| 25 - lib/librte_pmd_i40e/i40e_ethdev_vf.c | 124 - lib/librte_pmd_ixgbe/ixgbe_ethdev.c | 208 +++ 10 files changed, 719 insertions(+), 318 deletions(-) -- 1.8.1.4
[dpdk-dev] [PATCH] test: fix misplaced braces in strncmp call
This patch fixes two occurances where a call to strncmp had the closing brace in the wrong place. Changing this form: if (strncmp(X,Y,sizeof(X) != 0)) which does a comparison of length 1, to if (strncmp(X,Y,sizeof(X)) != 0) which does the correct length comparison and then compares the result to zero in the "if" part, as the author presumably originally intended. Reported-by: Larry Wang Signed-off-by: Bruce Richardson --- app/test/test_devargs.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/app/test/test_devargs.c b/app/test/test_devargs.c index f0acf8e..dcbdd09 100644 --- a/app/test/test_devargs.c +++ b/app/test/test_devargs.c @@ -90,9 +90,9 @@ test_devargs(void) goto fail; devargs = TAILQ_FIRST(&devargs_list); if (strncmp(devargs->virtual.drv_name, "eth_ring1", - sizeof(devargs->virtual.drv_name) != 0)) + sizeof(devargs->virtual.drv_name)) != 0) goto fail; - if (strncmp(devargs->args, "k1=val,k2=val2", sizeof(devargs->args) != 0)) + if (strncmp(devargs->args, "k1=val,k2=val2", sizeof(devargs->args)) != 0) goto fail; free_devargs_list(); -- 1.9.3
[dpdk-dev] [PATCH 0/4] Translate packet types for i40e
> -Original Message-
> From: Liu, Jijiang
> Sent: Wednesday, November 19, 2014 3:53 AM
> To: Ananyev, Konstantin
> Cc: dev at dpdk.org; Richardson, Bruce
> Subject: RE: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e
>
>
>
> > -Original Message-
> > From: Ananyev, Konstantin
> > Sent: Tuesday, November 18, 2014 11:29 PM
> > To: Richardson, Bruce
> > Cc: Liu, Jijiang; dev at dpdk.org
> > Subject: RE: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e
> >
> >
> >
> > > -Original Message-
> > > From: Richardson, Bruce
> > > Sent: Tuesday, November 18, 2014 1:08 PM
> > > To: Ananyev, Konstantin
> > > Cc: Liu, Jijiang; dev at dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e
> > >
> > > On Tue, Nov 18, 2014 at 11:33:24AM +, Ananyev, Konstantin wrote:
> > > > Hi Frank,
> > > >
> > > > > -Original Message-
> > > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jijiang Liu
> > > > > Sent: Tuesday, November 18, 2014 7:37 AM
> > > > > To: dev at dpdk.org
> > > > > Subject: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e
> > > > >
> > > > > The i40e NIC can recognize many packet types, including ordinary
> > > > > L2 packet format and tunneling packet format such as IP in IP, IP
> > > in
> > > > > GRE, MAC in GRE and MAC in UDP.
> > > > >
> > > > > This patch set provides abstract definitions of packet types,
> > > > > which can help user to use these packet types directly in their
> > > > > applications
> > to speed up receive packet analysis.
> > > > >
> > > > > Moreover, this patch set translates i40e packet types to abstract
> > > > > packet types in i40e driver, and make the corresponding changes in
> > > > > test
> > applications.
> > > > >
> > > > > Jijiang Liu (4):
> > > > > Add packet type and IP header check in rte_mbuf
> > > > > Remove the PKT_RX_TUNNEL_IPV4_HDR and the
> > PKT_RX_TUNNEL_IPV6_HDR
> > > > > Translate i40e packet types
> > > > > Make the corresponding changes in test-pmd
> > > > >
> > > > > app/test-pmd/csumonly.c | 12 +-
> > > > > app/test-pmd/rxonly.c | 15 +-
> > > > > lib/librte_mbuf/rte_mbuf.h | 225 ++-
> > > > > lib/librte_pmd_i40e/i40e_rxtx.c | 604
> > > > > +--
> > > > > 4 files changed, 569 insertions(+), 287 deletions(-)
> > > > >
> > > >
> > > > The patch looks good to me in general.
> > > > Though I think it is not complete: we need to make sure that all
> > > > PMDs RX functions will set mbuf's packet_type to the defined value.
> > > > As right now, only i40e implementation can distinguish packet_type
> > > > properly, I think all other PMDs for the freshly received packet should
> > > > do:
> > > > mbuf->packet_type = RTE_PTYPE_UNDEF;
>
> In current codes, the mbuf->packet_type = 0 has already been done in
> rte_pktmbuf_reset().
Ok yes, I missed that: indeed we already do mbuf->packet_type = 0 in
rte_pktmbuf_reset().
Though, as I said in another mail our PMDs RX routines don't use
rte_pktmbuf_reset() for performance reasons.
So, I still think that scalar ixgbe, igb/em and virtio/vmnext3 need to be
updated.
>
> > > > Another thing: right now mbuf's packet_type is uint16_t.
> > > > While enum rte_eth_packet_type will be interpreted by the compiler as
> > > > 'int'
> > (32bits).
> > > > We can either change enum to a lot of defines (which I don't really
> > > > like to do) or probably just add a comment somewhere that enum
> > rte_eth_packet_type should never exceed UINT16_MAX value?
> > > >
> > > Add a RTE_PTYPE_MAX value = UINT16_MAX to the enum, perhaps?
> >
> > Yep, add something like RTE_PTYPE_MAX = UINT16_MAX and RTE_PTYPE_MIN
> > == 0 seems like a good thing to me too.
>
> Ok, will add RTE_PTYPE_MAX = UINT16_MAX into rte_eth_packet_type.
> Currently, RTE_PTYPE_UNDEF is 0, if the RTE_PTYPE_MIN needed, and
> RTE_PTYPE_MIN = 1, but I think it is not necessary to add
> RTE_PTYPE_MIN.
Why you need to setup RTE_PTYPE_MIN == 1?
Why it can't be done like that:
enum rte_eth_ptype {
RTE_PTYPE_MIN = 0,
RTE_PTYPE_UDEF = RTE_PTYPE_MIN,
RTE_PTYPE_MAX = UINT16_MAX
};
?
>
> Moreover, there won't be an icc compilation error for the following codes,
> so we can set mb-> packet_type using enum paket_type
> directly in i40e driver.
> enum rte_eth_packet_type paket_type;
> mb-> packet_type = paket_type;//packet_type is uint16 in mbuf.
>
> But there will be an icc compilation error for the following codes, we must
> convert packet_type in mbuf .
> enum rte_eth_packet_type paket_type;
> paket_type = mb-> packet_type ;//packet_type is uint16 in mbuf.
>
> and it needs to change as follows to avoid compilation error using icc.
> paket_type =(rte_eth_packet_type) mb-> packet_type;
Not sure I understand you here.
I think you'll still need to do a direct conversion to keep old versions of icc
happy:
mb-> packet_type = (uint16_t)paket_type;
...
pa
[dpdk-dev] [PATCH v4 3/5] hash: add fallback to software CRC32 implementation
On Tue, Nov 18, 2014 at 04:36:24PM -0500, Neil Horman wrote:
> On Tue, Nov 18, 2014 at 05:52:27PM +, Bruce Richardson wrote:
> > On Tue, Nov 18, 2014 at 12:46:19PM -0500, Neil Horman wrote:
> > > On Tue, Nov 18, 2014 at 11:13:17PM +0600, Yerden Zhumabekov wrote:
> > > >
> > > > 18.11.2014 22:00, Neil Horman ?:
> > > > > On Tue, Nov 18, 2014 at 09:06:35PM +0600, Yerden Zhumabekov wrote:
> > > > >> 18.11.2014 20:41, Neil Horman ?:
> > > > >>> On Tue, Nov 18, 2014 at 08:03:40PM +0600, Yerden Zhumabekov wrote:
> > > > /**
> > > > * Use single crc32 instruction to perform a hash on a 4 byte
> > > > value.
> > > > + * Fall back to software crc32 implementation in case SSE4.2 is
> > > > + * not supported
> > > > *
> > > > * @param data
> > > > * Data to perform hash on.
> > > > @@ -376,11 +413,18 @@ crc32c_2words(uint64_t data, uint32_t
> > > > init_val)
> > > > static inline uint32_t
> > > > rte_hash_crc_4byte(uint32_t data, uint32_t init_val)
> > > > {
> > > > - return _mm_crc32_u32(init_val, data);
> > > > +#ifdef RTE_MACHINE_CPUFLAG_SSE4_2
> > > > + if (likely(crc32_alg == CRC32_SSE42))
> > > > + return _mm_crc32_u32(init_val, data);
> > > > +#endif
> > > > >>> you don't really need these ifdefs here anymore given that you have
> > > > >>> a
> > > > >>> constructor to do the algorithm selection. In fact you need to
> > > > >>> remove them, in
> > > > >>> the event you build on a system that doesn't support SSE42, but run
> > > > >>> on a system
> > > > >>> that does.
> > > > >> Originally, I thought so as well. I wrote the code without these
> > > > >> ifdefs,
> > > > >> but it didn't compile on my machine which doesn't support SSE4.2.
> > > > >> Error
> > > > >> was triggered by nmmintrin.h which has a check for respective GCC
> > > > >> extension. So I think these ifdefs are indeed required.
> > > > >>
> > > > > You need to edit the makefile so that the compiler gets passed the
> > > > > option
> > > > > -msse42. That way it will know to emit sse42 instructions. It will
> > > > > also allow
> > > > > you to remove the ifdef from the include file
> > > >
> > > > In this case, I guess there are two options:
> > > > 1) modify all makefiles which use librte_hash
> > > > 2) move all function bodies from rte_hash_crc.h to separate module,
> > > > leaving prototype definitions there only.
> > > >
> > > > Everybody's up for the second option? :)
> > > >
> > > Crud, you're right, I didn't think about the header inclusion issue. Is
> > > it
> > > worth adding the jump to enable the dynamic hash selection?
> > > Neil
> >
> > Maybe for cases where SSE4.2 is not currently available, i.e. for generic
> > builds.
> > For builds where we have hardware support confirmed at compile time, just
> > use
> > the function from the header file.
> > Does that make sense?
> >
> I'm not certain of that, as I don't think anything can be 'confirmed' at
> compile
> time. I.e. just because you have sse42 at compile time doesn't guarantee you
> have it at run time with a DSO. If you have these as macros, you need to
> enable
> sse42 whereever you include the file so that the intrinsic works properly.
Well, if you compile with sse42 at compile time, the compiler is free to insert
sse4 instructions at any place it feels like, irrespective of whether or not you
use SSE4 intrinsics, so I would never expect such a DSO to work on a system
without SSE42 support.
>
> an alternate option would be to not use the intrinsic, and craft some explicit
> __asm__ statement that executes the right sse42 instructions. That way the
> asm
> is directly emitted, without requiring the -msse42 flag at all, and it will
> just
> work in all the files that call it.
>
I really don't like that approach. I think using intrinsics is much more
maintainable.
/Bruce
[dpdk-dev] [PATCH] test: fix misplaced braces in strncmp call
Hi Bruce, On 11/19/2014 10:06 AM, Bruce Richardson wrote: > This patch fixes two occurances where a call to strncmp had the closing > brace in the wrong place. Changing this form: > if (strncmp(X,Y,sizeof(X) != 0)) > which does a comparison of length 1, to > if (strncmp(X,Y,sizeof(X)) != 0) > which does the correct length comparison and then compares the result to > zero in the "if" part, as the author presumably originally intended. > > Reported-by: Larry Wang > Signed-off-by: Bruce Richardson > --- > app/test/test_devargs.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/app/test/test_devargs.c b/app/test/test_devargs.c > index f0acf8e..dcbdd09 100644 > --- a/app/test/test_devargs.c > +++ b/app/test/test_devargs.c > @@ -90,9 +90,9 @@ test_devargs(void) > goto fail; > devargs = TAILQ_FIRST(&devargs_list); > if (strncmp(devargs->virtual.drv_name, "eth_ring1", > - sizeof(devargs->virtual.drv_name) != 0)) > + sizeof(devargs->virtual.drv_name)) != 0) > goto fail; > - if (strncmp(devargs->args, "k1=val,k2=val2", sizeof(devargs->args) != > 0)) > + if (strncmp(devargs->args, "k1=val,k2=val2", sizeof(devargs->args)) != > 0) > goto fail; > free_devargs_list(); > > Nice catch! Acked-by: Olivier Matz
[dpdk-dev] [PATCH 1/4] rte_mbuf:add packet types
Hi Jijiang,
On 11/18/2014 08:37 AM, Jijiang Liu wrote:
> This patch abstracts packet types of L2 packet, Non Tunneled IPv4/6, IP in
> IP, IP in GRE, MAC in GRE and MAC in UDP, and add 4 MACROS to check packet IP
> header.
>
> Signed-off-by: Jijiang Liu
> ---
> lib/librte_mbuf/rte_mbuf.h | 223
>
> 1 files changed, 223 insertions(+), 0 deletions(-)
>
> diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
> index f5f8658..678db0d 100644
> --- a/lib/librte_mbuf/rte_mbuf.h
> +++ b/lib/librte_mbuf/rte_mbuf.h
> @@ -125,6 +125,229 @@ extern "C" {
>*/
> #define PKT_TX_OFFLOAD_MASK (PKT_TX_VLAN_PKT | PKT_TX_IP_CKSUM |
> PKT_TX_L4_MASK)
>
> +/**
> + * Ethernet packet type
> + */
> +enum rte_eth_packet_type {
> +
> + /* undefined packet type, means HW can't recognise it */
> + RTE_PTYPE_UNDEF = 0,
> +
> + /* L2 Packet types */
> + RTE_PTYPE_PAY2,
> + RTE_PTYPE_TimeSync_PAY2, /**< IEEE1588 and 802.1AS */
> + RTE_PTYPE_FIP_PAY2, /**< FCoE Initiation Protocol */
> + RTE_PTYPE_LLDP_PAY2, /**< Link Layer Discovery Protocol */
> + RTE_PTYPE_ECP_PAY2, /**< Edge Control Protocol */
> [...]
I have one question about the packet_type: it is not clear to me
what the software can expect, for instance when RTE_PTYPE_IPv4_IPv4
is set. What does that mean exactly? Which fields must be valid in
the packet to have this type?
- L2 ethertype
- Presence of vlan?
- IP version
- IP checksum
- IP header length
- IP length (compared to packet len)
- anything about IP options?
This question applies to all types of course.
If I want to use packet type in an IP stack, I need to know which
fields are checked by hardware (and what "checked" means for some of
them), so I can do the remaining work in my application.
If I want to write a new PMD (maybe a virtual one, full software), what
do I need to check in the packet if I want to set the
RTE_PTYPE_IPv4_IPv4 type?
I also feel it can be redundant with the current flags ("header is IPv4"
for instance).
To me, these types look very "i40e" oriented. If tomorrow (or today ?)
we want to write a PMD for a hardware that is able to recognize IPv4,
but does not do exactly the same checks than i40e. It is crucial that
what having a packet type set means... else it will stay an i40e-only
mbuf field, which is probably not what we want.
So, I think if we really want packet types to be integrated in mbuf, we
need to:
- start with a small list (maybe ipv4, ipv6, vxlan tunnels, ...)
- each type must be well defined: what does having this type means? We
*need* to know what was checked by the hw.
- remove similar things in ol_flags to avoid having a redundant API.
Regards,
Olivier
[dpdk-dev] [PATCH v2 06/13] mbuf: add functions to get the name of an ol_flag
> -Original Message-
> From: Olivier MATZ [mailto:olivier.matz at 6wind.com]
> Sent: Tuesday, November 18, 2014 9:30 AM
> To: Ananyev, Konstantin; dev at dpdk.org
> Cc: jigsaw at gmail.com; Zhang, Helin
> Subject: Re: [dpdk-dev] [PATCH v2 06/13] mbuf: add functions to get the name
> of an ol_flag
>
> Hi Konstantin,
>
> On 11/17/2014 08:00 PM, Ananyev, Konstantin wrote:
> >> +/*
> >> + * Get the name of a RX offload flag
> >> + */
> >> +const char *rte_get_rx_ol_flag_name(uint64_t mask)
> >> +{
> >> + switch (mask) {
> >> + case PKT_RX_VLAN_PKT: return "PKT_RX_VLAN_PKT";
> >> + case PKT_RX_RSS_HASH: return "PKT_RX_RSS_HASH";
> >> + case PKT_RX_FDIR: return "PKT_RX_FDIR";
> >> + case PKT_RX_L4_CKSUM_BAD: return "PKT_RX_L4_CKSUM_BAD";
> >> + case PKT_RX_IP_CKSUM_BAD: return "PKT_RX_IP_CKSUM_BAD";
> >> + /* case PKT_RX_EIP_CKSUM_BAD: return "PKT_RX_EIP_CKSUM_BAD"; */
> >> + /* case PKT_RX_OVERSIZE: return "PKT_RX_OVERSIZE"; */
> >> + /* case PKT_RX_HBUF_OVERFLOW: return "PKT_RX_HBUF_OVERFLOW"; */
> >> + /* case PKT_RX_RECIP_ERR: return "PKT_RX_RECIP_ERR"; */
> >> + /* case PKT_RX_MAC_ERR: return "PKT_RX_MAC_ERR"; */
> >
> > Didn't spot it before, wonder why do you need these 5 commented out lines?
> > In fact, why do we need these flags if they all equal to zero right now?
> > I know these flags were not introduced by that patch, in fact as I can see
> > it was a temporary measure,
> > as old ol_flags were just 16 bits long:
> > http://dpdk.org/ml/archives/dev/2014-June/003308.html
> > So wonder should now these flags either get proper values or be removed?
>
> I would be in favor of removing them, or at least the following ones
> (I don't understand how they can help the application):
>
> - PKT_RX_OVERSIZE: Num of desc of an RX pkt oversize.
> - PKT_RX_HBUF_OVERFLOW: Header buffer overflow.
> - PKT_RX_RECIP_ERR: Hardware processing error.
> - PKT_RX_MAC_ERR: MAC error.
Tend to agree...
Or probably collapse these 4 flags into one: flag PKT_RX_ERR or something.
Might be still used by someone for debugging purposes.
Helin, what do you think?
>
> I would have say that a statistics counter in the driver is more
> appropriate for this case (maybe there is already a counter in the
> hardware).
>
> I have no i40e hardware to test that, so I don't feel very comfortable
> to modify the i40e driver code to add these stats.
>
> Adding Helin in CC list, maybe he has an idea.
>
> Regards,
> Olivier
[dpdk-dev] versioning and maintenance
Following the discussion we had with Neil during the conference call, I suggest this plan, starting with the next release (2.0): - add version numbers to libraries - add version numbers to functions inside .map files - create a git tree dedicated to maintenance and API compatibility It means these version numbers must be incremented when breaking the API. Though the old code paths will be maintained and tested separately by volunteers. A mailing list for maintenance purpose could be created if needed. -- Thomas
[dpdk-dev] [PATCH v4 3/5] hash: add fallback to software CRC32 implementation
On Wed, Nov 19, 2014 at 10:16:14AM +, Bruce Richardson wrote:
> On Tue, Nov 18, 2014 at 04:36:24PM -0500, Neil Horman wrote:
> > On Tue, Nov 18, 2014 at 05:52:27PM +, Bruce Richardson wrote:
> > > On Tue, Nov 18, 2014 at 12:46:19PM -0500, Neil Horman wrote:
> > > > On Tue, Nov 18, 2014 at 11:13:17PM +0600, Yerden Zhumabekov wrote:
> > > > >
> > > > > 18.11.2014 22:00, Neil Horman ?:
> > > > > > On Tue, Nov 18, 2014 at 09:06:35PM +0600, Yerden Zhumabekov wrote:
> > > > > >> 18.11.2014 20:41, Neil Horman ?:
> > > > > >>> On Tue, Nov 18, 2014 at 08:03:40PM +0600, Yerden Zhumabekov wrote:
> > > > > /**
> > > > > * Use single crc32 instruction to perform a hash on a 4 byte
> > > > > value.
> > > > > + * Fall back to software crc32 implementation in case SSE4.2 is
> > > > > + * not supported
> > > > > *
> > > > > * @param data
> > > > > * Data to perform hash on.
> > > > > @@ -376,11 +413,18 @@ crc32c_2words(uint64_t data, uint32_t
> > > > > init_val)
> > > > > static inline uint32_t
> > > > > rte_hash_crc_4byte(uint32_t data, uint32_t init_val)
> > > > > {
> > > > > -return _mm_crc32_u32(init_val, data);
> > > > > +#ifdef RTE_MACHINE_CPUFLAG_SSE4_2
> > > > > +if (likely(crc32_alg == CRC32_SSE42))
> > > > > +return _mm_crc32_u32(init_val, data);
> > > > > +#endif
> > > > > >>> you don't really need these ifdefs here anymore given that you
> > > > > >>> have a
> > > > > >>> constructor to do the algorithm selection. In fact you need to
> > > > > >>> remove them, in
> > > > > >>> the event you build on a system that doesn't support SSE42, but
> > > > > >>> run on a system
> > > > > >>> that does.
> > > > > >> Originally, I thought so as well. I wrote the code without these
> > > > > >> ifdefs,
> > > > > >> but it didn't compile on my machine which doesn't support SSE4.2.
> > > > > >> Error
> > > > > >> was triggered by nmmintrin.h which has a check for respective GCC
> > > > > >> extension. So I think these ifdefs are indeed required.
> > > > > >>
> > > > > > You need to edit the makefile so that the compiler gets passed the
> > > > > > option
> > > > > > -msse42. That way it will know to emit sse42 instructions. It will
> > > > > > also allow
> > > > > > you to remove the ifdef from the include file
> > > > >
> > > > > In this case, I guess there are two options:
> > > > > 1) modify all makefiles which use librte_hash
> > > > > 2) move all function bodies from rte_hash_crc.h to separate module,
> > > > > leaving prototype definitions there only.
> > > > >
> > > > > Everybody's up for the second option? :)
> > > > >
> > > > Crud, you're right, I didn't think about the header inclusion issue.
> > > > Is it
> > > > worth adding the jump to enable the dynamic hash selection?
> > > > Neil
> > >
> > > Maybe for cases where SSE4.2 is not currently available, i.e. for generic
> > > builds.
> > > For builds where we have hardware support confirmed at compile time, just
> > > use
> > > the function from the header file.
> > > Does that make sense?
> > >
> > I'm not certain of that, as I don't think anything can be 'confirmed' at
> > compile
> > time. I.e. just because you have sse42 at compile time doesn't guarantee
> > you
> > have it at run time with a DSO. If you have these as macros, you need to
> > enable
> > sse42 whereever you include the file so that the intrinsic works properly.
>
> Well, if you compile with sse42 at compile time, the compiler is free to
> insert
> sse4 instructions at any place it feels like, irrespective of whether or not
> you
> use SSE4 intrinsics, so I would never expect such a DSO to work on a system
> without SSE42 support.
>
> >
> > an alternate option would be to not use the intrinsic, and craft some
> > explicit
> > __asm__ statement that executes the right sse42 instructions. That way the
> > asm
> > is directly emitted, without requiring the -msse42 flag at all, and it will
> > just
> > work in all the files that call it.
> >
>
> I really don't like that approach. I think using intrinsics is much more
> maintainable.
>
I grant you that using an intrinsic is easier to read, but if the code doesn't
compile when using the intrinsic unless you have sse42 turned on, I'm not sure
what choice we have. and inline asm isn't that hard to maintain. We're talking
about three lines of code:
asm(
"mov%[1],%eax
mov%[2],%edx
crc32l %edx,%eax":
[edx] "r" (crc) /*output*/
:
[1] "r" (crc), /* input */
[2] "r" (val)
:
[eax] "r" /* clobber */
)
I don't have the syntax quite right, but its pretty easy to read the intent.
Its not like we dont have precidence for this, the atomic interface and several
pmds do this frequently.
Neil
> /Bruce
>
>
[dpdk-dev] versioning and maintenance
On Wed, Nov 19, 2014 at 12:22:14PM +0100, Thomas Monjalon wrote: > Following the discussion we had with Neil during the conference call, > I suggest this plan, starting with the next release (2.0): > - add version numbers to libraries > - add version numbers to functions inside .map files > - create a git tree dedicated to maintenance and API compatibility > > It means these version numbers must be incremented when breaking the API. > Though the old code paths will be maintained and tested separately by > volunteers. > A mailing list for maintenance purpose could be created if needed. > Hi Thomas, I really think that the versionning is best handled inside the main repository itself. Given that the proposed deprecation policy is over two releases i.e. an API is marked deprecated in release X and then removed in X+1, I don't see the maintaining of old code paths to be particularly onerous. /Bruce
[dpdk-dev] [PATCH v4 3/5] hash: add fallback to software CRC32 implementation
19.11.2014 16:16, Bruce Richardson ?:
> On Tue, Nov 18, 2014 at 04:36:24PM -0500, Neil Horman wrote:
>> an alternate option would be to not use the intrinsic, and craft some
>> explicit
>> __asm__ statement that executes the right sse42 instructions. That way the
>> asm
>> is directly emitted, without requiring the -msse42 flag at all, and it will
>> just
>> work in all the files that call it.
>>
> I really don't like that approach. I think using intrinsics is much more
> maintainable.
>
static inline uint32_t
crc32_sse42_u32(uint32_t data, uint32_t init_val)
{
/*??__asm__ volatile(
"crc32l %[data], %[init_val];"
: [init_val] "+r" (init_val)
: [data] "rm" (data));
return init_val;*/
But wait, will __builtin_ia32_crc32si and __builtin_ia32_crc32di
functions do the trick? ICC has them?
What about prototyping functions and extracting their bodies to separate
module? Does it break anything?
--
Sincerely,
Yerden Zhumabekov
State Technical Service
Astana, KZ
[dpdk-dev] [PATCH v4 3/5] hash: add fallback to software CRC32 implementation
On Wed, Nov 19, 2014 at 06:34:08AM -0500, Neil Horman wrote:
> On Wed, Nov 19, 2014 at 10:16:14AM +, Bruce Richardson wrote:
> > On Tue, Nov 18, 2014 at 04:36:24PM -0500, Neil Horman wrote:
> > > On Tue, Nov 18, 2014 at 05:52:27PM +, Bruce Richardson wrote:
> > > > On Tue, Nov 18, 2014 at 12:46:19PM -0500, Neil Horman wrote:
> > > > > On Tue, Nov 18, 2014 at 11:13:17PM +0600, Yerden Zhumabekov wrote:
> > > > > >
> > > > > > 18.11.2014 22:00, Neil Horman ?:
> > > > > > > On Tue, Nov 18, 2014 at 09:06:35PM +0600, Yerden Zhumabekov wrote:
> > > > > > >> 18.11.2014 20:41, Neil Horman ?:
> > > > > > >>> On Tue, Nov 18, 2014 at 08:03:40PM +0600, Yerden Zhumabekov
> > > > > > >>> wrote:
> > > > > > /**
> > > > > > * Use single crc32 instruction to perform a hash on a 4 byte
> > > > > > value.
> > > > > > + * Fall back to software crc32 implementation in case SSE4.2
> > > > > > is
> > > > > > + * not supported
> > > > > > *
> > > > > > * @param data
> > > > > > * Data to perform hash on.
> > > > > > @@ -376,11 +413,18 @@ crc32c_2words(uint64_t data, uint32_t
> > > > > > init_val)
> > > > > > static inline uint32_t
> > > > > > rte_hash_crc_4byte(uint32_t data, uint32_t init_val)
> > > > > > {
> > > > > > - return _mm_crc32_u32(init_val, data);
> > > > > > +#ifdef RTE_MACHINE_CPUFLAG_SSE4_2
> > > > > > + if (likely(crc32_alg == CRC32_SSE42))
> > > > > > + return _mm_crc32_u32(init_val, data);
> > > > > > +#endif
> > > > > > >>> you don't really need these ifdefs here anymore given that you
> > > > > > >>> have a
> > > > > > >>> constructor to do the algorithm selection. In fact you need to
> > > > > > >>> remove them, in
> > > > > > >>> the event you build on a system that doesn't support SSE42, but
> > > > > > >>> run on a system
> > > > > > >>> that does.
> > > > > > >> Originally, I thought so as well. I wrote the code without these
> > > > > > >> ifdefs,
> > > > > > >> but it didn't compile on my machine which doesn't support
> > > > > > >> SSE4.2. Error
> > > > > > >> was triggered by nmmintrin.h which has a check for respective GCC
> > > > > > >> extension. So I think these ifdefs are indeed required.
> > > > > > >>
> > > > > > > You need to edit the makefile so that the compiler gets passed
> > > > > > > the option
> > > > > > > -msse42. That way it will know to emit sse42 instructions. It
> > > > > > > will also allow
> > > > > > > you to remove the ifdef from the include file
> > > > > >
> > > > > > In this case, I guess there are two options:
> > > > > > 1) modify all makefiles which use librte_hash
> > > > > > 2) move all function bodies from rte_hash_crc.h to separate module,
> > > > > > leaving prototype definitions there only.
> > > > > >
> > > > > > Everybody's up for the second option? :)
> > > > > >
> > > > > Crud, you're right, I didn't think about the header inclusion issue.
> > > > > Is it
> > > > > worth adding the jump to enable the dynamic hash selection?
> > > > > Neil
> > > >
> > > > Maybe for cases where SSE4.2 is not currently available, i.e. for
> > > > generic builds.
> > > > For builds where we have hardware support confirmed at compile time,
> > > > just use
> > > > the function from the header file.
> > > > Does that make sense?
> > > >
> > > I'm not certain of that, as I don't think anything can be 'confirmed' at
> > > compile
> > > time. I.e. just because you have sse42 at compile time doesn't guarantee
> > > you
> > > have it at run time with a DSO. If you have these as macros, you need to
> > > enable
> > > sse42 whereever you include the file so that the intrinsic works properly.
> >
> > Well, if you compile with sse42 at compile time, the compiler is free to
> > insert
> > sse4 instructions at any place it feels like, irrespective of whether or
> > not you
> > use SSE4 intrinsics, so I would never expect such a DSO to work on a system
> > without SSE42 support.
> >
> > >
> > > an alternate option would be to not use the intrinsic, and craft some
> > > explicit
> > > __asm__ statement that executes the right sse42 instructions. That way
> > > the asm
> > > is directly emitted, without requiring the -msse42 flag at all, and it
> > > will just
> > > work in all the files that call it.
> > >
> >
> > I really don't like that approach. I think using intrinsics is much more
> > maintainable.
> >
> I grant you that using an intrinsic is easier to read, but if the code doesn't
> compile when using the intrinsic unless you have sse42 turned on, I'm not sure
> what choice we have. and inline asm isn't that hard to maintain. We're
> talking
> about three lines of code:
> asm(
> "mov%[1],%eax
> mov%[2],%edx
> crc32l %edx,%eax":
> [edx] "r" (crc) /*output*/
> :
> [1] "r" (crc), /* input */
> [2] "r" (val)
> :
> [eax] "r" /* clobber */
> )
>
> I don't have the syntax quite right, but it
[dpdk-dev] [PATCH v4 3/5] hash: add fallback to software CRC32 implementation
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce Richardson
> Sent: Wednesday, November 19, 2014 11:38 AM
> To: Neil Horman
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v4 3/5] hash: add fallback to software CRC32
> implementation
>
> On Wed, Nov 19, 2014 at 06:34:08AM -0500, Neil Horman wrote:
> > On Wed, Nov 19, 2014 at 10:16:14AM +, Bruce Richardson wrote:
> > > On Tue, Nov 18, 2014 at 04:36:24PM -0500, Neil Horman wrote:
> > > > On Tue, Nov 18, 2014 at 05:52:27PM +, Bruce Richardson wrote:
> > > > > On Tue, Nov 18, 2014 at 12:46:19PM -0500, Neil Horman wrote:
> > > > > > On Tue, Nov 18, 2014 at 11:13:17PM +0600, Yerden Zhumabekov wrote:
> > > > > > >
> > > > > > > 18.11.2014 22:00, Neil Horman ?:
> > > > > > > > On Tue, Nov 18, 2014 at 09:06:35PM +0600, Yerden Zhumabekov
> > > > > > > > wrote:
> > > > > > > >> 18.11.2014 20:41, Neil Horman ?:
> > > > > > > >>> On Tue, Nov 18, 2014 at 08:03:40PM +0600, Yerden Zhumabekov
> > > > > > > >>> wrote:
> > > > > > > /**
> > > > > > > * Use single crc32 instruction to perform a hash on a 4
> > > > > > > byte value.
> > > > > > > + * Fall back to software crc32 implementation in case
> > > > > > > SSE4.2 is
> > > > > > > + * not supported
> > > > > > > *
> > > > > > > * @param data
> > > > > > > * Data to perform hash on.
> > > > > > > @@ -376,11 +413,18 @@ crc32c_2words(uint64_t data, uint32_t
> > > > > > > init_val)
> > > > > > > static inline uint32_t
> > > > > > > rte_hash_crc_4byte(uint32_t data, uint32_t init_val)
> > > > > > > {
> > > > > > > -return _mm_crc32_u32(init_val, data);
> > > > > > > +#ifdef RTE_MACHINE_CPUFLAG_SSE4_2
> > > > > > > +if (likely(crc32_alg == CRC32_SSE42))
> > > > > > > +return _mm_crc32_u32(init_val, data);
> > > > > > > +#endif
> > > > > > > >>> you don't really need these ifdefs here anymore given that
> > > > > > > >>> you have a
> > > > > > > >>> constructor to do the algorithm selection. In fact you need
> > > > > > > >>> to remove them, in
> > > > > > > >>> the event you build on a system that doesn't support SSE42,
> > > > > > > >>> but run on a system
> > > > > > > >>> that does.
> > > > > > > >> Originally, I thought so as well. I wrote the code without
> > > > > > > >> these ifdefs,
> > > > > > > >> but it didn't compile on my machine which doesn't support
> > > > > > > >> SSE4.2. Error
> > > > > > > >> was triggered by nmmintrin.h which has a check for respective
> > > > > > > >> GCC
> > > > > > > >> extension. So I think these ifdefs are indeed required.
> > > > > > > >>
> > > > > > > > You need to edit the makefile so that the compiler gets passed
> > > > > > > > the option
> > > > > > > > -msse42. That way it will know to emit sse42 instructions. It
> > > > > > > > will also allow
> > > > > > > > you to remove the ifdef from the include file
> > > > > > >
> > > > > > > In this case, I guess there are two options:
> > > > > > > 1) modify all makefiles which use librte_hash
> > > > > > > 2) move all function bodies from rte_hash_crc.h to separate
> > > > > > > module,
> > > > > > > leaving prototype definitions there only.
> > > > > > >
> > > > > > > Everybody's up for the second option? :)
> > > > > > >
> > > > > > Crud, you're right, I didn't think about the header inclusion
> > > > > > issue. Is it
> > > > > > worth adding the jump to enable the dynamic hash selection?
> > > > > > Neil
> > > > >
> > > > > Maybe for cases where SSE4.2 is not currently available, i.e. for
> > > > > generic builds.
> > > > > For builds where we have hardware support confirmed at compile time,
> > > > > just use
> > > > > the function from the header file.
> > > > > Does that make sense?
> > > > >
> > > > I'm not certain of that, as I don't think anything can be 'confirmed'
> > > > at compile
> > > > time. I.e. just because you have sse42 at compile time doesn't
> > > > guarantee you
> > > > have it at run time with a DSO. If you have these as macros, you need
> > > > to enable
> > > > sse42 whereever you include the file so that the intrinsic works
> > > > properly.
> > >
> > > Well, if you compile with sse42 at compile time, the compiler is free to
> > > insert
> > > sse4 instructions at any place it feels like, irrespective of whether or
> > > not you
> > > use SSE4 intrinsics, so I would never expect such a DSO to work on a
> > > system
> > > without SSE42 support.
> > >
> > > >
> > > > an alternate option would be to not use the intrinsic, and craft some
> > > > explicit
> > > > __asm__ statement that executes the right sse42 instructions. That way
> > > > the asm
> > > > is directly emitted, without requiring the -msse42 flag at all, and it
> > > > will just
> > > > work in all the files that call it.
> > > >
> > >
> > > I really don't like that approach. I think using intrinsics is much more
> > >
[dpdk-dev] [PATCH v4 3/5] hash: add fallback to software CRC32 implementation
19.11.2014 17:50, Ananyev, Konstantin ?:
>
> As I remember with gcc & icc it is possible to specify tht you'd like to
> compile that particular function
> for different target.
> From https://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html:
> "target
> The target attribute is used to specify that a function is to be compiled
> with different target options than specified on the command line. This can be
> used for instance to have functions compiled with a different ISA
> (instruction set architecture) than the default. You can also use the
> ?#pragma GCC target? pragma to set more than one function to be compiled with
> specific target options. See Function Specific Option Pragmas, for details
> about the ?#pragma GCC target? pragma.
> For instance on a 386, you could compile one function with
> target("sse4.1,arch=core2") and another with target("sse4a,arch=amdfam10").
> This is equivalent to compiling the first function with -msse4.1 and
> -march=core2 options, and the second function with -msse4a and
> -march=amdfam10 options. It is up to the user to make sure that a function is
> only invoked on a machine that supports the particular ISA it is compiled for
> (for example by using cpuid on 386 to determine what feature bits and
> architecture family are used).
>
> int core2_func (void) __attribute__ ((__target__ ("arch=core2")));
> int sse3_func (void) __attribute__ ((__target__ ("sse3")));
> You can either use multiple strings to specify multiple options, or separate
> the options with a comma (?,?).
>
> The target attribute is presently implemented for i386/x86_64, PowerPC, and
> Nios II targets only. The options supported are specific to each target.
>
> On the 386, the following options are allowed:
> ...
> ?sse4.2?
> ?no-sse4.2?"
>
> Wouldn't that suit your purposes?
> Probably you can even keep your function inline with that approach.
Very nice. Thank you. I will test it.
--
Sincerely,
Yerden Zhumabekov
State Technical Service
Astana, KZ
[dpdk-dev] [PATCH 0/3] Add RTE_ prefix to CACHE_LINE related macros
Currently DPDK sets CACHE_LINE_SIZE value to 64 by default if the macro is not already defined. FreeBSD defines a CACHE_LINE_SIZE macro in the header file: /usr/include/machine/param.h These macros set different values, 64 in DPDK vs 128 in FreeBSD, causing broken application behaviour if the system header file is included before rte_memory.h (where DPDK sets CACHE_LINE_SIZE). This is the case for some examples like ip_fragmentation. In such application, DPDK library code would assume 64 bytes cache line size and the application code would assume 128 cache line size. Given that mbufs now take two cache lines and that the structure is being aligned based on this value, the result is broken application functionality. The approach to fix this issue is to add RTE_ prefix to all CACHE_LINE_ related macros to avoid conflicts. Sergio Gonzalez Monroy (3): Add RTE_ prefix to CACHE_LINE_SIZE macro Add RTE_ prefix to CACHE_LINE_MASK macro Add RTE_ prefix to CACHE_LINE_ROUNDUP macro app/test-acl/main.c | 2 +- app/test-pipeline/runtime.c | 2 +- app/test-pmd/testpmd.c| 14 +++--- app/test-pmd/testpmd.h| 4 +- app/test/test_distributor_perf.c | 2 +- app/test/test_ivshmem.c | 6 +-- app/test/test_malloc.c| 32 ++--- app/test/test_mbuf.c | 2 +- app/test/test_memzone.c | 58 +++ app/test/test_pmd_perf.c | 4 +- app/test/test_table.h | 2 +- doc/guides/sample_app_ug/kernel_nic_interface.rst | 2 +- examples/dpdk_qat/crypto.c| 2 +- examples/ip_pipeline/cmdline.c| 8 ++-- examples/ip_pipeline/init.c | 4 +- examples/ip_pipeline/pipeline_passthrough.c | 2 +- examples/ip_pipeline/pipeline_rx.c| 2 +- examples/ip_pipeline/pipeline_tx.c| 2 +- examples/ip_reassembly/main.c | 2 +- examples/kni/main.c | 2 +- examples/multi_process/l2fwd_fork/flib.c | 4 +- examples/multi_process/symmetric_mp/main.c| 2 +- examples/netmap_compat/lib/compat_netmap.c| 4 +- examples/qos_sched/main.c | 4 +- examples/vhost/main.c | 6 +-- examples/vhost_xen/vhost_monitor.c| 4 +- lib/librte_acl/acl_gen.c | 6 +-- lib/librte_acl/rte_acl.c | 2 +- lib/librte_acl/rte_acl_osdep_alone.h | 6 +-- lib/librte_distributor/rte_distributor.c | 4 +- lib/librte_eal/common/eal_common_memzone.c| 24 +- lib/librte_eal/common/include/rte_memory.h| 12 ++--- lib/librte_ether/rte_ethdev.c | 10 ++-- lib/librte_hash/rte_hash.c| 10 ++-- lib/librte_ip_frag/rte_ip_frag_common.c | 2 +- lib/librte_lpm/rte_lpm.c | 4 +- lib/librte_lpm/rte_lpm6.c | 4 +- lib/librte_malloc/malloc_elem.c | 4 +- lib/librte_malloc/malloc_elem.h | 2 +- lib/librte_malloc/malloc_heap.c | 6 +-- lib/librte_malloc/rte_malloc.c| 2 +- lib/librte_mempool/rte_mempool.c | 24 +- lib/librte_mempool/rte_mempool.h | 2 +- lib/librte_pipeline/rte_pipeline.c| 4 +- lib/librte_pmd_e1000/em_rxtx.c| 10 ++-- lib/librte_pmd_e1000/igb_rxtx.c | 8 ++-- lib/librte_pmd_i40e/i40e_rxtx.c | 8 ++-- lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 8 ++-- lib/librte_pmd_virtio/virtio_ethdev.c | 10 ++-- lib/librte_pmd_virtio/virtio_rxtx.c | 2 +- lib/librte_pmd_vmxnet3/vmxnet3_ethdev.c | 2 +- lib/librte_pmd_vmxnet3/vmxnet3_rxtx.c | 8 ++-- lib/librte_pmd_xenvirt/rte_eth_xenvirt.c | 6 +-- lib/librte_port/rte_port_ethdev.c | 4 +- lib/librte_port/rte_port_frag.c | 2 +- lib/librte_port/rte_port_ras.c| 2 +- lib/librte_port/rte_port_ring.c | 4 +- lib/librte_port/rte_port_sched.c | 4 +- lib/librte_port/rte_port_source_sink.c| 2 +- lib/librte_ring/rte_ring.c| 12 ++--- lib/librte_sched/rte_bitmap.h | 8 ++-- lib/librte_sched/rte_sched.c | 16 +++ lib/librte_table/rte_table_acl.c | 10 ++-- lib/librte_table/rte_table_array.c| 8 ++-- lib/librte_table/rte_table_hash_ext.c | 20 lib/librte_table/rte_table_hash_key16.c | 36 +++
[dpdk-dev] [PATCH 3/3] Add RTE_ prefix to CACHE_LINE_ROUNDUP macro
Adding RTE_ for consistency with other renamed macros and to avoid
potential conflicts.
Signed-off-by: Sergio Gonzalez Monroy
---
app/test-pmd/testpmd.c | 2 +-
lib/librte_eal/common/include/rte_memory.h | 2 +-
lib/librte_malloc/malloc_heap.c| 4 ++--
lib/librte_malloc/rte_malloc.c | 2 +-
lib/librte_sched/rte_sched.c | 14 +++---
lib/librte_table/rte_table_acl.c | 6 +++---
lib/librte_table/rte_table_hash_ext.c | 14 +++---
lib/librte_table/rte_table_hash_lru.c | 10 +-
8 files changed, 27 insertions(+), 27 deletions(-)
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 5f96899..7552bf9 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -444,7 +444,7 @@ mbuf_pool_create(uint16_t mbuf_seg_size, unsigned nb_mbuf,
mbp_ctor_arg.seg_buf_size = (uint16_t) (RTE_PKTMBUF_HEADROOM +
mbuf_seg_size);
mb_ctor_arg.seg_buf_offset =
- (uint16_t) CACHE_LINE_ROUNDUP(sizeof(struct rte_mbuf));
+ (uint16_t) RTE_CACHE_LINE_ROUNDUP(sizeof(struct rte_mbuf));
mb_ctor_arg.seg_buf_size = mbp_ctor_arg.seg_buf_size;
mb_size = mb_ctor_arg.seg_buf_offset + mb_ctor_arg.seg_buf_size;
mbuf_poolname_build(socket_id, pool_name, sizeof(pool_name));
diff --git a/lib/librte_eal/common/include/rte_memory.h
b/lib/librte_eal/common/include/rte_memory.h
index ab20c4b..05e55b9 100644
--- a/lib/librte_eal/common/include/rte_memory.h
+++ b/lib/librte_eal/common/include/rte_memory.h
@@ -64,7 +64,7 @@ enum rte_page_sizes {
#endif
#define RTE_CACHE_LINE_MASK (RTE_CACHE_LINE_SIZE-1) /**< Cache line mask. */
-#define CACHE_LINE_ROUNDUP(size) \
+#define RTE_CACHE_LINE_ROUNDUP(size) \
(RTE_CACHE_LINE_SIZE * ((size + RTE_CACHE_LINE_SIZE - 1) /
RTE_CACHE_LINE_SIZE))
/**< Return the first cache-aligned value greater or equal to size. */
diff --git a/lib/librte_malloc/malloc_heap.c b/lib/librte_malloc/malloc_heap.c
index a1d0ebb..95fcfec 100644
--- a/lib/librte_malloc/malloc_heap.c
+++ b/lib/librte_malloc/malloc_heap.c
@@ -155,8 +155,8 @@ void *
malloc_heap_alloc(struct malloc_heap *heap,
const char *type __attribute__((unused)), size_t size, unsigned
align)
{
- size = CACHE_LINE_ROUNDUP(size);
- align = CACHE_LINE_ROUNDUP(align);
+ size = RTE_CACHE_LINE_ROUNDUP(size);
+ align = RTE_CACHE_LINE_ROUNDUP(align);
rte_spinlock_lock(&heap->lock);
struct malloc_elem *elem = find_suitable_element(heap, size, align);
if (elem == NULL){
diff --git a/lib/librte_malloc/rte_malloc.c b/lib/librte_malloc/rte_malloc.c
index ee36357..b966fc7 100644
--- a/lib/librte_malloc/rte_malloc.c
+++ b/lib/librte_malloc/rte_malloc.c
@@ -169,7 +169,7 @@ rte_realloc(void *ptr, size_t size, unsigned align)
if (elem == NULL)
rte_panic("Fatal error: memory corruption detected\n");
- size = CACHE_LINE_ROUNDUP(size), align = CACHE_LINE_ROUNDUP(align);
+ size = RTE_CACHE_LINE_ROUNDUP(size), align =
RTE_CACHE_LINE_ROUNDUP(align);
/* check alignment matches first, and if ok, see if we can resize block
*/
if (RTE_PTR_ALIGN(ptr,align) == ptr &&
malloc_elem_resize(elem, size) == 0)
diff --git a/lib/librte_sched/rte_sched.c b/lib/librte_sched/rte_sched.c
index 1447a27..95dee27 100644
--- a/lib/librte_sched/rte_sched.c
+++ b/lib/librte_sched/rte_sched.c
@@ -417,25 +417,25 @@ rte_sched_port_get_array_base(struct
rte_sched_port_params *params, enum rte_sch
base = 0;
if (array == e_RTE_SCHED_PORT_ARRAY_SUBPORT) return base;
- base += CACHE_LINE_ROUNDUP(size_subport);
+ base += RTE_CACHE_LINE_ROUNDUP(size_subport);
if (array == e_RTE_SCHED_PORT_ARRAY_PIPE) return base;
- base += CACHE_LINE_ROUNDUP(size_pipe);
+ base += RTE_CACHE_LINE_ROUNDUP(size_pipe);
if (array == e_RTE_SCHED_PORT_ARRAY_QUEUE) return base;
- base += CACHE_LINE_ROUNDUP(size_queue);
+ base += RTE_CACHE_LINE_ROUNDUP(size_queue);
if (array == e_RTE_SCHED_PORT_ARRAY_QUEUE_EXTRA) return base;
- base += CACHE_LINE_ROUNDUP(size_queue_extra);
+ base += RTE_CACHE_LINE_ROUNDUP(size_queue_extra);
if (array == e_RTE_SCHED_PORT_ARRAY_PIPE_PROFILES) return base;
- base += CACHE_LINE_ROUNDUP(size_pipe_profiles);
+ base += RTE_CACHE_LINE_ROUNDUP(size_pipe_profiles);
if (array == e_RTE_SCHED_PORT_ARRAY_BMP_ARRAY) return base;
- base += CACHE_LINE_ROUNDUP(size_bmp_array);
+ base += RTE_CACHE_LINE_ROUNDUP(size_bmp_array);
if (array == e_RTE_SCHED_PORT_ARRAY_QUEUE_ARRAY) return base;
- base += CACHE_LINE_ROUNDUP(size_queue_array);
+ base += RTE_CACHE_LINE_ROUNDUP(size_queue_array);
return base;
}
diff --git a/lib/librte_table/rte_table_acl.c b/lib/librte_table/rte_table_acl.c
index e
[dpdk-dev] [PATCH 1/3] Add RTE_ prefix to CACHE_LINE_SIZE macro
CACHE_LINE_SIZE is a macro defined in machine/param.h in FreeBSD and conflicts with DPDK macro version. Adding RTE_ prefix to avoid conflicts. Signed-off-by: Sergio Gonzalez Monroy --- app/test-acl/main.c | 2 +- app/test-pipeline/runtime.c | 2 +- app/test-pmd/testpmd.c| 12 +++ app/test-pmd/testpmd.h| 4 +-- app/test/test_distributor_perf.c | 2 +- app/test/test_ivshmem.c | 6 ++-- app/test/test_malloc.c| 32 - app/test/test_mbuf.c | 2 +- app/test/test_memzone.c | 26 +++--- app/test/test_pmd_perf.c | 4 +-- app/test/test_table.h | 2 +- doc/guides/sample_app_ug/kernel_nic_interface.rst | 2 +- examples/dpdk_qat/crypto.c| 2 +- examples/ip_pipeline/cmdline.c| 8 ++--- examples/ip_pipeline/init.c | 4 +-- examples/ip_pipeline/pipeline_passthrough.c | 2 +- examples/ip_pipeline/pipeline_rx.c| 2 +- examples/ip_pipeline/pipeline_tx.c| 2 +- examples/ip_reassembly/main.c | 2 +- examples/kni/main.c | 2 +- examples/multi_process/l2fwd_fork/flib.c | 4 +-- examples/multi_process/symmetric_mp/main.c| 2 +- examples/netmap_compat/lib/compat_netmap.c| 4 +-- examples/qos_sched/main.c | 4 +-- examples/vhost/main.c | 6 ++-- examples/vhost_xen/vhost_monitor.c| 4 +-- lib/librte_acl/acl_gen.c | 6 ++-- lib/librte_acl/rte_acl.c | 2 +- lib/librte_acl/rte_acl_osdep_alone.h | 6 ++-- lib/librte_distributor/rte_distributor.c | 2 +- lib/librte_eal/common/eal_common_memzone.c| 12 +++ lib/librte_eal/common/include/rte_memory.h| 10 +++--- lib/librte_ether/rte_ethdev.c | 10 +++--- lib/librte_hash/rte_hash.c| 10 +++--- lib/librte_ip_frag/rte_ip_frag_common.c | 2 +- lib/librte_lpm/rte_lpm.c | 4 +-- lib/librte_lpm/rte_lpm6.c | 4 +-- lib/librte_malloc/malloc_elem.c | 4 +-- lib/librte_malloc/malloc_elem.h | 2 +- lib/librte_malloc/malloc_heap.c | 2 +- lib/librte_mempool/rte_mempool.c | 8 ++--- lib/librte_mempool/rte_mempool.h | 2 +- lib/librte_pipeline/rte_pipeline.c| 4 +-- lib/librte_pmd_e1000/em_rxtx.c| 10 +++--- lib/librte_pmd_e1000/igb_rxtx.c | 8 ++--- lib/librte_pmd_i40e/i40e_rxtx.c | 8 ++--- lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 8 ++--- lib/librte_pmd_virtio/virtio_ethdev.c | 10 +++--- lib/librte_pmd_virtio/virtio_rxtx.c | 2 +- lib/librte_pmd_vmxnet3/vmxnet3_ethdev.c | 2 +- lib/librte_pmd_vmxnet3/vmxnet3_rxtx.c | 8 ++--- lib/librte_pmd_xenvirt/rte_eth_xenvirt.c | 6 ++-- lib/librte_port/rte_port_ethdev.c | 4 +-- lib/librte_port/rte_port_frag.c | 2 +- lib/librte_port/rte_port_ras.c| 2 +- lib/librte_port/rte_port_ring.c | 4 +-- lib/librte_port/rte_port_sched.c | 4 +-- lib/librte_port/rte_port_source_sink.c| 2 +- lib/librte_ring/rte_ring.c| 2 +- lib/librte_sched/rte_bitmap.h | 6 ++-- lib/librte_sched/rte_sched.c | 2 +- lib/librte_table/rte_table_acl.c | 4 +-- lib/librte_table/rte_table_array.c| 8 ++--- lib/librte_table/rte_table_hash_ext.c | 6 ++-- lib/librte_table/rte_table_hash_key16.c | 36 +-- lib/librte_table/rte_table_hash_key32.c | 44 +++ lib/librte_table/rte_table_hash_key8.c| 28 +++ lib/librte_table/rte_table_hash_lru.c | 6 ++-- lib/librte_table/rte_table_lpm.c | 2 +- lib/librte_table/rte_table_lpm_ipv6.c | 2 +- 70 files changed, 230 insertions(+), 230 deletions(-) diff --git a/app/test-acl/main.c b/app/test-acl/main.c index 44add10..a2c127f 100644 --- a/app/test-acl/main.c +++ b/app/test-acl/main.c @@ -470,7 +470,7 @@ tracef_init(void) struct ipv6_5tuple *w; sz = config.nb_traces * (config.ipv6 ? sizeof(*w) : sizeof(*v)); - config.traces = rte_zmalloc_socket(name, sz, CACHE_LINE_SIZE, + config.traces = rte_zmalloc_socket(name, sz, RTE_CACHE_LINE_SIZE, SOCKET_ID_ANY);
[dpdk-dev] [PATCH 2/3] Add RTE_ prefix to CACHE_LINE_MASK macro
Adding RTE_ for consistency with other renamed macros and to avoid
potential conflicts.
Signed-off-by: Sergio Gonzalez Monroy
---
app/test/test_memzone.c| 32 +++---
lib/librte_acl/rte_acl_osdep_alone.h | 2 +-
lib/librte_distributor/rte_distributor.c | 2 +-
lib/librte_eal/common/eal_common_memzone.c | 14 ++---
lib/librte_eal/common/include/rte_memory.h | 2 +-
lib/librte_mempool/rte_mempool.c | 18 -
lib/librte_ring/rte_ring.c | 10 +-
lib/librte_sched/rte_bitmap.h | 2 +-
8 files changed, 41 insertions(+), 41 deletions(-)
diff --git a/app/test/test_memzone.c b/app/test/test_memzone.c
index b665fce..eeaac1f 100644
--- a/app/test/test_memzone.c
+++ b/app/test/test_memzone.c
@@ -283,7 +283,7 @@ test_memzone_reserve_max(void)
/* align everything */
last_addr = RTE_PTR_ALIGN_CEIL(ms[memseg_idx].addr,
RTE_CACHE_LINE_SIZE);
len = ms[memseg_idx].len - RTE_PTR_DIFF(last_addr,
ms[memseg_idx].addr);
- len &= ~((size_t) CACHE_LINE_MASK);
+ len &= ~((size_t) RTE_CACHE_LINE_MASK);
/* cycle through all memzones */
for (memzone_idx = 0; memzone_idx < RTE_MAX_MEMZONE;
memzone_idx++) {
@@ -376,7 +376,7 @@ test_memzone_reserve_max_aligned(void)
/* align everything */
last_addr = RTE_PTR_ALIGN_CEIL(ms[memseg_idx].addr,
RTE_CACHE_LINE_SIZE);
len = ms[memseg_idx].len - RTE_PTR_DIFF(last_addr,
ms[memseg_idx].addr);
- len &= ~((size_t) CACHE_LINE_MASK);
+ len &= ~((size_t) RTE_CACHE_LINE_MASK);
/* cycle through all memzones */
for (memzone_idx = 0; memzone_idx < RTE_MAX_MEMZONE;
memzone_idx++) {
@@ -474,11 +474,11 @@ test_memzone_aligned(void)
printf("Unable to reserve 64-byte aligned memzone!\n");
return -1;
}
- if ((memzone_aligned_32->phys_addr & CACHE_LINE_MASK) != 0)
+ if ((memzone_aligned_32->phys_addr & RTE_CACHE_LINE_MASK) != 0)
return -1;
- if (((uintptr_t) memzone_aligned_32->addr & CACHE_LINE_MASK) != 0)
+ if (((uintptr_t) memzone_aligned_32->addr & RTE_CACHE_LINE_MASK) != 0)
return -1;
- if ((memzone_aligned_32->len & CACHE_LINE_MASK) != 0)
+ if ((memzone_aligned_32->len & RTE_CACHE_LINE_MASK) != 0)
return -1;
if (memzone_aligned_128 == NULL) {
@@ -489,7 +489,7 @@ test_memzone_aligned(void)
return -1;
if (((uintptr_t) memzone_aligned_128->addr & 127) != 0)
return -1;
- if ((memzone_aligned_128->len & CACHE_LINE_MASK) != 0)
+ if ((memzone_aligned_128->len & RTE_CACHE_LINE_MASK) != 0)
return -1;
if (memzone_aligned_256 == NULL) {
@@ -500,7 +500,7 @@ test_memzone_aligned(void)
return -1;
if (((uintptr_t) memzone_aligned_256->addr & 255) != 0)
return -1;
- if ((memzone_aligned_256->len & CACHE_LINE_MASK) != 0)
+ if ((memzone_aligned_256->len & RTE_CACHE_LINE_MASK) != 0)
return -1;
if (memzone_aligned_512 == NULL) {
@@ -511,7 +511,7 @@ test_memzone_aligned(void)
return -1;
if (((uintptr_t) memzone_aligned_512->addr & 511) != 0)
return -1;
- if ((memzone_aligned_512->len & CACHE_LINE_MASK) != 0)
+ if ((memzone_aligned_512->len & RTE_CACHE_LINE_MASK) != 0)
return -1;
if (memzone_aligned_1024 == NULL) {
@@ -522,7 +522,7 @@ test_memzone_aligned(void)
return -1;
if (((uintptr_t) memzone_aligned_1024->addr & 1023) != 0)
return -1;
- if ((memzone_aligned_1024->len & CACHE_LINE_MASK) != 0)
+ if ((memzone_aligned_1024->len & RTE_CACHE_LINE_MASK) != 0)
return -1;
/* check that zones don't overlap */
@@ -588,7 +588,7 @@ check_memzone_bounded(const char *name, uint32_t len,
uint32_t align,
return (-1);
}
- if ((mz->len & CACHE_LINE_MASK) != 0 || mz->len < len ||
+ if ((mz->len & RTE_CACHE_LINE_MASK) != 0 || mz->len < len ||
mz->len < RTE_CACHE_LINE_SIZE) {
printf("%s(%s): invalid length\n",
__func__, mz->name);
@@ -952,17 +952,17 @@ test_memzone(void)
/* check cache-line alignments */
printf("check alignments and lengths\n");
- if ((memzone1->phys_addr & CACHE_LINE_MASK) != 0)
+ if ((memzone1->phys_addr & RTE_CACHE_LINE_MASK) != 0)
return -1;
- if ((memzone2->phys_addr & CACHE_LINE_MASK) != 0)
+ if ((memzone2->phys_addr & RTE_CACHE_LINE_MASK) != 0)
return -1;
- if (memzone3 != NULL && (memzone3->phys_addr & CACHE_LINE_MASK) != 0)
+ if (memzone3 != NULL && (memzone3-
[dpdk-dev] [PATCH] xenvirt: fix reference to old mbuf field
data is not an mbuf field anymore.
Signed-off-by: Sergio Gonzalez Monroy
---
lib/librte_pmd_xenvirt/virtqueue.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/librte_pmd_xenvirt/virtqueue.h
b/lib/librte_pmd_xenvirt/virtqueue.h
index d8717fe..34a24fc 100644
--- a/lib/librte_pmd_xenvirt/virtqueue.h
+++ b/lib/librte_pmd_xenvirt/virtqueue.h
@@ -54,7 +54,7 @@
* rather than gpa<->hva in virito spec.
*/
#define RTE_MBUF_DATA_DMA_ADDR(mb) \
- ((uint64_t)((mb)->data))
+ rte_pktmbuf_mtod(mb, uint64_t)
enum { VTNET_RQ = 0, VTNET_TQ = 1, VTNET_CQ = 2 };
--
1.9.3
[dpdk-dev] Community conference call - Tuesday 18th November
Thanks again to those who attended the call yesterday. There was a good discussion, and it was more interactive than the previous call, which is what we were aiming for. We'll schedule a follow-up call for 2 weeks' time. Thanks again to those who presented on the following features: - ABI Versioning (Neil Horman ) - Uio_pci_generic (Danny.Zhou at intel.com) - Integrated Qemu Userspace vHost (Huawei.Xie at intel.com) I have a recording of the session, and will send a link to it soon for anybody who missed the call. Tim > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of O'driscoll, Tim > Sent: Tuesday, November 18, 2014 12:56 PM > To: 'dev at dpdk.org' > Subject: Re: [dpdk-dev] Community conference call - Tuesday 18th > November > > This is just a reminder of our call later today, which is at 17:00 GMT. The > time > in a variety of timezones is included below. > > We're going to use GoToMeeting this time. If you follow the meeting link > (https://global.gotomeeting.com/join/843960205), the GoToMeeting web > viewer will start. You then have two options for audio: > > 1. You can join using a phone via one of the numbers listed below. The > Access Code is 843-960-205. You'll also be asked for an Audio PIN, which is > accessible by clicking the phone icon in the GoToMeeting web viewer after > you've joined the meeting. > > 2. To use your computer's audio via a headset, you need to switch to the > desktop version of GoToMeeting. You can do this by clicking the > GoToMeeting icon on the top right hand side of the web viewer, and then > selecting "Switch to the desktop version". The desktop version will need to > download and install, so if you plan to use this you may want to get it set up > in advance. Once it starts, under the Audio section, you can select "Mic & > Speakers". The desktop version is only available for Windows and Mac, so if > you're using Linux then you need to use option 1 above. > > Info on downloading the desktop app is available at: > http://support.citrixonline.com/en_US/meeting/help_files/G2M010002?title > =Download%7D > Info on the web viewer is available at: > http://support.citrixonline.com/en_US/GoToMeeting/help_files/GTM13001 > 9?title=Web+Viewer+FAQs > > I plan to record the session in GoToMeeting, and make that recording > available for anybody who can't attend today. > > > Tim > > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of O'driscoll, Tim > > Sent: Friday, November 14, 2014 10:53 AM > > To: 'dev at dpdk.org' > > Subject: Re: [dpdk-dev] Community conference call - Tuesday 18th > > November > > > > Firstly, due to some conflicts, we're going to move next Tuesday's > > meeting to > > 1 hour later. Apologies for the short notice on the change. Here's the > > new meeting time in a variety of timezones: > > > > Dublin (Ireland)Tuesday, November 18, 2014 at > 5:00:00 PMGMT UTC > > San Francisco (U.S.A. - California) Tuesday, November 18, 2014 at > 9:00:00 AMPST UTC-8 hours > > Phoenix (U.S.A. - Arizona) Tuesday, November 18, 2014 at > 10:00:00 AM MST UTC-7 hours > > New York (U.S.A. - New York)Tuesday, November 18, 2014 > at 12:00:00 Noon EST UTC-5 hours > > Ottawa (Canada - Ontario) Tuesday, November 18, 2014 at > 12:00:00 Noon EST UTC-5 hours > > Paris (France) Tuesday, November 18, 2014 at > 6:00:00 PMCET UTC+1 hour > > Tel Aviv (Israel) Tuesday, November 18, 2014 at > 7:00:00 PMIST UTC+2 hours > > Moscow (Russia) Tuesday, November 18, 2014 at > 8:00:00 PMMSK UTC+3 hours > > Beijing (China - Beijing Municipality) Wednesday, November 19, 2014 at > 1:00:00 AM CST UTC+8 hours > > Tokyo (Japan) Wednesday, November 19, 2014 at > 2:00:00 AM JST UTC+9 hours > > Corresponding UTC (GMT) Tuesday, November 18, 2014 at > 17:00:00 > > > > > > Secondly, we're going to try using GoToMeeting this time. Here are the > > details: > > 1. Please join my meeting from your computer, tablet or smartphone on > > Tue, Nov 18, 5:00 PM GMT Standard Time > > https://global.gotomeeting.com/join/843960205 > > > > 2. Use your microphone and speakers (VOIP) for audio. You'll sound > > best with a headset. You can also call in using your telephone. > > ? United Kingdom (Long distance): +44 (0) 20 7151 1818 > > ? Australia (Long distance): +61 2 8355 1034 > > ? Sweden (Long distance): +46 (0) 852 500 182 > > ? Canada (Long distance): +1 (647) 497-9372 > > ? Finland (Long distance): +358 (0) 942 45 0382 > > ? Ireland (Long distance): +353 (0) 15 255 598 > > ? Germany (Long distance): +49 (0) 692 5736 7206 > > ? Italy (Long distance): +39 0 693 38 75 53 > > ? Netherlands (Long distance): +31 (0) 208 080 212 > > ? Austria (Long distance): +43 (0) 7 2088 3707 > > ? Belgium (Long distance): +32 (0) 28 08 9460 > > ? United
[dpdk-dev] [PATCH v2 1/4] doc: Added new commands in testpmd UG
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara > Sent: Tuesday, November 18, 2014 5:05 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v2 1/4] doc: Added new commands in testpmd UG > > Added info in testpmd functions section for the following commands: > > - tunnel_filter add > - tunnel_filter rm > - rx_vxlan_port add > - rx_vxlan_port rm > - port stop/start queue > - set port mac address filter (for VF) > > Signed-off-by: Pablo de Lara Acked-by: Bernard Iremonger I have applied the patch to my tree next/dpdk-doc. > --- > doc/guides/testpmd_app_ug/testpmd_funcs.rst | 47 > +++ > 1 files changed, 47 insertions(+), 0 deletions(-) >
[dpdk-dev] [PATCH v2 2/4] doc: Corrected info for tx_checksum set mask function, in testpmd UG
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara > Sent: Tuesday, November 18, 2014 5:05 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v2 2/4] doc: Corrected info for tx_checksum set > mask function, in > testpmd UG > > tx_checksum set mask function now allows 4 extra bits in the mask for TX > checksum offload > > Signed-off-by: Pablo de Lara Acked-by: Bernard Iremonger I have applied the patch to my tree next/dpdk-doc. > --- > doc/guides/testpmd_app_ug/testpmd_funcs.rst | 10 +- > 1 files changed, 9 insertions(+), 1 deletions(-) >
[dpdk-dev] [PATCH v2 3/4] doc: Moved commands in testpmd UG to match testpmd command help order
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara > Sent: Tuesday, November 18, 2014 5:05 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v2 3/4] doc: Moved commands in testpmd UG to match > testpmd > command help order > > Moved commands in testpmd UG to set queue rates to match order in testpmd > command help. > > Created new section "Filters" to match that same section in testpmd UG, and > moved all commands > related to it there. > > Signed-off-by: Pablo de Lara Acked-by: Bernard Iremonger I have applied the patch to my tree next/dpdk-doc. > --- > doc/guides/testpmd_app_ug/testpmd_funcs.rst | 1019 > ++- > 1 files changed, 512 insertions(+), 507 deletions(-)
[dpdk-dev] [PATCH v2 4/4] doc: Various document fixes in testpmd UG
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pablo de Lara > Sent: Tuesday, November 18, 2014 5:05 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v2 4/4] doc: Various document fixes in testpmd UG > > Signed-off-by: Pablo de Lara Acked-by: Bernard Iremonger I have applied the patch to my tree next/dpdk-doc. > --- > doc/guides/testpmd_app_ug/testpmd_funcs.rst | 10 ++ > 1 files changed, 6 insertions(+), 4 deletions(-)
[dpdk-dev] [PATCH v4 2/2] testpmd: add mode 4 support
Sorry I missed extra comments here:
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Michal Jastrzebski
> Sent: Tuesday, November 18, 2014 4:31 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v4 2/2] testpmd: add mode 4 support
>
> From: Pawel Wodkowski
>
>
> Signed-off-by: Pawel Wodkowski
> ---
> app/test-pmd/cmdline.c | 28 +++--
> app/test-pmd/csumonly.c |9
> app/test-pmd/icmpecho.c | 17 ++-
> app/test-pmd/iofwd.c|9
> app/test-pmd/macfwd-retry.c |9
> app/test-pmd/macfwd.c |9
> app/test-pmd/macswap.c |9
> app/test-pmd/testpmd.c | 48
> +--
> app/test-pmd/testpmd.h | 11 --
> 9 files changed, 138 insertions(+), 11 deletions(-)
>
[...]
> diff --git a/app/test-pmd/icmpecho.c b/app/test-pmd/icmpecho.c
> index 7fd4b6d..e954601 100644
> --- a/app/test-pmd/icmpecho.c
> +++ b/app/test-pmd/icmpecho.c
> @@ -305,6 +305,9 @@ reply_to_icmp_echo_rqsts(struct fwd_stream *fs)
> uint16_t arp_pro;
> uint8_t i;
> int l2_len;
> +#if RTE_LIBRTE_PMD_BOND
Should be #ifdef
> + uint8_t force_tx_burst;
> +#endif
> #ifdef RTE_TEST_PMD_RECORD_CORE_CYCLES
> uint64_t start_tsc;
> uint64_t end_tsc;
> @@ -320,8 +323,20 @@ reply_to_icmp_echo_rqsts(struct fwd_stream *fs)
>*/
> nb_rx = rte_eth_rx_burst(fs->rx_port, fs->rx_queue, pkts_burst,
>nb_pkt_per_burst);
[...]
> index 5740804..68e2987 100644
> --- a/app/test-pmd/testpmd.c
> +++ b/app/test-pmd/testpmd.c
> @@ -72,6 +72,9 @@
> #include
> #include
> #include
> +#ifdef RTE_LIBRTE_PMD_BOND
> +#include
> +#endif
[...]
> +#ifdef RTE_LIBRTE_PMD_BOND
> + is_mode4 = ports[fs->rx_port].bond_mode ==
> BONDING_MODE_8023AD ||
> + ports[fs->tx_port].bond_mode ==
> BONDING_MODE_8023AD;
> +
> + if (is_mode4) {
> + if (cur_fwd_config.fwd_eng == &rx_only_engine ||
> + cur_fwd_config.fwd_eng ==
> &tx_only_engine
> +#ifdef RTE_LIBRTE_IEEE1588
> + || cur_fwd_config.fwd_eng ==
> &ieee1588_fwd_engine,
Remove that comma.
> +#endif
> + ) {
> + printf("Selected forwarding engine '%s' is not
> supported in "
> + "mode 802.3ad of link bonding.\n",
> + cur_fwd_config.fwd_eng-
> >fwd_mode_name);
> +
> + return;
> + }
> + fs->forward_timeout = 100 * rte_get_tsc_hz() / 1000;
> + fs->next_forward_time = 0; /* force forward */
> + } else
> + fs->forward_timeout = 0; /* force forward is disabled
> */
[...]
[dpdk-dev] [PATCH v6 0/3] Support configuring hash functions
These patches mainly support configuring hash functions. In detail, - It can get or set hash functions. - It can configure symmetric hash functions. * Get/set symmetric hash enable per port. * Get/set symmetric hash enable per flow type. * Get/set filter swap configurations. - Six commands have been implemented in testpmd to support testing above. * get_sym_hash_ena_per_port * set_sym_hash_ena_per_port * get_sym_hash_ena_per_flow_type * set_sym_hash_ena_per_flow_type * get_filter_swap * set_filter_swap * get_hash_function * set_hash_function It also uses constant hash keys to replace runtime generating hash keys. Global initialization is added to correctly put registers to an initial state. v3 changes: * Removed renamings in rte_ethdev.h. * Redesigned filter control API and its relevant structures/enums. * Renamed header file from rte_eth_features.h to rte_eth_ctrol.h. * Remove public header file of rte_i40e.h specific for i40e. * Added hardware initialization function during port init. * Used constant random hash keys in i40e PF. * renamed the commands in testpmd based on the redesigned filter control API. v4 changes: * Fixed a bug in testpmd to support 'set_sym_hash_ena_per_port'. v5 changes: * Integrated with filter API defined recently. * Remove all for filter API definition, as it has already defined and merged recently. v6 changes: * Flow type strings are used to replace Packet Classification Types, to isolate hardware specific things. * Implemented the mapping function to convert RSS offload types to Packet Classification Types, to isolate the real hardware specific things. * Removed initialization of global registers in i40e PMD, as global registers shouldn't be initialized per port. * Added more annotations to get code more understandable. * Corrected annotation format for documenation. Helin Zhang (3): i40e: Use constant as the default hash keys i40e: support of controlling hash functions app/testpmd: add commands to support hash functions app/test-pmd/cmdline.c| 628 ++ lib/librte_ether/rte_eth_ctrl.h | 98 +- lib/librte_pmd_i40e/i40e_ethdev.c | 403 +++- 3 files changed, 1117 insertions(+), 12 deletions(-) -- 1.8.1.4
[dpdk-dev] [PATCH v6 1/3] i40e: Use constant as the default hash keys
Calculating the default RSS hash keys at run time is not needed at
all, and may have race conditions. The alternative is to use array
of random values which were generated manually as the default hash
keys.
Signed-off-by: Helin Zhang
---
lib/librte_pmd_i40e/i40e_ethdev.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/lib/librte_pmd_i40e/i40e_ethdev.c
b/lib/librte_pmd_i40e/i40e_ethdev.c
index 5074262..9096802 100644
--- a/lib/librte_pmd_i40e/i40e_ethdev.c
+++ b/lib/librte_pmd_i40e/i40e_ethdev.c
@@ -92,7 +92,7 @@
#define I40E_48_BIT_SHIFT 48
#define I40E_48_BIT_MASK 0xULL
-/* Default queue interrupt throttling time in microseconds*/
+/* Default queue interrupt throttling time in microseconds */
#define I40E_ITR_INDEX_DEFAULT 0
#define I40E_QUEUE_ITR_INTERVAL_DEFAULT 32 /* 32 us */
#define I40E_QUEUE_ITR_INTERVAL_MAX 8160 /* 8160 us */
@@ -210,9 +210,6 @@ static int i40e_dev_filter_ctrl(struct rte_eth_dev *dev,
enum rte_filter_op filter_op,
void *arg);
-/* Default hash key buffer for RSS */
-static uint32_t rss_key_default[I40E_PFQF_HKEY_MAX_INDEX + 1];
-
static struct rte_pci_id pci_id_i40e_map[] = {
#define RTE_PCI_DEV_ID_DECL_I40E(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
#include "rte_pci_dev_ids.h"
@@ -4893,9 +4890,12 @@ i40e_pf_config_rss(struct i40e_pf *pf)
}
if (rss_conf.rss_key == NULL || rss_conf.rss_key_len <
(I40E_PFQF_HKEY_MAX_INDEX + 1) * sizeof(uint32_t)) {
- /* Calculate the default hash key */
- for (i = 0; i <= I40E_PFQF_HKEY_MAX_INDEX; i++)
- rss_key_default[i] = (uint32_t)rte_rand();
+ /* Random default keys */
+ static uint32_t rss_key_default[] = {0x6b793944,
+ 0x23504cb5, 0x5bea75b6, 0x309f4f12, 0x3dc0a2b8,
+ 0x024ddcdf, 0x339b8ca0, 0x4c4af64a, 0x34fac605,
+ 0x55d85839, 0x3a58997d, 0x2ec938e1, 0x66031581};
+
rss_conf.rss_key = (uint8_t *)rss_key_default;
rss_conf.rss_key_len = (I40E_PFQF_HKEY_MAX_INDEX + 1) *
sizeof(uint32_t);
--
1.8.1.4
[dpdk-dev] [PATCH v6 2/3] i40e: support of controlling hash functions
Hash filter control has been implemented for i40e. It includes
getting/setting,
- hash function type
- symmetric hash enable per pctype (packet classification type)
- symmetric hash enable per port
- filter swap configuration
Signed-off-by: Helin Zhang
---
lib/librte_ether/rte_eth_ctrl.h | 98 +-
lib/librte_pmd_i40e/i40e_ethdev.c | 389 ++
2 files changed, 482 insertions(+), 5 deletions(-)
v5 changes:
* Integrated with filter API defined recently.
v6 changes:
* Implemented the mapping function to convert RSS offload types to
Packet Classification Types, to isolate the real hardware
specific things.
* Removed initialization of global registers in i40e PMD, as global
registers shouldn't be initialized per port.
* Added more annotations to get code more understandable.
* Corrected annotation format for documenation.
diff --git a/lib/librte_ether/rte_eth_ctrl.h b/lib/librte_ether/rte_eth_ctrl.h
index 8dd384d..1dab7d0 100644
--- a/lib/librte_ether/rte_eth_ctrl.h
+++ b/lib/librte_ether/rte_eth_ctrl.h
@@ -51,6 +51,7 @@ extern "C" {
*/
enum rte_filter_type {
RTE_ETH_FILTER_NONE = 0,
+ RTE_ETH_FILTER_HASH,
RTE_ETH_FILTER_MACVLAN,
RTE_ETH_FILTER_TUNNEL,
RTE_ETH_FILTER_MAX
@@ -60,29 +61,116 @@ enum rte_filter_type {
* Generic operations on filters
*/
enum rte_filter_op {
+ /** used to check whether the type filter is supported */
RTE_ETH_FILTER_NOP = 0,
- /**< used to check whether the type filter is supported */
RTE_ETH_FILTER_ADD, /**< add filter entry */
RTE_ETH_FILTER_UPDATE, /**< update filter entry */
RTE_ETH_FILTER_DELETE, /**< delete filter entry */
RTE_ETH_FILTER_FLUSH,/**< flush all entries */
RTE_ETH_FILTER_GET, /**< get filter entry */
RTE_ETH_FILTER_SET, /**< configurations */
+ /** get information of filter, such as status or statistics */
RTE_ETH_FILTER_INFO,
- /**< get information of filter, such as status or statistics */
RTE_ETH_FILTER_OP_MAX
};
/**
+ * Hash filter information types.
+ * - RTE_ETH_HASH_FILTER_SYM_HASH_ENA_PER_FLOW_TYPE is for getting/setting the
+ * information/configuration of 'symmetric hash enable' per flow type.
+ * - RTE_ETH_HASH_FILTER_SYM_HASH_ENA_PER_PORT is for getting/setting the
+ * information/configuration of 'symmetric hash enable' per port.
+ * - RTE_ETH_HASH_FILTER_SWAP is for getting/setting the swap
+ * information/configuration which is for symmetric hash function.
+ * - RTE_ETH_HASH_FILTER_HASH_FUNCTION is for getting/setting the hash function
+ * which could be Toeplitz or Simple Xor.
+ */
+enum rte_eth_hash_filter_info_type {
+ RTE_ETH_HASH_FILTER_INFO_TYPE_UNKNOWN = 0,
+ /** Symmetric hash enable per flow type */
+ RTE_ETH_HASH_FILTER_SYM_HASH_ENA_PER_FLOW_TYPE,
+ /** Symmetric hash enable per port */
+ RTE_ETH_HASH_FILTER_SYM_HASH_ENA_PER_PORT,
+ /** Hash filter swap */
+ RTE_ETH_HASH_FILTER_SWAP,
+ /** Hash function */
+ RTE_ETH_HASH_FILTER_HASH_FUNCTION,
+ RTE_ETH_HASH_FILTER_INFO_TYPE_MAX,
+};
+
+/**
+ * Hash function types.
+ */
+enum rte_eth_hash_function {
+ RTE_ETH_HASH_FUNCTION_UNKNOWN = 0,
+ RTE_ETH_HASH_FUNCTION_TOEPLITZ, /**< Toeplitz */
+ RTE_ETH_HASH_FUNCTION_SIMPLE_XOR, /**< Simple XOR */
+ RTE_ETH_HASH_FUNCTION_MAX,
+};
+
+/**
+ * A structure used to set or get symmetric hash enable information, to support
+ * 'RTE_ETH_FILTER_HASH', 'RTE_ETH_FILTER_GET/RTE_ETH_FILTER_SET', with
+ * information type 'RTE_ETH_HASH_FILTER_SYM_HASH_ENA_PER_FLOW_TYPE'.
+ * The flow type could be 'ETH_RSS_<*>_SHIFT' which is defined in rte_ethdev.h.
+ */
+struct rte_eth_sym_hash_ena_info {
+ /** Flow type, defined in rte_ethdev.h */
+ uint8_t flow_type;
+ uint8_t enable; /**< Enable or disable flag */
+};
+
+/**
+ * A structure used to set or get filter swap information, to support
+ * 'RTE_ETH_FILTER_HASH', 'RTE_ETH_FILTER_GET/RTE_ETH_FILTER_SET',
+ * with information type 'RTE_ETH_HASH_FILTER_SWAP'.
+ * The flow type could be 'ETH_RSS_<*>_SHIFT' which is defined in rte_ethdev.h.
+ */
+struct rte_eth_filter_swap_info {
+ /** Flow type, defined in rte_ethdev.h */
+ uint8_t flow_type;
+ /** Offset of the 1st field of the 1st couple to be swapped. */
+ uint8_t off0_src0;
+ /** Offset of the 2nd field of the 1st couple to be swapped. */
+ uint8_t off0_src1;
+ /** Field length of the first couple. */
+ uint8_t len0;
+ /** Offset of the 1st field of the 2nd couple to be swapped. */
+ uint8_t off1_src0;
+ /** Offset of the 2nd field of the 2nd couple to be swapped. */
+ uint8_t off1_src1;
+ /** Field length of the second couple. */
+ uint8_t len1;
+};
+
+/**
+ * A structure used to set or get hash filter information, to support filter
+ * type of 'RTE_ETH_FILT
[dpdk-dev] [PATCH v6 3/3] app/testpmd: add commands to support hash functions
To demonstrate the hash filter control, commands are added.
They are,
- get_sym_hash_ena_per_port
- set_sym_hash_ena_per_port
- get_sym_hash_ena_per_pctype
- set_sym_hash_ena_per_pctype
- get_filter_swap
- set_filter_swap
- get_hash_function
- set_hash_function
Signed-off-by: Helin Zhang
---
app/test-pmd/cmdline.c | 628 +
1 file changed, 628 insertions(+)
v6 changes:
* Flow type strings are used to replace Packet Classification
Types, to isolate hardware specific things.
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 4c3fc76..ce1547d 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -74,6 +74,7 @@
#include
#include
#include
+#include
#include
#include
@@ -683,6 +684,44 @@ static void cmd_help_long_parsed(void *parsed_result,
"get_flex_filter (port_id) index (idx)\n"
"get info of a flex filter.\n\n"
+
+ "get_sym_hash_ena_per_port (port_id)\n"
+ "get symmetric hash enable configuration per
port.\n\n"
+
+ "set_sym_hash_ena_per_port (port_id)"
+ " (enable|disable)\n"
+ "set symmetric hash enable configuration per port"
+ " to enable or disable.\n\n"
+
+ "get_sym_hash_ena_per_flow_type (port_id) (ipv4-udp|"
+ "ipv4-tcp|ipv4-sctp|ipv4-other|ipv4-frag|ipv6-udp|"
+ "ipv6-tcp|ipv6-sctp|ipv6-other|ipv6-frag|l2_payload)\n"
+ "get symmetric hash enable configuration per flow
type.\n\n"
+
+ "set_sym_hash_ena_per_flow_type (port_id) (ipv4-udp|"
+ "ipv4-tcp|ipv4-sctp|ipv4-other|ipv4-frag|ipv6-udp|"
+ "ipv6-tcp|ipv6-sctp|ipv6-other|ipv6-frag|l2_payload) "
+ "(enable|disable)\n"
+ "set symmetric hash enable configuration per"
+ " flow type to enable or disable.\n\n"
+
+ "get_filter_swap (port_id) (ipv4-udp|ipv4-tcp|"
+ "ipv4-sctp|ipv4-other|ipv4-frag|ipv6-udp|ipv6-tcp|"
+ "ipv6-sctp|ipv6-other|ipv6-frag|l2_payload)\n"
+ "get filter swap configurations.\n\n"
+
+ "set_filter_swap (port_id) (ipv4-udp|ipv4-tcp|"
+ "ipv4-sctp|ipv4-other|ipv4-frag|ipv6-udp|ipv6-tcp|"
+ "ipv6-sctp|ipv6-other|ipv6-frag|l2_payload) "
+ "(off0_src0) (off0_src1) (len0) (off1_src0) "
+ "(off1_src1) (len1)\n"
+ "set filter swap configurations.\n\n"
+
+ "get_hash_function (port_id)\n"
+ "get hash function of Toeplitz or Simple XOR.\n\n"
+
+ "set_hash_function (port_id) (toeplitz|simple_xor)\n"
+ "set the hash function to Toeplitz or Simple
XOR.\n\n"
);
}
}
@@ -7745,6 +7784,587 @@ cmdline_parse_inst_t cmd_get_flex_filter = {
},
};
+/* *** Classification Filters Control *** */
+static uint8_t
+parse_flow_type(const char *str)
+{
+ struct flow_type_pair {
+ char str[STR_TOKEN_SIZE];
+ uint8_t flow_type;
+ };
+ uint32_t i;
+ static const struct flow_type_pair ftype[] = {
+ {"ipv4-udp", ETH_RSS_NONF_IPV4_UDP_SHIFT},
+ {"ipv4-tcp", ETH_RSS_NONF_IPV4_TCP_SHIFT},
+ {"ipv4-sctp", ETH_RSS_NONF_IPV4_SCTP_SHIFT},
+ {"ipv4-other", ETH_RSS_NONF_IPV4_OTHER_SHIFT},
+ {"ipv4-frag", ETH_RSS_FRAG_IPV4_SHIFT},
+ {"ipv6-udp", ETH_RSS_NONF_IPV6_UDP_SHIFT},
+ {"ipv6-tcp", ETH_RSS_NONF_IPV6_TCP_SHIFT},
+ {"ipv6-sctp", ETH_RSS_NONF_IPV6_SCTP_SHIFT},
+ {"ipv6-other", ETH_RSS_NONF_IPV6_OTHER_SHIFT},
+ {"ipv6-frag", ETH_RSS_FRAG_IPV6_SHIFT},
+ {"l2_payload", ETH_RSS_L2_PAYLOAD_SHIFT},
+ };
+
+ if (!str)
+ return 0xFF;
+
+ for (i = 0; i < RTE_DIM(ftype); i++) {
+ if (!strcmp(ftype[i].str, str))
+ return ftype[i].flow_type;
+ }
+
+ return 0xFF;
+}
+
+/* *** Get symmetric hash enable per port *** */
+struct cmd_get_sym_hash_ena_per_port_result {
+ cmdline_fixed_string_t get_sym_hash_ena_per_port;
+ uint8_t port_id;
+};
+
+static void
+cmd_get_sym_hash_per_port_parsed(void *parsed_result,
+__rte_unused struct cmdline *cl,
+__rte_unused void *data)
+{
+ struct cmd_get_sym_hash_ena_per_port_result *res = parsed_result;
+ struct rte_eth_hash_filter_info info;
+ int ret;
+
+ if (rte_eth_dev_filter_supported(res->port_id,
+
[dpdk-dev] [PATCH v4 3/5] hash: add fallback to software CRC32 implementation
On Wed, Nov 19, 2014 at 11:50:40AM +, Ananyev, Konstantin wrote:
>
>
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce Richardson
> > Sent: Wednesday, November 19, 2014 11:38 AM
> > To: Neil Horman
> > Cc: dev at dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH v4 3/5] hash: add fallback to software CRC32
> > implementation
> >
> > On Wed, Nov 19, 2014 at 06:34:08AM -0500, Neil Horman wrote:
> > > On Wed, Nov 19, 2014 at 10:16:14AM +, Bruce Richardson wrote:
> > > > On Tue, Nov 18, 2014 at 04:36:24PM -0500, Neil Horman wrote:
> > > > > On Tue, Nov 18, 2014 at 05:52:27PM +, Bruce Richardson wrote:
> > > > > > On Tue, Nov 18, 2014 at 12:46:19PM -0500, Neil Horman wrote:
> > > > > > > On Tue, Nov 18, 2014 at 11:13:17PM +0600, Yerden Zhumabekov wrote:
> > > > > > > >
> > > > > > > > 18.11.2014 22:00, Neil Horman ?:
> > > > > > > > > On Tue, Nov 18, 2014 at 09:06:35PM +0600, Yerden Zhumabekov
> > > > > > > > > wrote:
> > > > > > > > >> 18.11.2014 20:41, Neil Horman ?:
> > > > > > > > >>> On Tue, Nov 18, 2014 at 08:03:40PM +0600, Yerden Zhumabekov
> > > > > > > > >>> wrote:
> > > > > > > > /**
> > > > > > > > * Use single crc32 instruction to perform a hash on a 4
> > > > > > > > byte value.
> > > > > > > > + * Fall back to software crc32 implementation in case
> > > > > > > > SSE4.2 is
> > > > > > > > + * not supported
> > > > > > > > *
> > > > > > > > * @param data
> > > > > > > > * Data to perform hash on.
> > > > > > > > @@ -376,11 +413,18 @@ crc32c_2words(uint64_t data,
> > > > > > > > uint32_t init_val)
> > > > > > > > static inline uint32_t
> > > > > > > > rte_hash_crc_4byte(uint32_t data, uint32_t init_val)
> > > > > > > > {
> > > > > > > > - return _mm_crc32_u32(init_val, data);
> > > > > > > > +#ifdef RTE_MACHINE_CPUFLAG_SSE4_2
> > > > > > > > + if (likely(crc32_alg == CRC32_SSE42))
> > > > > > > > + return _mm_crc32_u32(init_val, data);
> > > > > > > > +#endif
> > > > > > > > >>> you don't really need these ifdefs here anymore given that
> > > > > > > > >>> you have a
> > > > > > > > >>> constructor to do the algorithm selection. In fact you
> > > > > > > > >>> need to remove them, in
> > > > > > > > >>> the event you build on a system that doesn't support SSE42,
> > > > > > > > >>> but run on a system
> > > > > > > > >>> that does.
> > > > > > > > >> Originally, I thought so as well. I wrote the code without
> > > > > > > > >> these ifdefs,
> > > > > > > > >> but it didn't compile on my machine which doesn't support
> > > > > > > > >> SSE4.2. Error
> > > > > > > > >> was triggered by nmmintrin.h which has a check for
> > > > > > > > >> respective GCC
> > > > > > > > >> extension. So I think these ifdefs are indeed required.
> > > > > > > > >>
> > > > > > > > > You need to edit the makefile so that the compiler gets
> > > > > > > > > passed the option
> > > > > > > > > -msse42. That way it will know to emit sse42 instructions.
> > > > > > > > > It will also allow
> > > > > > > > > you to remove the ifdef from the include file
> > > > > > > >
> > > > > > > > In this case, I guess there are two options:
> > > > > > > > 1) modify all makefiles which use librte_hash
> > > > > > > > 2) move all function bodies from rte_hash_crc.h to separate
> > > > > > > > module,
> > > > > > > > leaving prototype definitions there only.
> > > > > > > >
> > > > > > > > Everybody's up for the second option? :)
> > > > > > > >
> > > > > > > Crud, you're right, I didn't think about the header inclusion
> > > > > > > issue. Is it
> > > > > > > worth adding the jump to enable the dynamic hash selection?
> > > > > > > Neil
> > > > > >
> > > > > > Maybe for cases where SSE4.2 is not currently available, i.e. for
> > > > > > generic builds.
> > > > > > For builds where we have hardware support confirmed at compile
> > > > > > time, just use
> > > > > > the function from the header file.
> > > > > > Does that make sense?
> > > > > >
> > > > > I'm not certain of that, as I don't think anything can be 'confirmed'
> > > > > at compile
> > > > > time. I.e. just because you have sse42 at compile time doesn't
> > > > > guarantee you
> > > > > have it at run time with a DSO. If you have these as macros, you
> > > > > need to enable
> > > > > sse42 whereever you include the file so that the intrinsic works
> > > > > properly.
> > > >
> > > > Well, if you compile with sse42 at compile time, the compiler is free
> > > > to insert
> > > > sse4 instructions at any place it feels like, irrespective of whether
> > > > or not you
> > > > use SSE4 intrinsics, so I would never expect such a DSO to work on a
> > > > system
> > > > without SSE42 support.
> > > >
> > > > >
> > > > > an alternate option would be to not use the intrinsic, and craft some
> > > > > explicit
> > > > > __asm__ statement that executes the right sse42 instruction
[dpdk-dev] [PATCH v4 3/5] hash: add fallback to software CRC32 implementation
On Wed, Nov 19, 2014 at 05:35:51PM +0600, Yerden Zhumabekov wrote:
>
> 19.11.2014 16:16, Bruce Richardson ?:
> > On Tue, Nov 18, 2014 at 04:36:24PM -0500, Neil Horman wrote:
> >> an alternate option would be to not use the intrinsic, and craft some
> >> explicit
> >> __asm__ statement that executes the right sse42 instructions. That way
> >> the asm
> >> is directly emitted, without requiring the -msse42 flag at all, and it
> >> will just
> >> work in all the files that call it.
> >>
> > I really don't like that approach. I think using intrinsics is much more
> > maintainable.
> >
>
> static inline uint32_t
> crc32_sse42_u32(uint32_t data, uint32_t init_val)
> {
> /*??__asm__ volatile(
> "crc32l %[data], %[init_val];"
> : [init_val] "+r" (init_val)
> : [data] "rm" (data));
> return init_val;*/
>
> But wait, will __builtin_ia32_crc32si and __builtin_ia32_crc32di
> functions do the trick? ICC has them?
If builtins work on both icc and gcc, yes, that would be a solution as it
creates non sse instructions when the target cpu doesn't support it.
> What about prototyping functions and extracting their bodies to separate
> module? Does it break anything?
>
That would be a variant on the asm inline idea, but yes, I think that would work
too
Neil
> --
> Sincerely,
>
> Yerden Zhumabekov
> State Technical Service
> Astana, KZ
>
>
[dpdk-dev] versioning and maintenance
On Wed, Nov 19, 2014 at 11:35:08AM +, Bruce Richardson wrote: > On Wed, Nov 19, 2014 at 12:22:14PM +0100, Thomas Monjalon wrote: > > Following the discussion we had with Neil during the conference call, > > I suggest this plan, starting with the next release (2.0): > > - add version numbers to libraries > > - add version numbers to functions inside .map files > > - create a git tree dedicated to maintenance and API compatibility > > > > It means these version numbers must be incremented when breaking the API. > > Though the old code paths will be maintained and tested separately by > > volunteers. > > A mailing list for maintenance purpose could be created if needed. > > > Hi Thomas, > > I really think that the versionning is best handled inside the main repository > itself. Given that the proposed deprecation policy is over two releases i.e. > an > API is marked deprecated in release X and then removed in X+1, I don't see the > maintaining of old code paths to be particularly onerous. > > /Bruce > I agree with Bruce, even if it is on occasion an added workload, its not the sort of thing that can or should be placed on an alternate developer. Backwards compatibility is the sort of thing that has to be on the mind of the developer when modifying an API, and on the mind of the reviewer when reviewing code. To shunt that responsibility elsewhere invites the opportunity for backwards compatibilty to be a second class citizen who's goal will never be reached, because developers instituting ABI changes will never care about the consequences, and anyone worrying about backwards compatibility will always be playing catch up, possibly allowing ABI breaks to slip through. Neil
[dpdk-dev] [PATCH v4 3/5] hash: add fallback to software CRC32 implementation
> -Original Message-
> From: Neil Horman [mailto:nhorman at tuxdriver.com]
> Sent: Wednesday, November 19, 2014 3:06 PM
> To: Ananyev, Konstantin
> Cc: Richardson, Bruce; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v4 3/5] hash: add fallback to software CRC32
> implementation
>
> On Wed, Nov 19, 2014 at 11:50:40AM +, Ananyev, Konstantin wrote:
> >
> >
> > > -Original Message-
> > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce Richardson
> > > Sent: Wednesday, November 19, 2014 11:38 AM
> > > To: Neil Horman
> > > Cc: dev at dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH v4 3/5] hash: add fallback to software
> > > CRC32 implementation
> > >
> > > On Wed, Nov 19, 2014 at 06:34:08AM -0500, Neil Horman wrote:
> > > > On Wed, Nov 19, 2014 at 10:16:14AM +, Bruce Richardson wrote:
> > > > > On Tue, Nov 18, 2014 at 04:36:24PM -0500, Neil Horman wrote:
> > > > > > On Tue, Nov 18, 2014 at 05:52:27PM +, Bruce Richardson wrote:
> > > > > > > On Tue, Nov 18, 2014 at 12:46:19PM -0500, Neil Horman wrote:
> > > > > > > > On Tue, Nov 18, 2014 at 11:13:17PM +0600, Yerden Zhumabekov
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > 18.11.2014 22:00, Neil Horman ?:
> > > > > > > > > > On Tue, Nov 18, 2014 at 09:06:35PM +0600, Yerden Zhumabekov
> > > > > > > > > > wrote:
> > > > > > > > > >> 18.11.2014 20:41, Neil Horman ?:
> > > > > > > > > >>> On Tue, Nov 18, 2014 at 08:03:40PM +0600, Yerden
> > > > > > > > > >>> Zhumabekov wrote:
> > > > > > > > > /**
> > > > > > > > > * Use single crc32 instruction to perform a hash on a
> > > > > > > > > 4 byte value.
> > > > > > > > > + * Fall back to software crc32 implementation in case
> > > > > > > > > SSE4.2 is
> > > > > > > > > + * not supported
> > > > > > > > > *
> > > > > > > > > * @param data
> > > > > > > > > * Data to perform hash on.
> > > > > > > > > @@ -376,11 +413,18 @@ crc32c_2words(uint64_t data,
> > > > > > > > > uint32_t init_val)
> > > > > > > > > static inline uint32_t
> > > > > > > > > rte_hash_crc_4byte(uint32_t data, uint32_t init_val)
> > > > > > > > > {
> > > > > > > > > -return _mm_crc32_u32(init_val, data);
> > > > > > > > > +#ifdef RTE_MACHINE_CPUFLAG_SSE4_2
> > > > > > > > > +if (likely(crc32_alg == CRC32_SSE42))
> > > > > > > > > +return _mm_crc32_u32(init_val, data);
> > > > > > > > > +#endif
> > > > > > > > > >>> you don't really need these ifdefs here anymore given
> > > > > > > > > >>> that you have a
> > > > > > > > > >>> constructor to do the algorithm selection. In fact you
> > > > > > > > > >>> need to remove them, in
> > > > > > > > > >>> the event you build on a system that doesn't support
> > > > > > > > > >>> SSE42, but run on a system
> > > > > > > > > >>> that does.
> > > > > > > > > >> Originally, I thought so as well. I wrote the code without
> > > > > > > > > >> these ifdefs,
> > > > > > > > > >> but it didn't compile on my machine which doesn't support
> > > > > > > > > >> SSE4.2. Error
> > > > > > > > > >> was triggered by nmmintrin.h which has a check for
> > > > > > > > > >> respective GCC
> > > > > > > > > >> extension. So I think these ifdefs are indeed required.
> > > > > > > > > >>
> > > > > > > > > > You need to edit the makefile so that the compiler gets
> > > > > > > > > > passed the option
> > > > > > > > > > -msse42. That way it will know to emit sse42 instructions.
> > > > > > > > > > It will also allow
> > > > > > > > > > you to remove the ifdef from the include file
> > > > > > > > >
> > > > > > > > > In this case, I guess there are two options:
> > > > > > > > > 1) modify all makefiles which use librte_hash
> > > > > > > > > 2) move all function bodies from rte_hash_crc.h to separate
> > > > > > > > > module,
> > > > > > > > > leaving prototype definitions there only.
> > > > > > > > >
> > > > > > > > > Everybody's up for the second option? :)
> > > > > > > > >
> > > > > > > > Crud, you're right, I didn't think about the header inclusion
> > > > > > > > issue. Is it
> > > > > > > > worth adding the jump to enable the dynamic hash selection?
> > > > > > > > Neil
> > > > > > >
> > > > > > > Maybe for cases where SSE4.2 is not currently available, i.e. for
> > > > > > > generic builds.
> > > > > > > For builds where we have hardware support confirmed at compile
> > > > > > > time, just use
> > > > > > > the function from the header file.
> > > > > > > Does that make sense?
> > > > > > >
> > > > > > I'm not certain of that, as I don't think anything can be
> > > > > > 'confirmed' at compile
> > > > > > time. I.e. just because you have sse42 at compile time doesn't
> > > > > > guarantee you
> > > > > > have it at run time with a DSO. If you have these as macros, you
> > > > > > need to enable
> > > > > > sse42 whereever you include the file so that the intrinsic works
> > > > > > properly.
>
[dpdk-dev] Enhance KNI DPDK-app-side to be Multi-Producer/Consumer
Hi Danny,
On Fri, Nov 14, 2014 at 7:04 PM, Zhou, Danny wrote:
> It will be always good if you can submit the RFC patch in terms of KNI
> optimization.
>
> On the other hand, do you have any perf. data to prove that your patchset
> could improve
> KNI performance which is the concern that most customers care about? We
> introduced
> multiple-threaded KNI kernel support last year, if I remember correctly,
> the key perform
> bottle-neck we found is the skb alloc/free and memcpy between skb and
> mbuf. Would be
> very happy if your patchset can approve I am wrong.
This is not an attempt to improve raw performance. Our modest goal is to
make librte_kni's RX/TX burst APIs multithreaded, without changing
rte_kni.ko. In this RFC patch, we make it possible for multiple cores to
concurrently invoke rte_kni_tx_burst (or rte_kni_rx_burst) for the same KNI
device.
At the moment, multiple cores invoking rte_kni_tx_burst for the same device
cannot function correctly, because the rte_kni_fifo structures (memory
shared between app and kernel driver) are single-producer, single-consumer.
The following patch supplements the rte_kni_fifo structure with an
additional structure that is private to the application, and we borrow
librte_ring's MP/MC enqueue/dequeue logic.
Here is a patch for 1.8. We have only tested a 1.7.1 version. Please have a
look and let us know whether you think something like this would be useful.
--
Thanks,
Robert
*Signed-off-by: Robert Sanford >*
---
lib/librte_kni/rte_kni.c | 21 +-
lib/librte_kni/rte_kni_fifo.h | 131
+
2 files changed, 148 insertions(+), 4 deletions(-)
diff --git a/lib/librte_kni/rte_kni.c b/lib/librte_kni/rte_kni.c
index fdb7509..8009173 100644
--- a/lib/librte_kni/rte_kni.c
+++ b/lib/librte_kni/rte_kni.c
@@ -76,6 +76,11 @@ struct rte_kni {
struct rte_kni_fifo *alloc_q; /**< Allocated mbufs queue */
struct rte_kni_fifo *free_q;/**< To be freed mbufs queue */
+ struct rte_kni_fifo_multi tx_q_mc; /**< Make tx_q multi-consumer */
+ struct rte_kni_fifo_multi alloc_q_mp;/**< Make alloc_q multi-producer */
+ struct rte_kni_fifo_multi rx_q_mp; /**< Make rx_q multi-producer */
+ struct rte_kni_fifo_multi free_q_mc;/**< Make free_q multi-consumer */
+
/* For request & response */
struct rte_kni_fifo *req_q; /**< Request queue */
struct rte_kni_fifo *resp_q;/**< Response queue */
@@ -414,6 +419,11 @@ rte_kni_alloc(struct rte_mempool *pktmbuf_pool,
kni_fifo_init(ctx->free_q, KNI_FIFO_COUNT_MAX);
dev_info.free_phys = mz->phys_addr;
+ kni_fifo_multi_init(&ctx->tx_q_mc, KNI_FIFO_COUNT_MAX);
+ kni_fifo_multi_init(&ctx->alloc_q_mp, KNI_FIFO_COUNT_MAX);
+ kni_fifo_multi_init(&ctx->rx_q_mp, KNI_FIFO_COUNT_MAX);
+ kni_fifo_multi_init(&ctx->free_q_mc, KNI_FIFO_COUNT_MAX);
+
/* Request RING */
mz = slot->m_req_q;
ctx->req_q = mz->addr;
@@ -557,7 +567,8 @@ rte_kni_handle_request(struct rte_kni *kni)
unsigned
rte_kni_tx_burst(struct rte_kni *kni, struct rte_mbuf **mbufs, unsigned
num)
{
- unsigned ret = kni_fifo_put(kni->rx_q, (void **)mbufs, num);
+ unsigned ret = kni_fifo_put_mp(kni->rx_q, &kni->rx_q_mp, (void **)mbufs,
+ num);
/* Get mbufs from free_q and then free them */
kni_free_mbufs(kni);
@@ -568,7 +579,8 @@ 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)
{
- unsigned ret = kni_fifo_get(kni->tx_q, (void **)mbufs, num);
+ unsigned ret = kni_fifo_get_mc(kni->tx_q, &kni->tx_q_mc,
+ (void **)mbufs, num);
/* Allocate mbufs and then put them into alloc_q */
kni_allocate_mbufs(kni);
@@ -582,7 +594,8 @@ kni_free_mbufs(struct rte_kni *kni)
int i, ret;
struct rte_mbuf *pkts[MAX_MBUF_BURST_NUM];
- ret = kni_fifo_get(kni->free_q, (void **)pkts, MAX_MBUF_BURST_NUM);
+ ret = kni_fifo_get_mc(kni->free_q, &kni->free_q_mc, (void **)pkts,
+ MAX_MBUF_BURST_NUM);
if (likely(ret > 0)) {
for (i = 0; i < ret; i++)
rte_pktmbuf_free(pkts[i]);
@@ -629,7 +642,7 @@ kni_allocate_mbufs(struct rte_kni *kni)
if (i <= 0)
return;
- ret = kni_fifo_put(kni->alloc_q, (void **)pkts, i);
+ ret = kni_fifo_put_mp(kni->alloc_q, &kni->alloc_q_mp, (void **)pkts, i);
/* Check if any mbufs not put into alloc_q, and then free them */
if (ret >= 0 && ret < i && ret < MAX_MBUF_BURST_NUM) {
diff --git a/lib/librte_kni/rte_kni_fifo.h b/lib/librte_kni/rte_kni_fifo.h
index 8cb8587..7dccba2 100644
--- a/lib/librte_kni/rte_kni_fifo.h
+++ b/lib/librte_kni/rte_kni_fifo.h
@@ -91,3 +91,134 @@ kni_fifo_get(struct rte_kni_fifo *fifo, void **data,
unsigned num)
fifo->read = new_read;
return i;
}
+
+
+/**
+ * Suplemental members to facilitate MP/MC access to KNI FIFOs.
+ */
+struct rte_kni_fifo_multi {
+ volatile uint32_t head;
+ volatile uint32_t tail;
+ uint32_t mask;
+ uint32_t size;
+};
+
+/**
+ * Initialize a kni fifo MP/MC struct.
+ */
+static void
+kni_fifo_multi_init(struct rte_kn
