[dpdk-dev] dev Digest, Vol 83, Issue 176
??
1
2??
wenhb at techsure.com.cn
From: dev-request
Date: 2016-03-13 23:17
To: dev
Subject: dev Digest, Vol 83, Issue 176
Send dev mailing list submissions to
dev at dpdk.org
To subscribe or unsubscribe via the World Wide Web, visit
http://dpdk.org/ml/listinfo/dev
or, via email, send a message with subject or body 'help' to
dev-request at dpdk.org
You can reach the person managing the list at
dev-owner at dpdk.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of dev digest..."
Today's Topics:
1. Re: [PATCH v8 1/4] lib/ether: optimize struct
rte_eth_tunnel_filter_conf (Thomas Monjalon)
2. Re: [PATCH v8 0/4] This patch set adds tunnel filter support
for IP in GRE on i40e. (Thomas Monjalon)
3. dpdk hash lookup function crashed (segment fault) (??)
4. Re: [PATCH v4 0/4] Add PCAP support to source and sink port
(Thomas Monjalon)
5. Re: [PATCH v3] ip_pipeline: add load balancing function to
pass-through pipeline (Thomas Monjalon)
6. Re: [PATCH] app/test-pmd: add support for zero rx and tx
queues (Thomas Monjalon)
--
Message: 1
Date: Sun, 13 Mar 2016 13:01:05 +0100
From: Thomas Monjalon
To: Jingjing Wu , xutao.sun at intel.com
Cc: dev at dpdk.org, helin.zhang at intel.com, Jijiang Liu
Subject: Re: [dpdk-dev] [PATCH v8 1/4] lib/ether: optimize struct
rte_eth_tunnel_filter_conf
Message-ID: <3488408.ByHyY3dxP7 at xps13>
Content-Type: text/plain; charset="us-ascii"
2016-03-10 11:05, Jingjing Wu:
> From: Xutao Sun
>
> Change the fields of outer_mac and inner_mac in struct
> rte_eth_tunnel_filter_conf from pointer to struct in order to
> keep the code's readability.
It breaks compilation of examples/tep_termination.
> --- a/app/test-pmd/cmdline.c
> +++ b/app/test-pmd/cmdline.c
> @@ -6628,8 +6628,10 @@ cmd_tunnel_filter_parsed(void *parsed_result,
> struct rte_eth_tunnel_filter_conf tunnel_filter_conf;
> int ret = 0;
>
> - tunnel_filter_conf.outer_mac = &res->outer_mac;
> - tunnel_filter_conf.inner_mac = &res->inner_mac;
> + rte_memcpy(&tunnel_filter_conf.outer_mac, &res->outer_mac,
> + ETHER_ADDR_LEN);
> + rte_memcpy(&tunnel_filter_conf.inner_mac, &res->inner_mac,
> + ETHER_ADDR_LEN);
Please use ether_addr_copy().
> --- a/drivers/net/i40e/i40e_ethdev.c
> +++ b/drivers/net/i40e/i40e_ethdev.c
> @@ -5839,10 +5839,10 @@ i40e_dev_tunnel_filter_set(struct i40e_pf *pf,
> }
> pfilter = cld_filter;
>
> - (void)rte_memcpy(&pfilter->outer_mac, tunnel_filter->outer_mac,
> - sizeof(struct ether_addr));
> - (void)rte_memcpy(&pfilter->inner_mac, tunnel_filter->inner_mac,
> - sizeof(struct ether_addr));
> + (void)rte_memcpy(&pfilter->outer_mac, &tunnel_filter->outer_mac,
> + ETHER_ADDR_LEN);
> + (void)rte_memcpy(&pfilter->inner_mac, &tunnel_filter->inner_mac,
> + ETHER_ADDR_LEN);
As already commented in January, please stop this useless return cast.
There is a dedicated function to copy MAC addresses:
ether_addr_copy()
--
Message: 2
Date: Sun, 13 Mar 2016 15:18:37 +0100
From: Thomas Monjalon
To: Jingjing Wu , xutao.sun at intel.com
Cc: dev at dpdk.org, helin.zhang at intel.com
Subject: Re: [dpdk-dev] [PATCH v8 0/4] This patch set adds tunnel
filter support for IP in GRE on i40e.
Message-ID: <2132081.GGHc1VANAT at xps13>
Content-Type: text/plain; charset="us-ascii"
2016-03-10 11:05, Jingjing Wu:
> Xutao Sun (4):
> lib/ether: optimize the'rte_eth_tunnel_filter_conf' structure
> lib/ether: add IP in GRE type
> driver/i40e: implement tunnel filter for IP in GRE
> app/test-pmd: test tunnel filter for IP in GRE
I've done the changes for ether_addr_copy and fixed tep_termination.
Applied, thanks
--
Message: 3
Date: Sun, 13 Mar 2016 22:38:14 +0800 (CST)
From: ??
To: dev at dpdk.org
Subject: [dpdk-dev] dpdk hash lookup function crashed (segment fault)
Message-ID: <44245b2a.50bb.1537069ca54.Coremail.zhangwqh at 126.com>
Content-Type: text/plain; charset=GBK
Hi all,
When I use the dpdk lookup function, I met the segment fault problem. Can
anybody help to look at why this happens. I will put the aim what I want to do
and the related piece of code, and my debug message,
This problem is that in dpdk multi process - client and server example,
dpdk-2.2.0/examples/multi_process/client_server_mp
My aim is that server create a hash table, then share it to client. Client will
write the hash table, server will read the hash table. I am using dpdk hash
table. What I did is that server create a hash table (table and array
entries), return the table address. I use memzone pass the table address to
client. In client, the second lookup gets segment fault. The system gets
crashed. I will put some related code here.
create hash table function:
struct onvm_ft*
onvm_ft_create(int cnt, int entry_size) {
struct rte_hash* hash;
struct onv
[dpdk-dev] [PATCH 0/3] sched: patches for 2.2
2016-03-13 22:47, Dumitrescu, Cristian: > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > 2016-03-08 07:49, Dumitrescu, Cristian: > > > Regarding Stephen's patches, I think there is a pending issue regarding > > > the > > legal side of the Copyright, which is attributed to Intel, although > > Stephen's > > code is relicensed with BSD license by permission from the original code > > author (which also submitted the code to Linux kernel under GPL). This was > > already flagged. This is a legal issue and I do not feel comfortable with > > ack-ing > > this patch until the legal resolution on this is crystal clear. > > > > > > I also think the new files called rte_reciprocal.[hc] implement an > > > algorithm > > that is very generic and totally independent of the QoS code, therefore it > > should be placed into a different folder that is globally visible to other > > libraries (librte_eal/common ?) just in case other usages for this algorithm > > are identified in the future. I suggest we break the patch into two separate > > patches submitted independently: one introducing the rte_reciprocal.[hc] > > algorithm to librte_eal/common and the second containing just the > > librte_sched changes, which are small. I am thinking ahead here: once we > > have the 2x64-bit multiplication solution in place, we should not have > > rte_reciprocal.[hc] hanging in librte_sched folder without being used here, > > while it might be used by other parts of DPDK. > > > > Let's keep the improvement as-is to test it in the first release candidate. > > We can move the code and/or fix the file header later. > > > > Series applied, thanks. > > Hi Thomas, > > I am OK with this, as long as Stephen commits to fix the copyright in the > header file There is no copyright issue. Just an Intel mention in the disclaimer. > and move the rte_reciprocal.[hc] into a common area like > librte_eal/common in time for the next release candidate. If it is moved as a public API, it must be better documented. If it stay here, it must be removed from SYMLINK-y-include.
[dpdk-dev] [PATCH v2] vhost: Fix default value of kickfd and callfd
On 2016/03/11 16:19, Yuanhan Liu wrote: > On Thu, Mar 10, 2016 at 04:06:05PM +0900, Tetsuya Mukawa wrote: >> Currently, default values of kickfd and callfd are -1. >> If the values are -1, current code guesses kickfd and callfd haven't >> been initialized yet. And vhost library will guess the virtqueue isn't >> ready for processing. >> But callfd and kickfd will be set as -1 when "--enable-kvm" >> isn't specified in QEMU command line. It means we cannot treat -1 as >> uninitialized state. The patch changes default values to -2. And the >> patch defines -2 as VIRTIO_UNINITIALIZED_EVENTFD. > This looks more like a workaround to me. Hi Yuanhan, Sorry for late reply. I have checked QEMU documentation, and found below. -- * VHOST_USER_SET_VRING_CALL Id: 14 Equivalent ioctl: VHOST_SET_VRING_CALL Master payload: u64 Set the event file descriptor to signal when buffers are used. It is passed in the ancillary data. Bits (0-7) of the payload contain the vring index. Bit 8 is the invalid FD flag. -- VHOST_USER_SET_VRING_KICK has almost same description. I will check this invalid flag, and if it works for our case, then will use it. How about it? > Besides, this patch would make > following fail: > > eventfd_write(vq->callfd, (eventfd_t)1); It's my fault. I thought above case should be blocked by virtio spec itself. So just leave it. But eventfd is came from vhost spec, so VRING_AVAIL_F_NO_INTERRUPT might be set even when kickfd and callfd are -1. Thanks for checking it. Tetsuya > --yliu
[dpdk-dev] [PATCH v2] vhost: Fix default value of kickfd and callfd
On Mon, Mar 14, 2016 at 10:54:14AM +0900, Tetsuya Mukawa wrote: > On 2016/03/11 16:19, Yuanhan Liu wrote: > > On Thu, Mar 10, 2016 at 04:06:05PM +0900, Tetsuya Mukawa wrote: > >> Currently, default values of kickfd and callfd are -1. > >> If the values are -1, current code guesses kickfd and callfd haven't > >> been initialized yet. And vhost library will guess the virtqueue isn't > >> ready for processing. > >> But callfd and kickfd will be set as -1 when "--enable-kvm" > >> isn't specified in QEMU command line. It means we cannot treat -1 as > >> uninitialized state. The patch changes default values to -2. And the > >> patch defines -2 as VIRTIO_UNINITIALIZED_EVENTFD. > > This looks more like a workaround to me. > > > Hi Yuanhan, > > Sorry for late reply. > I have checked QEMU documentation, and found below. > > -- > * VHOST_USER_SET_VRING_CALL > > Id: 14 > Equivalent ioctl: VHOST_SET_VRING_CALL > Master payload: u64 > > Set the event file descriptor to signal when buffers are used. It > is passed in the ancillary data. > Bits (0-7) of the payload contain the vring index. Bit 8 is the > invalid FD flag. > -- > > VHOST_USER_SET_VRING_KICK has almost same description. > I will check this invalid flag, and if it works for our case, then will > use it. > How about it? Yeah, that indeed sounds much better. --yliu > > > Besides, this patch would make > > following fail: > > > > eventfd_write(vq->callfd, (eventfd_t)1); > > It's my fault. > I thought above case should be blocked by virtio spec itself. So just > leave it. > But eventfd is came from vhost spec, so VRING_AVAIL_F_NO_INTERRUPT might > be set even when kickfd and callfd are -1. > Thanks for checking it. > > Tetsuya > > > --yliu
[dpdk-dev] [PATCH] hash: fix memcmp function pointer in multi-process environment
I met a problem which I used the DPDK hash table for multi processes. One
started as primary process and the other as secondary process.
I based on the client and server multiprocess example. My aim is that server
creates a hash table, then share it to the client. The client will read and
write the hash table, and the server will read the hash table. I use rte_calloc
allocate the space for hash table, use memzone tells the client the hash table
address.
But once I add an entry into the hash table, calling "lookup" function will
have the segment fault. But for the lookup function, I have exactly the same
parameters for lookup when the first time calls the lookup.
If I create the hash table inside the client, everything works correctly.
I put pieces of codes for server and client codes related to the hash table. I
have spent almost 3 days on this bug. But there is no any clue which can help
to solve this bug. If any of you can give some suggestions, I will be
appreciated. I post the question into the mail list, but have not yet got any
reply.
This problem is that in dpdk multi process - client and server example,
dpdk-2.2.0/examples/multi_process/client_server_mp
My aim is that server create a hash table, then share it to client. Client will
write the hash table, server will read the hash table. I am using dpdk hash
table. What I did is that server create a hash table (table and array
entries), return the table address. I use memzone pass the table address to
client. In client, the second lookup gets segment fault. The system gets
crashed. I will put some related code here.
create hash table function:
struct onvm_ft*
onvm_ft_create(int cnt, int entry_size) {
struct rte_hash* hash;
struct onvm_ft* ft;
struct rte_hash_parameters ipv4_hash_params = {
.name = NULL,
.entries = cnt,
.key_len = sizeof(struct onvm_ft_ipv4_5tuple),
.hash_func = NULL,
.hash_func_init_val = 0,
};
char s[64];
/* create ipv4 hash table. use core number and cycle counter to get a
unique name. */
ipv4_hash_params.name = s;
ipv4_hash_params.socket_id = rte_socket_id();
snprintf(s, sizeof(s), "onvm_ft_%d-%"PRIu64, rte_lcore_id(),
rte_get_tsc_cycles());
hash = rte_hash_create(&ipv4_hash_params);
if (hash == NULL) {
return NULL;
}
ft = (struct onvm_ft*)rte_calloc("table", 1, sizeof(struct onvm_ft), 0);
if (ft == NULL) {
rte_hash_free(hash);
return NULL;
}
ft->hash = hash;
ft->cnt = cnt;
ft->entry_size = entry_size;
/* Create data array for storing values */
ft->data = rte_calloc("entry", cnt, entry_size, 0);
if (ft->data == NULL) {
rte_hash_free(hash);
rte_free(ft);
return NULL;
}
return ft;
}
related structure:
struct onvm_ft {
struct rte_hash* hash;
char* data;
int cnt;
int entry_size;
};
in server side, I will call the create function, use memzone share it to
client. The following is what I do:
related variables:
struct onvm_ft *sdn_ft;
struct onvm_ft **sdn_ft_p;
const struct rte_memzone *mz_ftp;
sdn_ft = onvm_ft_create(1024, sizeof(struct onvm_flow_entry));
if(sdn_ft == NULL) {
rte_exit(EXIT_FAILURE, "Unable to create flow table\n");
}
mz_ftp = rte_memzone_reserve(MZ_FTP_INFO, sizeof(struct onvm_ft *),
rte_socket_id(), NO_FLAGS);
if (mz_ftp == NULL) {
rte_exit(EXIT_FAILURE, "Canot reserve memory zone for flow
table pointer\n");
}
memset(mz_ftp->addr, 0, sizeof(struct onvm_ft *));
sdn_ft_p = mz_ftp->addr;
*sdn_ft_p = sdn_ft;
In client side:
struct onvm_ft *sdn_ft;
static void
map_flow_table(void) {
const struct rte_memzone *mz_ftp;
struct onvm_ft **ftp;
mz_ftp = rte_memzone_lookup(MZ_FTP_INFO);
if (mz_ftp == NULL)
rte_exit(EXIT_FAILURE, "Cannot get flow table pointer\n");
ftp = mz_ftp->addr;
sdn_ft = *ftp;
}
The following is my debug message: I set a breakpoint in lookup table line. To
narrow down the problem, I just send one flow. So the second time and the first
time, the packets are the same.
For the first time, it works. I print out the parameters: inside the
onvm_ft_lookup function, if there is a related entry, it will return the
address by flow_entry.
Breakpoint 1, datapath_handle_read (dp=0x78c0) at
/home/zhangwei1984/openNetVM-master/openNetVM/examples/flow_table/sdn.c:191
191 ret = onvm_ft_lookup(sdn_ft, fk,
(char**)&flow_entry);
(gdb) print *sdn_ft
$1 = {hash = 0x7fff32cce740, data = 0x7ff
[dpdk-dev] [PATCH v3] ixgbe: fix ixgbevf RX/TX function assignment
For the secondary process of DPDK to initialize ixgbevf, it will always
use the simple RX function or LRO RX function, and this behavior is not
the same RX/TX function selection logic as it is for the primary process,
so use the ixgbe_set_tx_function and ixgbe_set_rx_function to select the
RX/TX function when secondary process call the init function for eth dev.
Fixes: 46bc9d75 (ixgbe: fix multi-process support)
Signed-off-by: Zhe Tao
---
V2:added fixes line
V3:changed fixes line
drivers/net/ixgbe/ixgbe_ethdev.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 3e6fe86..0f9d048 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -1278,8 +1278,21 @@ eth_ixgbevf_dev_init(struct rte_eth_dev *eth_dev)
* has already done this work. Only check we don't need a different
* RX function */
if (rte_eal_process_type() != RTE_PROC_PRIMARY){
- if (eth_dev->data->scattered_rx)
- eth_dev->rx_pkt_burst =
ixgbe_recv_pkts_lro_single_alloc;
+ struct ixgbe_tx_queue *txq;
+ /* TX queue function in primary, set by last queue initialized
+* Tx queue may not initialized by primary process
+*/
+ if (eth_dev->data->tx_queues) {
+ txq =
eth_dev->data->tx_queues[eth_dev->data->nb_tx_queues-1];
+ ixgbe_set_tx_function(eth_dev, txq);
+ } else {
+ /* Use default TX function if we get here */
+ PMD_INIT_LOG(NOTICE, "No TX queues configured yet. "
+"Using default TX function.");
+ }
+
+ ixgbe_set_rx_function(eth_dev);
+
return 0;
}
--
2.1.4
[dpdk-dev] [PATCH] hash: fix memcmp function pointer in multi-process environment
BTW, the following is my backtrace when the system crashes.
Program received signal SIGSEGV, Segmentation fault.
0x004883ab in rte_hash_reset (h=0x0)
at
/home/zhangwei1984/timopenNetVM/dpdk-2.2.0/lib/librte_hash/rte_cuckoo_hash.c:444
444while (rte_ring_dequeue(h->free_slots, &ptr) == 0)
(gdb) bt
#0 0x004883ab in rte_hash_reset (h=0x0)
at
/home/zhangwei1984/timopenNetVM/dpdk-2.2.0/lib/librte_hash/rte_cuckoo_hash.c:444
#1 0x0048fdfb in rte_hash_lookup_with_hash (h=0x7fff32cce740,
key=0x7fffe220, sig=403183624)
at
/home/zhangwei1984/timopenNetVM/dpdk-2.2.0/lib/librte_hash/rte_cuckoo_hash.c:771
#2 0x0042b551 in onvm_ft_lookup_with_hash (table=0x7fff32cbe4c0,
pkt=0x7fff390ea9c0,
data=0x7fffe298) at
/home/zhangwei1984/openNetVM-master/openNetVM/onvm/shared/onvm_flow_table.c:104
#3 0x0042b8c3 in onvm_flow_dir_get_with_hash (table=0x7fff32cbe4c0,
pkt=0x7fff390ea9c0,
flow_entry=0x7fffe298)
at
/home/zhangwei1984/openNetVM-master/openNetVM/onvm/shared/onvm_flow_dir.c:14
#4 0x004251d7 in packet_handler (pkt=0x7fff390ea9c0,
meta=0x7fff390eaa00)
at
/home/zhangwei1984/openNetVM-master/openNetVM/examples/flow_table/flow_table.c:212
#5 0x00429502 in onvm_nf_run ()
#6 0x004253f1 in main (argc=1, argv=0x7fffe648)
at
/home/zhangwei1984/openNetVM-master/openNetVM/examples/flow_table/flow_table.c:272
(gdb)
I met a problem which I used the DPDK hash table for multi processes. One
started as primary process and the other as secondary process.
I based on the client and server multiprocess example. My aim is that server
creates a hash table, then share it to the client. The client will read and
write the hash table, and the server will read the hash table. I use rte_calloc
allocate the space for hash table, use memzone tells the client the hash table
address.
But once I add an entry into the hash table, calling "lookup" function will
have the segment fault. But for the lookup function, I have exactly the same
parameters for lookup when the first time calls the lookup.
If I create the hash table inside the client, everything works correctly.
I put pieces of codes for server and client codes related to the hash table. I
have spent almost 3 days on this bug. But there is no any clue which can help
to solve this bug. If any of you can give some suggestions, I will be
appreciated. I post the question into the mail list, but have not yet got any
reply.
This problem is that in dpdk multi process - client and server example,
dpdk-2.2.0/examples/multi_process/client_server_mp
My aim is that server create a hash table, then share it to client. Client will
write the hash table, server will read the hash table. I am using dpdk hash
table. What I did is that server create a hash table (table and array
entries), return the table address. I use memzone pass the table address to
client. In client, the second lookup gets segment fault. The system gets
crashed. I will put some related code here.
create hash table function:
struct onvm_ft*
onvm_ft_create(int cnt, int entry_size) {
struct rte_hash* hash;
struct onvm_ft* ft;
struct rte_hash_parameters ipv4_hash_params = {
.name = NULL,
.entries = cnt,
.key_len = sizeof(struct onvm_ft_ipv4_5tuple),
.hash_func = NULL,
.hash_func_init_val = 0,
};
char s[64];
/* create ipv4 hash table. use core number and cycle counter to get a
unique name. */
ipv4_hash_params.name = s;
ipv4_hash_params.socket_id = rte_socket_id();
snprintf(s, sizeof(s), "onvm_ft_%d-%"PRIu64, rte_lcore_id(),
rte_get_tsc_cycles());
hash = rte_hash_create(&ipv4_hash_params);
if (hash == NULL) {
return NULL;
}
ft = (struct onvm_ft*)rte_calloc("table", 1, sizeof(struct onvm_ft), 0);
if (ft == NULL) {
rte_hash_free(hash);
return NULL;
}
ft->hash = hash;
ft->cnt = cnt;
ft->entry_size = entry_size;
/* Create data array for storing values */
ft->data = rte_calloc("entry", cnt, entry_size, 0);
if (ft->data == NULL) {
rte_hash_free(hash);
rte_free(ft);
return NULL;
}
return ft;
}
related structure:
struct onvm_ft {
struct rte_hash* hash;
char* data;
int cnt;
int entry_size;
};
in server side, I will call the create function, use memzone share it to
client. The following is what I do:
related variables:
struct onvm_ft *sdn_ft;
struct onvm_ft **sdn_ft_p;
const struct rte_memzone *mz_ftp;
sdn_ft = onvm_ft_create(1024, sizeof(struct onvm_flow_entry));
if(sdn_ft == NULL) {
rte_exit(EXIT_FAILURE, "Unable to
[dpdk-dev] [PATCH v3 3/8] vhost: refactor virtio_dev_merge_rx
On Fri, Mar 11, 2016 at 05:18:54PM +0100, Thomas Monjalon wrote: > This patch does not compile: > lib/librte_vhost/vhost_rxtx.c:386:5: error: ?dev? undeclared Oops, I acutally did the basic compile test on every commit and every time I did a rebase. I had a quick look, it turned out that it's a build bug when RTE_LIBRTE_VHOST_DEBUG is enabled. It is disabled by default, and that's why I didn't catch it. Thanks for the report, I will fix it soon. --yliu
[dpdk-dev] [PATCH] ethdev: don't count missed packets in erroneous packets counter
Ping.
CCing to maintainers of affected drivers.
> 10 ? 2016 ?., ? 16:03, Igor Ryzhov ???(?):
>
> Comment for "ierrors" counter says that it counts erroneous received packets.
> But for some reason "imissed" counter is added to "ierrors" counter in most
> drivers. It is a mistake, because missed packets are obviously not received.
> This patch fixes it.
>
> Signed-off-by: Igor Ryzhov
> ---
> app/test-pmd/testpmd.c | 4 ++--
> drivers/net/cxgbe/cxgbe_ethdev.c | 2 +-
> drivers/net/e1000/em_ethdev.c| 1 -
> drivers/net/e1000/igb_ethdev.c | 1 -
> drivers/net/i40e/i40e_ethdev.c | 3 +--
> drivers/net/ixgbe/ixgbe_ethdev.c | 1 -
> 6 files changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
> index 269ef81..d3d733b 100644
> --- a/app/test-pmd/testpmd.c
> +++ b/app/test-pmd/testpmd.c
> @@ -753,7 +753,7 @@ fwd_port_stats_display(portid_t port_id, struct
> rte_eth_stats *stats)
> if (cur_fwd_eng == &csum_fwd_engine)
> printf(" Bad-ipcsum: %-14"PRIu64" Bad-l4csum:
> %-14"PRIu64" \n",
> port->rx_bad_ip_csum, port->rx_bad_l4_csum);
> - if (((stats->ierrors - stats->imissed) + stats->rx_nombuf) > 0)
> {
> + if ((stats->ierrors + stats->rx_nombuf) > 0) {
> printf(" RX-error: %-"PRIu64"\n", stats->ierrors);
> printf(" RX-nombufs: %-14"PRIu64"\n",
> stats->rx_nombuf);
> }
> @@ -772,7 +772,7 @@ fwd_port_stats_display(portid_t port_id, struct
> rte_eth_stats *stats)
> if (cur_fwd_eng == &csum_fwd_engine)
> printf(" Bad-ipcsum:%14"PRIu64"
> Bad-l4csum:%14"PRIu64"\n",
> port->rx_bad_ip_csum, port->rx_bad_l4_csum);
> - if (((stats->ierrors - stats->imissed) + stats->rx_nombuf) > 0)
> {
> + if ((stats->ierrors + stats->rx_nombuf) > 0) {
> printf(" RX-error:%"PRIu64"\n", stats->ierrors);
> printf(" RX-nombufs: %14"PRIu64"\n",
> stats->rx_nombuf);
> diff --git a/drivers/net/cxgbe/cxgbe_ethdev.c
> b/drivers/net/cxgbe/cxgbe_ethdev.c
> index 97ef152..0070e2a 100644
> --- a/drivers/net/cxgbe/cxgbe_ethdev.c
> +++ b/drivers/net/cxgbe/cxgbe_ethdev.c
> @@ -662,7 +662,7 @@ static void cxgbe_dev_stats_get(struct rte_eth_dev
> *eth_dev,
> ps.rx_trunc2 + ps.rx_trunc3;
> eth_stats->ierrors = ps.rx_symbol_err + ps.rx_fcs_err +
> ps.rx_jabber + ps.rx_too_long + ps.rx_runt +
> - ps.rx_len_err + eth_stats->imissed;
> + ps.rx_len_err;
>
> /* TX Stats */
> eth_stats->opackets = ps.tx_frames;
> diff --git a/drivers/net/e1000/em_ethdev.c b/drivers/net/e1000/em_ethdev.c
> index 4a843fe..27ace6d 100644
> --- a/drivers/net/e1000/em_ethdev.c
> +++ b/drivers/net/e1000/em_ethdev.c
> @@ -914,7 +914,6 @@ eth_em_stats_get(struct rte_eth_dev *dev, struct
> rte_eth_stats *rte_stats)
> rte_stats->imissed = stats->mpc;
> rte_stats->ierrors = stats->crcerrs +
>stats->rlec + stats->ruc + stats->roc +
> - rte_stats->imissed +
>stats->rxerrc + stats->algnerrc + stats->cexterr;
>
> /* Tx Errors */
> diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
> index 4ed5e95..6e93214 100644
> --- a/drivers/net/e1000/igb_ethdev.c
> +++ b/drivers/net/e1000/igb_ethdev.c
> @@ -1640,7 +1640,6 @@ eth_igb_stats_get(struct rte_eth_dev *dev, struct
> rte_eth_stats *rte_stats)
> rte_stats->imissed = stats->mpc;
> rte_stats->ierrors = stats->crcerrs +
>stats->rlec + stats->ruc + stats->roc +
> - rte_stats->imissed +
>stats->rxerrc + stats->algnerrc + stats->cexterr;
>
> /* Tx Errors */
> diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
> index 7e68c61..7d68d4d 100644
> --- a/drivers/net/i40e/i40e_ethdev.c
> +++ b/drivers/net/i40e/i40e_ethdev.c
> @@ -2062,8 +2062,7 @@ i40e_dev_stats_get(struct rte_eth_dev *dev, struct
> rte_eth_stats *stats)
> pf->main_vsi->eth_stats.rx_discards;
> stats->ierrors = ns->crc_errors +
> ns->rx_length_errors + ns->rx_undersize +
> - ns->rx_oversize + ns->rx_fragments + ns->rx_jabber +
> - stats->imissed;
> + ns->rx_oversize + ns->rx_fragments + ns->rx_jabber;
>
> PMD_DRV_LOG(DEBUG, "* PF stats start
> ***");
> PMD_DRV_LOG(DEBUG, "rx_bytes:%"PRIu64"", ns->eth.rx_bytes);
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> b/drivers/net/ixgbe/ixgbe_ethdev.c
> index 3e6fe86..ba84544 100644
> --- a/drivers/
[dpdk-dev] [PATCH v4 3/8] vhost: refactor virtio_dev_merge_rx
Current virtio_dev_merge_rx() implementation just looks like the
old rte_vhost_dequeue_burst(), full of twisted logic, that you
can see same code block in quite many different places.
However, the logic of virtio_dev_merge_rx() is quite similar to
virtio_dev_rx(). The big difference is that the mergeable one
could allocate more than one available entries to hold the data.
Fetching all available entries to vec_buf at once makes the
difference a bit bigger then.
The refactored code looks like below:
while (mbuf_has_not_drained_totally || mbuf_has_next) {
if (this_desc_has_no_room) {
this_desc = fetch_next_from_vec_buf();
if (it is the last of a desc chain)
update_used_ring();
}
if (this_mbuf_has_drained_totally)
mbuf = fetch_next_mbuf();
COPY(this_desc, this_mbuf);
}
This patch reduces quite many lines of code, therefore, make it much
more readable.
Signed-off-by: Yuanhan Liu
---
v4: fix build error when DEBUG is enabled
---
lib/librte_vhost/vhost_rxtx.c | 406 +-
1 file changed, 168 insertions(+), 238 deletions(-)
diff --git a/lib/librte_vhost/vhost_rxtx.c b/lib/librte_vhost/vhost_rxtx.c
index 0df0612..3ebecee 100644
--- a/lib/librte_vhost/vhost_rxtx.c
+++ b/lib/librte_vhost/vhost_rxtx.c
@@ -324,251 +324,201 @@ virtio_dev_rx(struct virtio_net *dev, uint16_t queue_id,
return count;
}
-static inline uint32_t __attribute__((always_inline))
-copy_from_mbuf_to_vring(struct virtio_net *dev, uint32_t queue_id,
- uint16_t res_base_idx, uint16_t res_end_idx,
- struct rte_mbuf *pkt)
+static inline int
+fill_vec_buf(struct vhost_virtqueue *vq, uint32_t avail_idx,
+uint32_t *allocated, uint32_t *vec_idx)
{
- uint32_t vec_idx = 0;
- uint32_t entry_success = 0;
- struct vhost_virtqueue *vq;
- /* The virtio_hdr is initialised to 0. */
- struct virtio_net_hdr_mrg_rxbuf virtio_hdr = {
- {0, 0, 0, 0, 0, 0}, 0};
- uint16_t cur_idx = res_base_idx;
- uint64_t vb_addr = 0;
- uint64_t vb_hdr_addr = 0;
- uint32_t seg_offset = 0;
- uint32_t vb_offset = 0;
- uint32_t seg_avail;
- uint32_t vb_avail;
- uint32_t cpy_len, entry_len;
- uint16_t idx;
-
- if (pkt == NULL)
- return 0;
+ uint16_t idx = vq->avail->ring[avail_idx & (vq->size - 1)];
+ uint32_t vec_id = *vec_idx;
+ uint32_t len= *allocated;
- LOG_DEBUG(VHOST_DATA, "(%"PRIu64") Current Index %d| "
- "End Index %d\n",
- dev->device_fh, cur_idx, res_end_idx);
+ while (1) {
+ if (vec_id >= BUF_VECTOR_MAX)
+ return -1;
- /*
-* Convert from gpa to vva
-* (guest physical addr -> vhost virtual addr)
-*/
- vq = dev->virtqueue[queue_id];
+ len += vq->desc[idx].len;
+ vq->buf_vec[vec_id].buf_addr = vq->desc[idx].addr;
+ vq->buf_vec[vec_id].buf_len = vq->desc[idx].len;
+ vq->buf_vec[vec_id].desc_idx = idx;
+ vec_id++;
- vb_addr = gpa_to_vva(dev, vq->buf_vec[vec_idx].buf_addr);
- vb_hdr_addr = vb_addr;
+ if ((vq->desc[idx].flags & VRING_DESC_F_NEXT) == 0)
+ break;
- /* Prefetch buffer address. */
- rte_prefetch0((void *)(uintptr_t)vb_addr);
+ idx = vq->desc[idx].next;
+ }
- virtio_hdr.num_buffers = res_end_idx - res_base_idx;
+ *allocated = len;
+ *vec_idx = vec_id;
- LOG_DEBUG(VHOST_DATA, "(%"PRIu64") RX: Num merge buffers %d\n",
- dev->device_fh, virtio_hdr.num_buffers);
+ return 0;
+}
- virtio_enqueue_offload(pkt, &virtio_hdr.hdr);
+/*
+ * As many data cores may want to access available buffers concurrently,
+ * they need to be reserved.
+ *
+ * Returns -1 on fail, 0 on success
+ */
+static inline int
+reserve_avail_buf_mergeable(struct vhost_virtqueue *vq, uint32_t size,
+ uint16_t *start, uint16_t *end)
+{
+ uint16_t res_start_idx;
+ uint16_t res_cur_idx;
+ uint16_t avail_idx;
+ uint32_t allocated;
+ uint32_t vec_idx;
+ uint16_t tries;
- rte_memcpy((void *)(uintptr_t)vb_hdr_addr,
- (const void *)&virtio_hdr, vq->vhost_hlen);
- vhost_log_write(dev, vq->buf_vec[vec_idx].buf_addr, vq->vhost_hlen);
+again:
+ res_start_idx = vq->last_used_idx_res;
+ res_cur_idx = res_start_idx;
- PRINT_PACKET(dev, (uintptr_t)vb_hdr_addr, vq->vhost_hlen, 1);
+ allocated = 0;
+ vec_idx = 0;
+ tries = 0;
+ while (1) {
+ avail_idx = *((volatile uint16_t *)&vq->avail->idx);
+ if (unlikely(res_cur_i
[dpdk-dev] mailing list configuration
On Sat, Mar 12, 2016 at 10:37:46AM -0800, Thomas Monjalon wrote: > Hi all, > > Please find an information notice about mailman running this mailing list. > > You can change your settings at this URL: > http://dpdk.org/ml/options/dev/ > > There is an option "nodupes": > " > Avoid duplicate copies of messages? > When you are listed explicitly in the To: or Cc: headers of a list message, > you can opt to not receive another copy from the mailing list. > " > It is enabled most of the time (default). > > It may be helpful to disable "nodupes", i.e. receive copies, to filter > whole threads from the mailing list (List-Id) in a folder while keeping > a copy of the messages addressed to you in your inbox. > It is a way to avoid missing important messages. > > For those who want to keep "nodupes" enabled, i.e. receive only one copy, > mailman will not send them the messages where they are explicit recipients. > So they will receive only the message directly from the sender' SMTP > (untouched by mailman). > But it is not the full story. The other members of the mailing list will > receive the message from mailman with a modified CC header. > Indeed, members having enabled "nodupes" are dropped from CC list. > > Some members were complaining about this weird bug-haviour. > That's why this patch has been applied to keep CC list untouched: > > --- mailman-2.1.15/Handlers/AvoidDuplicates.py > +++ mailman-2.1.15/Handlers/AvoidDuplicates.py ... > > Thanks to Olivier for helping. Thank you both! It is a weird bug to me. --yliu > If anyone is volunteer to work with mailman community, a configuration option > could be introduced.
[dpdk-dev] [PATCH v2] vhost: Fix default value of kickfd and callfd
On 2016/03/14 11:08, Yuanhan Liu wrote:
> On Mon, Mar 14, 2016 at 10:54:14AM +0900, Tetsuya Mukawa wrote:
>> On 2016/03/11 16:19, Yuanhan Liu wrote:
>>> On Thu, Mar 10, 2016 at 04:06:05PM +0900, Tetsuya Mukawa wrote:
Currently, default values of kickfd and callfd are -1.
If the values are -1, current code guesses kickfd and callfd haven't
been initialized yet. And vhost library will guess the virtqueue isn't
ready for processing.
But callfd and kickfd will be set as -1 when "--enable-kvm"
isn't specified in QEMU command line. It means we cannot treat -1 as
uninitialized state. The patch changes default values to -2. And the
patch defines -2 as VIRTIO_UNINITIALIZED_EVENTFD.
>>> This looks more like a workaround to me.
>>
>> Hi Yuanhan,
>>
>> Sorry for late reply.
>> I have checked QEMU documentation, and found below.
>>
>> --
>> * VHOST_USER_SET_VRING_CALL
>>
>> Id: 14
>> Equivalent ioctl: VHOST_SET_VRING_CALL
>> Master payload: u64
>>
>> Set the event file descriptor to signal when buffers are used. It
>> is passed in the ancillary data.
>> Bits (0-7) of the payload contain the vring index. Bit 8 is the
>> invalid FD flag.
>> --
>>
>> VHOST_USER_SET_VRING_KICK has almost same description.
>> I will check this invalid flag, and if it works for our case, then will
>> use it.
>> How about it?
> Yeah, that indeed sounds much better.
I've checked current dpdk code.
It seems we've already checked invalid flag like below.
if (pmsg->payload.u64 & VHOST_USER_VRING_NOFD_MASK)
file.fd = -1;
else
file.fd = pmsg->fds[0];
So how about adding below macros or enum?
#define VIRTIO_UNINITIALIZED_EVENTFD (-2)
#define VIRTIO_INVALID_EVENTFD (-1)
I am still not sure whether using enum is better or not.
But here is one of example patch.
What do you think?
diff --git a/lib/librte_vhost/rte_virtio_net.h
b/lib/librte_vhost/rte_virtio_net.h
index 7d1fde2..2a7566d 100644
--- a/lib/librte_vhost/rte_virtio_net.h
+++ b/lib/librte_vhost/rte_virtio_net.h
@@ -89,6 +89,8 @@ struct vhost_virtqueue {
uint16_tvhost_hlen; /**< Vhost
header length (varies depending on RX merge buffers. */
volatile uint16_t last_used_idx; /**< Last index
used on the available ring */
volatile uint16_t last_used_idx_res; /**< Used for
multiple devices reserving buffers. */
+#define VIRTIO_UNINITIALIZED_EVENTFD (-2)
+#define VIRTIO_INVALID_EVENTFD (-1)
int callfd; /**< Used to
notify the guest (trigger interrupt). */
int kickfd; /**< Currently
unused as polling mode is enabled. */
int enabled;
diff --git a/lib/librte_vhost/vhost_rxtx.c b/lib/librte_vhost/vhost_rxtx.c
index 9d23eb1..29d002d 100644
--- a/lib/librte_vhost/vhost_rxtx.c
+++ b/lib/librte_vhost/vhost_rxtx.c
@@ -333,7 +333,8 @@ virtio_dev_rx(struct virtio_net *dev, uint16_t queue_id,
rte_mb();
/* Kick the guest if necessary. */
- if (!(vq->avail->flags & VRING_AVAIL_F_NO_INTERRUPT))
+ if (!(vq->avail->flags & VRING_AVAIL_F_NO_INTERRUPT)
+ && (vq->callfd >= 0))
eventfd_write(vq->callfd, (eventfd_t)1);
return count;
}
@@ -654,7 +655,8 @@ merge_rx_exit:
rte_mb();
/* Kick the guest if necessary. */
- if (!(vq->avail->flags & VRING_AVAIL_F_NO_INTERRUPT))
+ if (!(vq->avail->flags & VRING_AVAIL_F_NO_INTERRUPT)
+ && (vq->callfd >= 0))
eventfd_write(vq->callfd, (eventfd_t)1);
}
@@ -1048,7 +1050,8 @@ rte_vhost_dequeue_burst(struct virtio_net *dev,
uint16_t queue_id,
sizeof(vq->used->idx));
/* Kick guest if required. */
- if (!(vq->avail->flags & VRING_AVAIL_F_NO_INTERRUPT))
+ if (!(vq->avail->flags & VRING_AVAIL_F_NO_INTERRUPT)
+ && (vq->callfd >= 0))
eventfd_write(vq->callfd, (eventfd_t)1);
out:
diff --git a/lib/librte_vhost/vhost_user/virtio-net-user.c
b/lib/librte_vhost/vhost_user/virtio-net-user.c
index 65b5652..f5248bc 100644
--- a/lib/librte_vhost/vhost_user/virtio-net-user.c
+++ b/lib/librte_vhost/vhost_user/virtio-net-user.c
@@ -225,8 +225,8 @@ static int
vq_is_ready(struct vhost_virtqueue *vq)
{
return vq && vq->desc &&
- vq->kickfd != -1 &&
- vq->callfd != -1;
+ vq->kickfd != VIRTIO_UNINITIALIZED_EVENTFD &&
+ vq->callfd != VIRTIO_UNINITIALIZED_EVENTFD;
}
static int
@@ -258,7 +258,7 @@ user_set_vring_call(struct vhost_device_ctx ctx,
struct VhostUserMsg *pmsg)
file.index = pmsg->payload.u64 & VHOST_USER_VRING_IDX_MASK;
if (pmsg->payload.u64 & VHOST_USER_VRING_NOFD_MASK)
-
[dpdk-dev] [PATCH v4] cryptodev: add capabilities discovery mechanism
Tested-by: Min Cao
- Tested Commit: 94b0ad8e0aa556230183f4c4d06b68bfd145dce3
- OS: Fedora20 3.11.10-301.fc20.x86_64
- GCC: gcc (GCC) 4.8.3
- CPU: Intel(R) Xeon(R) CPU E5-2658 v3 @ 2.20GHz
- NIC: Niantic
- Default x86_64-native-linuxapp-gcc configuration
- Prerequisites:
- Total 56 cases, 56 passed, 0 failed
- test case 1: QAT Unit test
Total 45 cases, 45 passed, 0 failed
- test case 2: AES_NI Unit test
Total 10 cases, 10 passed, 0 failed
- test case 3: l2fwd-crypto
Total 1 cases, 1 passed, 0 failed
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Pablo de Lara
Sent: Friday, March 11, 2016 9:37 AM
To: dev at dpdk.org
Subject: [dpdk-dev] [PATCH v4] cryptodev: add capabilities discovery mechanism
From: Declan Doherty
This patch add a mechanism for discovery of crypto device features and
supported crypto operations and algorithms. It also provides a method for a
crypto PMD to publish any data range limitations it may have for the operations
and algorithms it supports.
The parameter feature_flags added to rte_cryptodev struct is used to capture
features such as operations supported (symmetric crypto, operation chaining
etc) as well parameter such as whether the device is hardware accelerated or
uses SIMD instructions.
The capabilities parameter allows a PMD to define an array of supported
operations with any limitation which that implementation may have.
Finally the rte_cryptodev_info struct has been extended to allow retrieval of
these parameter using the existing rte_cryptodev_info_get() API.
Signed-off-by: Declan Doherty
Signed-off-by: Pablo de Lara
Acked-by: Fiona Trahe
---
This patch depends on "null_crypto_pmd: PMD to support null crypto operations"
patch
(http://dpdk.org/dev/patchwork/patch/11428/)
and "snow3g: Bit-wise handling for Wireless Algorithm" patch
(http://dpdk.org/dev/patchwork/patch/11429/)
Changes in v4:
- Added missing capabilities information in device info
Changes in v3:
- Renamed macro to specify symmetric algo chaining
Changes in v2:
- Fixed incorrect values for sizes
- Renamed some fields in capabilities structure
- Added capabilities for new PMDs
drivers/crypto/aesni_gcm/aesni_gcm_pmd.c | 18 +++
drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c | 51 +++
drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 18 +++
drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c | 175 +
drivers/crypto/null/null_crypto_pmd.c | 3 +
drivers/crypto/null/null_crypto_pmd_ops.c | 47 ++
drivers/crypto/qat/qat_crypto.c| 201 -
drivers/crypto/qat/rte_qat_cryptodev.c | 3 +
drivers/crypto/snow3g/rte_snow3g_pmd.c | 3 +
drivers/crypto/snow3g/rte_snow3g_pmd_ops.c | 51 +++
lib/librte_cryptodev/rte_cryptodev.c | 28
lib/librte_cryptodev/rte_cryptodev.h | 137 +
lib/librte_cryptodev/rte_cryptodev_version.map | 1 +
13 files changed, 735 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
b/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
index 83aa272..35577bc 100644
--- a/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
+++ b/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
@@ -445,6 +445,24 @@ aesni_gcm_create(const char *name,
dev->dequeue_burst = aesni_gcm_pmd_dequeue_burst;
dev->enqueue_burst = aesni_gcm_pmd_enqueue_burst;
+ dev->feature_flags = RTE_CRYPTODEV_FF_SYMMETRIC_CRYPTO |
+ RTE_CRYPTODEV_FF_SYM_OPERATION_CHAINING |
+ RTE_CRYPTODEV_FF_CPU_AESNI;
+
+ switch (vector_mode) {
+ case RTE_AESNI_GCM_SSE:
+ dev->feature_flags |= RTE_CRYPTODEV_FF_CPU_SSE;
+ break;
+ case RTE_AESNI_GCM_AVX:
+ dev->feature_flags |= RTE_CRYPTODEV_FF_CPU_AVX;
+ break;
+ case RTE_AESNI_GCM_AVX2:
+ dev->feature_flags |= RTE_CRYPTODEV_FF_CPU_AVX2;
+ break;
+ default:
+ break;
+ }
+
/* Set vector instructions mode supported */
internals = dev->data->dev_private;
diff --git a/drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c
b/drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c
index f865e0d..387f8d1 100644
--- a/drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c
+++ b/drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c
@@ -38,6 +38,55 @@
#include "aesni_gcm_pmd_private.h"
+static const struct rte_cryptodev_capabilities aesni_gcm_pmd_capabilities[] = {
+ { /* AES GCM (AUTH) */
+ .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
+ .sym = {
+ .xform_type = RTE_CRYPTO_SYM_XFORM_AUTH,
+ .auth = {
+ .algo = RTE_CRYPTO_AUTH_AES_GCM,
+ .block_size = 16,
+ .key_size = {
+ .min = 16,
+
[dpdk-dev] [PATCH v2] vhost: Fix default value of kickfd and callfd
On Mon, Mar 14, 2016 at 04:54:00PM +0900, Tetsuya Mukawa wrote:
> On 2016/03/14 11:08, Yuanhan Liu wrote:
> > On Mon, Mar 14, 2016 at 10:54:14AM +0900, Tetsuya Mukawa wrote:
> >> On 2016/03/11 16:19, Yuanhan Liu wrote:
> >>> On Thu, Mar 10, 2016 at 04:06:05PM +0900, Tetsuya Mukawa wrote:
> Currently, default values of kickfd and callfd are -1.
> If the values are -1, current code guesses kickfd and callfd haven't
> been initialized yet. And vhost library will guess the virtqueue isn't
> ready for processing.
> But callfd and kickfd will be set as -1 when "--enable-kvm"
> isn't specified in QEMU command line. It means we cannot treat -1 as
> uninitialized state. The patch changes default values to -2. And the
> patch defines -2 as VIRTIO_UNINITIALIZED_EVENTFD.
> >>> This looks more like a workaround to me.
> >>
> >> Hi Yuanhan,
> >>
> >> Sorry for late reply.
> >> I have checked QEMU documentation, and found below.
> >>
> >> --
> >> * VHOST_USER_SET_VRING_CALL
> >>
> >> Id: 14
> >> Equivalent ioctl: VHOST_SET_VRING_CALL
> >> Master payload: u64
> >>
> >> Set the event file descriptor to signal when buffers are used. It
> >> is passed in the ancillary data.
> >> Bits (0-7) of the payload contain the vring index. Bit 8 is the
> >> invalid FD flag.
> >> --
> >>
> >> VHOST_USER_SET_VRING_KICK has almost same description.
> >> I will check this invalid flag, and if it works for our case, then will
> >> use it.
> >> How about it?
> > Yeah, that indeed sounds much better.
>
> I've checked current dpdk code.
> It seems we've already checked invalid flag like below.
>
> if (pmsg->payload.u64 & VHOST_USER_VRING_NOFD_MASK)
> file.fd = -1;
> else
> file.fd = pmsg->fds[0];
>
> So how about adding below macros or enum?
>
> #define VIRTIO_UNINITIALIZED_EVENTFD (-2)
> #define VIRTIO_INVALID_EVENTFD (-1)
>
> I am still not sure whether using enum is better or not.
Both are Okay to me; I have no preference on that.
> But here is one of example patch.
> What do you think?
Looks okay to me
>
> diff --git a/lib/librte_vhost/rte_virtio_net.h
> b/lib/librte_vhost/rte_virtio_net.h
> index 7d1fde2..2a7566d 100644
> --- a/lib/librte_vhost/rte_virtio_net.h
> +++ b/lib/librte_vhost/rte_virtio_net.h
> @@ -89,6 +89,8 @@ struct vhost_virtqueue {
> uint16_tvhost_hlen; /**< Vhost
> header length (varies depending on RX merge buffers. */
> volatile uint16_t last_used_idx; /**< Last index
> used on the available ring */
> volatile uint16_t last_used_idx_res; /**< Used for
> multiple devices reserving buffers. */
> +#define VIRTIO_UNINITIALIZED_EVENTFD (-2)
> +#define VIRTIO_INVALID_EVENTFD (-1)
One nit: you may keep it in order.
--yliu
[dpdk-dev] [PATCH v3] cryptodev: add capabilities discovery mechanism
Tested-by: Min Cao
- Tested Commit: 94b0ad8e0aa556230183f4c4d06b68bfd145dce3
- OS: Fedora20 3.11.10-301.fc20.x86_64
- GCC: gcc (GCC) 4.8.3
- CPU: Intel(R) Xeon(R) CPU E5-2658 v3 @ 2.20GHz
- NIC: Niantic
- Default x86_64-native-linuxapp-gcc configuration
- Prerequisites:
- Total 56 cases, 56 passed, 0 failed
- test case 1: QAT Unit test
Total 45 cases, 45 passed, 0 failed
- test case 2: AES_NI Unit test
Total 10 cases, 10 passed, 0 failed
- test case 3: l2fwd-crypto
Total 1 cases, 1 passed, 0 failed
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Pablo de Lara
Sent: Friday, March 11, 2016 3:55 AM
To: dev at dpdk.org
Subject: [dpdk-dev] [PATCH v3] cryptodev: add capabilities discovery mechanism
From: Declan Doherty
This patch add a mechanism for discovery of crypto device features and
supported crypto operations and algorithms. It also provides a method for a
crypto PMD to publish any data range limitations it may have for the operations
and algorithms it supports.
The parameter feature_flags added to rte_cryptodev struct is used to capture
features such as operations supported (symmetric crypto, operation chaining
etc) as well parameter such as whether the device is hardware accelerated or
uses SIMD instructions.
The capabilities parameter allows a PMD to define an array of supported
operations with any limitation which that implementation may have.
Finally the rte_cryptodev_info struct has been extended to allow retrieval of
these parameter using the existing rte_cryptodev_info_get() API.
Signed-off-by: Declan Doherty
Signed-off-by: Pablo de Lara
---
This patch depends on "null_crypto_pmd: PMD to support null crypto operations"
patch
(http://dpdk.org/dev/patchwork/patch/11428/)
and "snow3g: Bit-wise handling for Wireless Algorithm" patch
(http://dpdk.org/dev/patchwork/patch/11429/)
Changes in v3:
- Renamed macro to specify symmetric algo chaining
Changes in v2:
- Fixed incorrect values for sizes
- Renamed some fields in capabilities structure
- Added capabilities for new PMDs
drivers/crypto/aesni_gcm/aesni_gcm_pmd.c | 18 +++
drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c | 49 ++
drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 18 +++
drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c | 175 +
drivers/crypto/null/null_crypto_pmd.c | 3 +
drivers/crypto/null/null_crypto_pmd_ops.c | 47 ++
drivers/crypto/qat/qat_crypto.c| 201 -
drivers/crypto/qat/rte_qat_cryptodev.c | 3 +
drivers/crypto/snow3g/rte_snow3g_pmd.c | 3 +
drivers/crypto/snow3g/rte_snow3g_pmd_ops.c | 51 +++
lib/librte_cryptodev/rte_cryptodev.c | 28
lib/librte_cryptodev/rte_cryptodev.h | 137 +
lib/librte_cryptodev/rte_cryptodev_version.map | 1 +
13 files changed, 733 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
b/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
index 83aa272..35577bc 100644
--- a/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
+++ b/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
@@ -445,6 +445,24 @@ aesni_gcm_create(const char *name,
dev->dequeue_burst = aesni_gcm_pmd_dequeue_burst;
dev->enqueue_burst = aesni_gcm_pmd_enqueue_burst;
+ dev->feature_flags = RTE_CRYPTODEV_FF_SYMMETRIC_CRYPTO |
+ RTE_CRYPTODEV_FF_SYM_OPERATION_CHAINING |
+ RTE_CRYPTODEV_FF_CPU_AESNI;
+
+ switch (vector_mode) {
+ case RTE_AESNI_GCM_SSE:
+ dev->feature_flags |= RTE_CRYPTODEV_FF_CPU_SSE;
+ break;
+ case RTE_AESNI_GCM_AVX:
+ dev->feature_flags |= RTE_CRYPTODEV_FF_CPU_AVX;
+ break;
+ case RTE_AESNI_GCM_AVX2:
+ dev->feature_flags |= RTE_CRYPTODEV_FF_CPU_AVX2;
+ break;
+ default:
+ break;
+ }
+
/* Set vector instructions mode supported */
internals = dev->data->dev_private;
diff --git a/drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c
b/drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c
index f865e0d..af7907b 100644
--- a/drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c
+++ b/drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c
@@ -38,6 +38,55 @@
#include "aesni_gcm_pmd_private.h"
+static const struct rte_cryptodev_capabilities aesni_gcm_pmd_capabilities[] = {
+ { /* AES GCM (AUTH) */
+ .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
+ .sym = {
+ .xform_type = RTE_CRYPTO_SYM_XFORM_AUTH,
+ .auth = {
+ .algo = RTE_CRYPTO_AUTH_AES_GCM,
+ .block_size = 16,
+ .key_size = {
+ .min = 16,
+ .max = 32,
+ .increment = 8
+
[dpdk-dev] [PATCH] ethdev: don't count missed packets in erroneous packets counter
Hi, > -Original Message- > From: Igor Ryzhov [mailto:iryzhov at nfware.com] > Sent: Monday, March 14, 2016 3:31 PM > To: ? ? > Cc: dev at dpdk.org; Rahul Lakkireddy; Lu, Wenzhuo; Zhang, Helin; Ananyev, > Konstantin > Subject: Re: [dpdk-dev] [PATCH] ethdev: don't count missed packets in > erroneous packets counter > > Ping. > > CCing to maintainers of affected drivers. > > > 10 ? 2016 ?., ? 16:03, Igor Ryzhov ???(?): > > > > Comment for "ierrors" counter says that it counts erroneous received > > packets. > But for some reason "imissed" counter is added to "ierrors" counter in most > drivers. It is a mistake, because missed packets are obviously not received. > This > patch fixes it. > > > > Signed-off-by: Igor Ryzhov Acked-by: Wenzhuo Lu Agree with Igor. As we have a counter for imissed, we need not to mix it with ierror.
[dpdk-dev] [PATCH v2] cryptodev: add capabilities discovery mechanism
Tested-by: Min Cao
- Tested Commit: 94b0ad8e0aa556230183f4c4d06b68bfd145dce3
- OS: Fedora20 3.11.10-301.fc20.x86_64
- GCC: gcc (GCC) 4.8.3
- CPU: Intel(R) Xeon(R) CPU E5-2658 v3 @ 2.20GHz
- NIC: Niantic
- Default x86_64-native-linuxapp-gcc configuration
- Prerequisites:
- Total 56 cases, 56 passed, 0 failed
- test case 1: QAT Unit test
Total 45 cases, 45 passed, 0 failed
- test case 2: AES_NI Unit test
Total 10 cases, 10 passed, 0 failed
- test case 3: l2fwd-crypto
Total 1 cases, 1 passed, 0 failed
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Pablo de Lara
Sent: Friday, March 11, 2016 1:07 AM
To: dev at dpdk.org
Subject: [dpdk-dev] [PATCH v2] cryptodev: add capabilities discovery mechanism
From: Declan Doherty
This patch add a mechanism for discovery of crypto device features and
supported crypto operations and algorithms. It also provides a method for a
crypto PMD to publish any data range limitations it may have for the operations
and algorithms it supports.
The parameter feature_flags added to rte_cryptodev struct is used to capture
features such as operations supported (symmetric crypto, operation chaining
etc) as well parameter such as whether the device is hardware accelerated or
uses SIMD instructions.
The capabilities parameter allows a PMD to define an array of supported
operations with any limitation which that implementation may have.
Finally the rte_cryptodev_info struct has been extended to allow retrieval of
these parameter using the existing rte_cryptodev_info_get() API.
Signed-off-by: Declan Doherty
Signed-off-by: Pablo de Lara
---
This patch depends on "null_crypto_pmd: PMD to support null crypto operations"
patch
(http://dpdk.org/dev/patchwork/patch/11428/)
and "snow3g: Bit-wise handling for Wireless Algorithm" patch
(http://dpdk.org/dev/patchwork/patch/11429/)
Changes in v2:
- Fixed incorrect values for sizes
- Renamed some fields in capabilities structure
- Added capabilities for new PMDs
drivers/crypto/aesni_gcm/aesni_gcm_pmd.c | 18 +++
drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c | 49 ++
drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 18 +++
drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c | 175 +
drivers/crypto/null/null_crypto_pmd.c | 3 +
drivers/crypto/null/null_crypto_pmd_ops.c | 47 ++
drivers/crypto/qat/qat_crypto.c| 201 -
drivers/crypto/qat/rte_qat_cryptodev.c | 3 +
drivers/crypto/snow3g/rte_snow3g_pmd.c | 3 +
drivers/crypto/snow3g/rte_snow3g_pmd_ops.c | 51 +++
lib/librte_cryptodev/rte_cryptodev.c | 28
lib/librte_cryptodev/rte_cryptodev.h | 137 +
lib/librte_cryptodev/rte_cryptodev_version.map | 1 +
13 files changed, 733 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
b/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
index 83aa272..c94bb7d 100644
--- a/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
+++ b/drivers/crypto/aesni_gcm/aesni_gcm_pmd.c
@@ -445,6 +445,24 @@ aesni_gcm_create(const char *name,
dev->dequeue_burst = aesni_gcm_pmd_dequeue_burst;
dev->enqueue_burst = aesni_gcm_pmd_enqueue_burst;
+ dev->feature_flags = RTE_CRYPTODEV_FF_SYMMETRIC_CRYPTO |
+ RTE_CRYPTODEV_FF_OPERATION_CHAINING |
+ RTE_CRYPTODEV_FF_CPU_AESNI;
+
+ switch (vector_mode) {
+ case RTE_AESNI_GCM_SSE:
+ dev->feature_flags |= RTE_CRYPTODEV_FF_CPU_SSE;
+ break;
+ case RTE_AESNI_GCM_AVX:
+ dev->feature_flags |= RTE_CRYPTODEV_FF_CPU_AVX;
+ break;
+ case RTE_AESNI_GCM_AVX2:
+ dev->feature_flags |= RTE_CRYPTODEV_FF_CPU_AVX2;
+ break;
+ default:
+ break;
+ }
+
/* Set vector instructions mode supported */
internals = dev->data->dev_private;
diff --git a/drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c
b/drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c
index f865e0d..af7907b 100644
--- a/drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c
+++ b/drivers/crypto/aesni_gcm/aesni_gcm_pmd_ops.c
@@ -38,6 +38,55 @@
#include "aesni_gcm_pmd_private.h"
+static const struct rte_cryptodev_capabilities aesni_gcm_pmd_capabilities[] = {
+ { /* AES GCM (AUTH) */
+ .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC,
+ .sym = {
+ .xform_type = RTE_CRYPTO_SYM_XFORM_AUTH,
+ .auth = {
+ .algo = RTE_CRYPTO_AUTH_AES_GCM,
+ .block_size = 16,
+ .key_size = {
+ .min = 16,
+ .max = 32,
+ .increment = 8
+ },
+ .digest_size = {
+
[dpdk-dev] [PATCH v2] vhost: Fix default value of kickfd and callfd
On 2016/03/14 17:21, Yuanhan Liu wrote:
> On Mon, Mar 14, 2016 at 04:54:00PM +0900, Tetsuya Mukawa wrote:
>> On 2016/03/14 11:08, Yuanhan Liu wrote:
>>> On Mon, Mar 14, 2016 at 10:54:14AM +0900, Tetsuya Mukawa wrote:
On 2016/03/11 16:19, Yuanhan Liu wrote:
> On Thu, Mar 10, 2016 at 04:06:05PM +0900, Tetsuya Mukawa wrote:
>> Currently, default values of kickfd and callfd are -1.
>> If the values are -1, current code guesses kickfd and callfd haven't
>> been initialized yet. And vhost library will guess the virtqueue isn't
>> ready for processing.
>> But callfd and kickfd will be set as -1 when "--enable-kvm"
>> isn't specified in QEMU command line. It means we cannot treat -1 as
>> uninitialized state. The patch changes default values to -2. And the
>> patch defines -2 as VIRTIO_UNINITIALIZED_EVENTFD.
> This looks more like a workaround to me.
Hi Yuanhan,
Sorry for late reply.
I have checked QEMU documentation, and found below.
--
* VHOST_USER_SET_VRING_CALL
Id: 14
Equivalent ioctl: VHOST_SET_VRING_CALL
Master payload: u64
Set the event file descriptor to signal when buffers are used. It
is passed in the ancillary data.
Bits (0-7) of the payload contain the vring index. Bit 8 is the
invalid FD flag.
--
VHOST_USER_SET_VRING_KICK has almost same description.
I will check this invalid flag, and if it works for our case, then will
use it.
How about it?
>>> Yeah, that indeed sounds much better.
>> I've checked current dpdk code.
>> It seems we've already checked invalid flag like below.
>>
>> if (pmsg->payload.u64 & VHOST_USER_VRING_NOFD_MASK)
>> file.fd = -1;
>> else
>> file.fd = pmsg->fds[0];
>>
>> So how about adding below macros or enum?
>>
>> #define VIRTIO_UNINITIALIZED_EVENTFD (-2)
>> #define VIRTIO_INVALID_EVENTFD (-1)
>>
>> I am still not sure whether using enum is better or not.
> Both are Okay to me; I have no preference on that.
>
>> But here is one of example patch.
>> What do you think?
> Looks okay to me
>
>> diff --git a/lib/librte_vhost/rte_virtio_net.h
>> b/lib/librte_vhost/rte_virtio_net.h
>> index 7d1fde2..2a7566d 100644
>> --- a/lib/librte_vhost/rte_virtio_net.h
>> +++ b/lib/librte_vhost/rte_virtio_net.h
>> @@ -89,6 +89,8 @@ struct vhost_virtqueue {
>> uint16_tvhost_hlen; /**< Vhost
>> header length (varies depending on RX merge buffers. */
>> volatile uint16_t last_used_idx; /**< Last index
>> used on the available ring */
>> volatile uint16_t last_used_idx_res; /**< Used for
>> multiple devices reserving buffers. */
>> +#define VIRTIO_UNINITIALIZED_EVENTFD (-2)
>> +#define VIRTIO_INVALID_EVENTFD (-1)
> One nit: you may keep it in order.
Thanks for your comments, will change it.
Tetsuya
> --yliu
[dpdk-dev] [PATCH v3] vhost: Fix default value of kickfd and callfd
Currently, default values of kickfd and callfd are -1.
If the values are -1, current code guesses kickfd and callfd haven't
been initialized yet. Then vhost library will guess the virtqueue isn't
ready for processing.
But callfd and kickfd will be set as -1 when "--enable-kvm"
isn't specified in QEMU command line. It means we cannot treat -1 as
uninitialized state.
The patch defines -1 and -2 as VIRTIO_INVALID_EVENTFD and
VIRTIO_UNINITIALIZED_EVENTFD, and uses VIRTIO_UNINITIALIZED_EVENTFD for
the default values of kickfd and callfd.
Signed-off-by: Tetsuya Mukawa
---
lib/librte_vhost/rte_virtio_net.h | 2 ++
lib/librte_vhost/vhost_rxtx.c | 9 ++---
lib/librte_vhost/vhost_user/virtio-net-user.c | 14 +++---
lib/librte_vhost/virtio-net.c | 4 ++--
4 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/lib/librte_vhost/rte_virtio_net.h
b/lib/librte_vhost/rte_virtio_net.h
index 443245d..600b20b 100644
--- a/lib/librte_vhost/rte_virtio_net.h
+++ b/lib/librte_vhost/rte_virtio_net.h
@@ -89,6 +89,8 @@ struct vhost_virtqueue {
uint16_tvhost_hlen; /**< Vhost header
length (varies depending on RX merge buffers. */
volatile uint16_t last_used_idx; /**< Last index used on
the available ring */
volatile uint16_t last_used_idx_res; /**< Used for multiple
devices reserving buffers. */
+#define VIRTIO_INVALID_EVENTFD (-1)
+#define VIRTIO_UNINITIALIZED_EVENTFD (-2)
int callfd; /**< Used to notify the
guest (trigger interrupt). */
int kickfd; /**< Currently unused
as polling mode is enabled. */
int enabled;
diff --git a/lib/librte_vhost/vhost_rxtx.c b/lib/librte_vhost/vhost_rxtx.c
index 9d23eb1..29d002d 100644
--- a/lib/librte_vhost/vhost_rxtx.c
+++ b/lib/librte_vhost/vhost_rxtx.c
@@ -333,7 +333,8 @@ virtio_dev_rx(struct virtio_net *dev, uint16_t queue_id,
rte_mb();
/* Kick the guest if necessary. */
- if (!(vq->avail->flags & VRING_AVAIL_F_NO_INTERRUPT))
+ if (!(vq->avail->flags & VRING_AVAIL_F_NO_INTERRUPT)
+ && (vq->callfd >= 0))
eventfd_write(vq->callfd, (eventfd_t)1);
return count;
}
@@ -654,7 +655,8 @@ merge_rx_exit:
rte_mb();
/* Kick the guest if necessary. */
- if (!(vq->avail->flags & VRING_AVAIL_F_NO_INTERRUPT))
+ if (!(vq->avail->flags & VRING_AVAIL_F_NO_INTERRUPT)
+ && (vq->callfd >= 0))
eventfd_write(vq->callfd, (eventfd_t)1);
}
@@ -1048,7 +1050,8 @@ rte_vhost_dequeue_burst(struct virtio_net *dev, uint16_t
queue_id,
sizeof(vq->used->idx));
/* Kick guest if required. */
- if (!(vq->avail->flags & VRING_AVAIL_F_NO_INTERRUPT))
+ if (!(vq->avail->flags & VRING_AVAIL_F_NO_INTERRUPT)
+ && (vq->callfd >= 0))
eventfd_write(vq->callfd, (eventfd_t)1);
out:
diff --git a/lib/librte_vhost/vhost_user/virtio-net-user.c
b/lib/librte_vhost/vhost_user/virtio-net-user.c
index 65b5652..f5248bc 100644
--- a/lib/librte_vhost/vhost_user/virtio-net-user.c
+++ b/lib/librte_vhost/vhost_user/virtio-net-user.c
@@ -225,8 +225,8 @@ static int
vq_is_ready(struct vhost_virtqueue *vq)
{
return vq && vq->desc &&
- vq->kickfd != -1 &&
- vq->callfd != -1;
+ vq->kickfd != VIRTIO_UNINITIALIZED_EVENTFD &&
+ vq->callfd != VIRTIO_UNINITIALIZED_EVENTFD;
}
static int
@@ -258,7 +258,7 @@ user_set_vring_call(struct vhost_device_ctx ctx, struct
VhostUserMsg *pmsg)
file.index = pmsg->payload.u64 & VHOST_USER_VRING_IDX_MASK;
if (pmsg->payload.u64 & VHOST_USER_VRING_NOFD_MASK)
- file.fd = -1;
+ file.fd = VIRTIO_INVALID_EVENTFD;
else
file.fd = pmsg->fds[0];
RTE_LOG(INFO, VHOST_CONFIG,
@@ -279,7 +279,7 @@ user_set_vring_kick(struct vhost_device_ctx ctx, struct
VhostUserMsg *pmsg)
file.index = pmsg->payload.u64 & VHOST_USER_VRING_IDX_MASK;
if (pmsg->payload.u64 & VHOST_USER_VRING_NOFD_MASK)
- file.fd = -1;
+ file.fd = VIRTIO_INVALID_EVENTFD;
else
file.fd = pmsg->fds[0];
RTE_LOG(INFO, VHOST_CONFIG,
@@ -316,10 +316,10 @@ user_get_vring_base(struct vhost_device_ctx ctx,
* sent and only sent in vhost_vring_stop.
* TODO: cleanup the vring, it isn't usable since here.
*/
- if (dev->virtqueue[state->index]->kickfd >= 0) {
+ if (dev->virtqueue[state->index]->kickfd >= 0)
close(dev->virtqueue[state->index]->kickfd);
- dev->virtqueue[state->index]->kickfd = -1;
- }
+
+ dev->virtqueue[state->index]->kickfd = VIRTIO_UNI
[dpdk-dev] [PATCH v8 0/5] cryptodev API changes
Tested-by: Min Cao - Tested Commit: 4c387fcdf7776d3bb9f47789580a57bd18d4dbf3 - OS: Fedora20 3.11.10-301.fc20.x86_64 - GCC: gcc (GCC) 4.8.3 - CPU: Intel(R) Xeon(R) CPU E5-2658 v3 @ 2.20GHz - NIC: Niantic - Default x86_64-native-linuxapp-gcc configuration - Prerequisites: - Total 23 cases, 23 passed, 0 failed - test case 1: QAT Unit test Total 13 cases, 13 passed, 0 failed - test case 2: AES_NI Unit test Total 10 cases, 10 passed, 0 failed -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Fiona Trahe Sent: Thursday, March 10, 2016 9:43 PM To: dev at dpdk.org Subject: [dpdk-dev] [PATCH v8 0/5] cryptodev API changes This patch set separates the symmetric crypto operations from generic operations and then modifies the cryptodev burst API to accept bursts of rte_crypto_op rather than rte_mbufs. v8: - split patchset for easier review - fix broken /examples/l2fwd-crypto build in intermediate patch - split removal of rte_mbuf_offload into separate commit v7: - remove trailing spaces introduced in v6 - rebase against recent config file changes v6: - restore EXPERIMENTAL label to cryptodev. Will handle removal in separate thread. (email subject was incorrect in v5, so v5 hasn't arrived in patchwork, therefore v6 is in-reply-to v4 message id) V5: - updates .map file - removes EXPERIMENTAL label from rte_cryptodev.h V4: - Fixes for issues introduced in __rte_crypto_op_raw_bulk_alloc in V3 patcheset. - Typo fix in cached attribute on rte_crypto_op structure. V3: - Addresses V2 comments - Rebased for head Declan Doherty (2): cryptodev: change burst API to be crypto op oriented mbuf_offload: remove library Fiona Trahe (3): cryptodev: code cleanup cryptodev: refactor to partition common from symmetric-specific code cryptodev: remove unused phys_addr field from key MAINTAINERS| 4 - app/test/test_cryptodev.c | 883 +++-- app/test/test_cryptodev.h | 5 +- app/test/test_cryptodev_perf.c | 270 --- config/common_base | 7 - doc/api/doxy-api-index.md | 1 - drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 190 +++-- drivers/crypto/aesni_mb/rte_aesni_mb_pmd_ops.c | 30 +- drivers/crypto/aesni_mb/rte_aesni_mb_pmd_private.h | 10 +- drivers/crypto/qat/qat_crypto.c| 160 ++-- drivers/crypto/qat/qat_crypto.h| 14 +- drivers/crypto/qat/rte_qat_cryptodev.c | 8 +- examples/l2fwd-crypto/main.c | 234 +++--- lib/Makefile | 1 - lib/librte_cryptodev/Makefile | 1 + lib/librte_cryptodev/rte_crypto.h | 819 --- lib/librte_cryptodev/rte_crypto_sym.h | 642 +++ lib/librte_cryptodev/rte_cryptodev.c | 115 ++- lib/librte_cryptodev/rte_cryptodev.h | 189 ++--- lib/librte_cryptodev/rte_cryptodev_pmd.h | 32 +- lib/librte_cryptodev/rte_cryptodev_version.map | 7 +- lib/librte_mbuf/rte_mbuf.h | 6 - lib/librte_mbuf_offload/Makefile | 52 -- lib/librte_mbuf_offload/rte_mbuf_offload.c | 100 --- lib/librte_mbuf_offload/rte_mbuf_offload.h | 310 .../rte_mbuf_offload_version.map | 7 - 26 files changed, 2130 insertions(+), 1967 deletions(-) create mode 100644 lib/librte_cryptodev/rte_crypto_sym.h delete mode 100644 lib/librte_mbuf_offload/Makefile delete mode 100644 lib/librte_mbuf_offload/rte_mbuf_offload.c delete mode 100644 lib/librte_mbuf_offload/rte_mbuf_offload.h delete mode 100644 lib/librte_mbuf_offload/rte_mbuf_offload_version.map -- 2.1.0
[dpdk-dev] [PATCH] i40e: fix using memory after free issue
The old code still uses entry in the next loop of LIST_FOREACH after free() in
i40e_res_pool_destroy().
Change to a safe way to free entry, which is similar with LIST_FOREACH_SAFE in
FreeBSD.
Signed-off-by: Jiangu Zhao
---
drivers/net/i40e/i40e_ethdev.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 2f676f6..5af2128 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -3317,17 +3317,21 @@ i40e_res_pool_init (struct i40e_res_pool_info *pool,
uint32_t base,
static void
i40e_res_pool_destroy(struct i40e_res_pool_info *pool)
{
- struct pool_entry *entry;
+ struct pool_entry *entry, *next_entry;
if (pool == NULL)
return;
- LIST_FOREACH(entry, &pool->alloc_list, next) {
+ for (entry = LIST_FIRST(&pool->alloc_list);
+ entry && (next_entry = LIST_NEXT(entry, next), 1);
+ entry = next_entry) {
LIST_REMOVE(entry, next);
rte_free(entry);
}
- LIST_FOREACH(entry, &pool->free_list, next) {
+ for (entry = LIST_FIRST(&pool->free_list);
+ entry && (next_entry = LIST_NEXT(entry, next), 1);
+ entry = next_entry) {
LIST_REMOVE(entry, next);
rte_free(entry);
}
--
1.8.3.1
[dpdk-dev] [PATCH v3] vhost: Fix default value of kickfd and callfd
On Mon, Mar 14, 2016 at 05:53:32PM +0900, Tetsuya Mukawa wrote: > Currently, default values of kickfd and callfd are -1. > If the values are -1, current code guesses kickfd and callfd haven't > been initialized yet. Then vhost library will guess the virtqueue isn't > ready for processing. > But callfd and kickfd will be set as -1 when "--enable-kvm" > isn't specified in QEMU command line. It means we cannot treat -1 as > uninitialized state. > The patch defines -1 and -2 as VIRTIO_INVALID_EVENTFD and > VIRTIO_UNINITIALIZED_EVENTFD, and uses VIRTIO_UNINITIALIZED_EVENTFD for > the default values of kickfd and callfd. Don't be mean to put an empty line between paragraphs :) > Signed-off-by: Tetsuya Mukawa Acked-by: Yuanhan Liu Thanks. --yliu
[dpdk-dev] [PATCH v7 01/11] ethdev: add API to query packet type filling info
2016-03-10 03:31, Jianfeng Tan: > Add a new API rte_eth_dev_get_ptype_info to query whether/what packet > type can be filled by given already started device or its pmd rx burst > function has already been decided). [...] > /** > + * Retrieve the packet type information of an Ethernet device. > + * > + * @note > + * Better to invoke this API after the device is already started or rx > burst > + * function is decided, to obtain concise ptype information. > + * @param port_id > + * The port identifier of the Ethernet device. > + * @param ptype_mask > + * A hint of what kind of packet type which the caller is interested in. > + * @param ptypes > + * An array pointer to store adequent packet types, allocated by caller. > + * @param num > + * Size of the array pointed by param ptypes. > + * @return > + * - (>0) Number of ptypes supported. If it exceeds param num, exceeding > + * packet types will not be filled in the given array. > + * - (0 or -ENOTSUP) if PMD does not fill the specified ptype. > + * - (-ENODEV) if *port_id* invalid. > + */ > +int rte_eth_dev_get_ptype_info(uint8_t port_id, uint32_t ptype_mask, > +uint32_t *ptypes, int num); I think the word info is too vague. What do you think of these names? - rte_eth_dev_get_ptype_capa - rte_eth_dev_get_supported_ptypes
[dpdk-dev] [PATCH v7 01/11] ethdev: add API to query packet type filling info
On Mon, Mar 14, 2016 at 10:44:30AM +0100, Thomas Monjalon wrote: > 2016-03-10 03:31, Jianfeng Tan: > > Add a new API rte_eth_dev_get_ptype_info to query whether/what packet > > type can be filled by given already started device or its pmd rx burst > > function has already been decided). > [...] > > /** > > + * Retrieve the packet type information of an Ethernet device. > > + * > > + * @note > > + * Better to invoke this API after the device is already started or rx > > burst > > + * function is decided, to obtain concise ptype information. > > + * @param port_id > > + * The port identifier of the Ethernet device. > > + * @param ptype_mask > > + * A hint of what kind of packet type which the caller is interested in. > > + * @param ptypes > > + * An array pointer to store adequent packet types, allocated by caller. > > + * @param num > > + * Size of the array pointed by param ptypes. > > + * @return > > + * - (>0) Number of ptypes supported. If it exceeds param num, exceeding > > + * packet types will not be filled in the given array. > > + * - (0 or -ENOTSUP) if PMD does not fill the specified ptype. > > + * - (-ENODEV) if *port_id* invalid. > > + */ > > +int rte_eth_dev_get_ptype_info(uint8_t port_id, uint32_t ptype_mask, > > + uint32_t *ptypes, int num); > > I think the word info is too vague. > What do you think of these names? > - rte_eth_dev_get_ptype_capa > - rte_eth_dev_get_supported_ptypes > +1 for supported_ptypes /Bruce
[dpdk-dev] [PATCH v3 1/1] drivers/net/i40e: add ethdev functions
On Thu, Mar 10, 2016 at 12:25:27PM +, Mcnamara, John wrote: > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Remy Horton > > Sent: Wednesday, March 9, 2016 1:29 PM > > To: Zhang, Helin > > Cc: dev at dpdk.org > > Subject: [dpdk-dev] [PATCH v3 1/1] drivers/net/i40e: add ethdev functions > > > > Implements driver support for dumping of EEPROM and registers, > > and the setting of MAC address. > > > > Signed-off-by: Remy Horton > > Acked-by: John McNamara > Applied to dpdk-next-net/rel_16_04 /Bruce
[dpdk-dev] [PATCH] nfp: fix tx queue reset
When using start-stop functionality the per queue fields need to be properly reset. Fixes: b812daadad0d (\"nfp: add Rx and Tx\") Signed-off-by: Alejandro Lucero --- drivers/net/nfp/nfp_net.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c index 9c4f218..e1e014f 100644 --- a/drivers/net/nfp/nfp_net.c +++ b/drivers/net/nfp/nfp_net.c @@ -358,6 +358,7 @@ nfp_net_reset_tx_queue(struct nfp_net_txq *txq) txq->wr_p = 0; txq->rd_p = 0; txq->tail = 0; + txq->qcp_rd_p = 0; } static int -- 1.7.9.5
[dpdk-dev] [PATCH] virtio: fix wrong features returned for legacy virtio
On Thu, Mar 10, 2016 at 03:50:54PM +0800, Yuanhan Liu wrote:
> On Thu, Mar 10, 2016 at 08:43:37AM +0100, David Marchand wrote:
> > On Thu, Mar 10, 2016 at 8:01 AM, Yuanhan Liu
> > wrote:
> > > Declare dst as type uint32_t instead of uint64_t, otherwise, we will get
> > > a random upper 32 bit feature bits, as the following io port read reads
> > > lower 32 bit only. It could lead a feature bits that include
> > > VIRTIO_F_VERSION_1
> > > (the 32th bit) for legacy virtio, which is obviously wrong.
> > >
> > > Fixes: b8f04520ad71 ("virtio: use PCI ioport API")
> > >
> > > Cc: David Marchand
> > > Signed-off-by: Yuanhan Liu
> >
> > Argh, good catch.
> > Relooked at my patch, this should be the only bug (of this kind ;-)).
>
> Yes, I also have a check while making this patch.
>
> --yliu
> >
> > Reviewed-by: David Marchand
> >
> >
> > --
> > David Marchand
Hi,
this patch no longer applies to dpdk-next-net/rel_16_04 branch due to changes
in legacy_get_features function. Is it still needed? If so, please do a V2.
Regards,
/Bruce
[dpdk-dev] [PATCH] nfp: fix tx queue reset
On Mon, Mar 14, 2016 at 10:39:04AM +, Alejandro Lucero wrote: > When using start-stop functionality the per queue fields need to > be properly reset. > > Fixes: b812daadad0d (\"nfp: add Rx and Tx\") > > Signed-off-by: Alejandro Lucero > --- Applied to dpdk-next-net/rel_16_04 /Bruce
[dpdk-dev] [PATCH 0/3 v3] virtio: Tx performance improvements
On Fri, Mar 04, 2016 at 10:19:18AM -0800, Stephen Hemminger wrote: > This patch series uses virtio negotiated features to allow for > more packets to be queued to host even though the default QEMU/KVM > virtio queue is very small 256 elements. > > Stephen Hemminger (3): > virtio: use indirect ring elements > virtio: use any layout on transmit > virtio: optimize transmit enqueue > These patches require an ack to merge. Virtio maintainers, can you please review and ack if ok. /Bruce
[dpdk-dev] [PATCH v11 2/2] vhost: Add VHOST PMD
On Mon, Mar 07, 2016 at 11:07:14AM +0900, Tetsuya Mukawa wrote: > The patch introduces a new PMD. This PMD is implemented as thin wrapper > of librte_vhost. It means librte_vhost is also needed to compile the PMD. > The vhost messages will be handled only when a port is started. So start > a port first, then invoke QEMU. > > The PMD has 2 parameters. > - iface: The parameter is used to specify a path to connect to a >virtio-net device. > - queues: The parameter is used to specify the number of the queues >virtio-net device has. >(Default: 1) > > Here is an example. > $ ./testpmd -c f -n 4 --vdev 'eth_vhost0,iface=/tmp/sock0,queues=1' -- -i > > To connect above testpmd, here is qemu command example. > > $ qemu-system-x86_64 \ > > -chardev socket,id=chr0,path=/tmp/sock0 \ > -netdev vhost-user,id=net0,chardev=chr0,vhostforce,queues=1 \ > -device virtio-net-pci,netdev=net0,mq=on > > Signed-off-by: Tetsuya Mukawa > Acked-by: Ferruh Yigit > Acked-by: Yuanhan Liu > Acked-by: Rich Lane > Tested-by: Rich Lane > --- > MAINTAINERS | 5 + > config/common_base | 6 + > config/common_linuxapp | 1 + > doc/guides/nics/index.rst | 1 + This adds a new entry for vhost PMD into the index, but there is no vhost.rst file present in this patchset. Did you forget to add it? > doc/guides/rel_notes/release_16_04.rst | 4 + > drivers/net/Makefile| 4 + > drivers/net/vhost/Makefile | 62 ++ > drivers/net/vhost/rte_eth_vhost.c | 916 > > drivers/net/vhost/rte_eth_vhost.h | 109 > drivers/net/vhost/rte_pmd_vhost_version.map | 10 + > mk/rte.app.mk | 6 + > 11 files changed, 1124 insertions(+) > create mode 100644 drivers/net/vhost/Makefile > create mode 100644 drivers/net/vhost/rte_eth_vhost.c > create mode 100644 drivers/net/vhost/rte_eth_vhost.h > create mode 100644 drivers/net/vhost/rte_pmd_vhost_version.map /Bruce
[dpdk-dev] [PATCH 0/2] tools/setup.sh fixes
- added support to work with systems other than 2MB page size - added support to work with built-in kernel modules Jerin Jacob (2): tools/setup.sh: remove 2MB huge page size hard-cording tools/setup.sh: Support built-in kernel modules tools/setup.sh | 24 +--- 1 file changed, 13 insertions(+), 11 deletions(-) -- 2.1.0
[dpdk-dev] [PATCH 1/2] tools/setup.sh: remove 2MB huge page size hard-cording
Signed-off-by: Jerin Jacob
---
tools/setup.sh | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/tools/setup.sh b/tools/setup.sh
index faa5eee..b290b87 100755
--- a/tools/setup.sh
+++ b/tools/setup.sh
@@ -44,6 +44,8 @@ echo
"--
echo " RTE_SDK exported as $RTE_SDK"
echo
"--"
+HUGEPGSZ=`cat /proc/meminfo | grep Hugepagesize | cut -d : -f 2 | tr -d ' '`
+
#
# Application EAL parameters for setting memory options
(amount/channels/ranks).
#
@@ -325,7 +327,7 @@ clear_huge_pages()
{
echo > .echo_tmp
for d in /sys/devices/system/node/node? ; do
- echo "echo 0 > $d/hugepages/hugepages-2048kB/nr_hugepages" >>
.echo_tmp
+ echo "echo 0 > $d/hugepages/hugepages-${HUGEPGSZ}/nr_hugepages"
>> .echo_tmp
done
echo "Removing currently reserved hugepages"
sudo sh .echo_tmp
@@ -342,13 +344,13 @@ set_non_numa_pages()
clear_huge_pages
echo ""
- echo " Input the number of 2MB pages"
- echo " Example: to have 128MB of hugepages available, enter '64' to"
- echo " reserve 64 * 2MB pages"
+ echo " Input the number of ${HUGEPGSZ} hugepages"
+ echo " Example: to have 128MB of hugepages available in a 2MB huge
page system,"
+ echo " enter '64' to reserve 64 * 2MB pages"
echo -n "Number of pages: "
read Pages
- echo "echo $Pages >
/sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages" > .echo_tmp
+ echo "echo $Pages >
/sys/kernel/mm/hugepages/hugepages-${HUGEPGSZ}/nr_hugepages" > .echo_tmp
echo "Reserving hugepages"
sudo sh .echo_tmp
@@ -365,8 +367,8 @@ set_numa_pages()
clear_huge_pages
echo ""
- echo " Input the number of 2MB pages for each node"
- echo " Example: to have 128MB of hugepages available per node,"
+ echo " Input the number of ${HUGEPGSZ} hugepages for each node"
+ echo " Example: to have 128MB of hugepages available per node in a 2MB
huge page system,"
echo " enter '64' to reserve 64 * 2MB pages on each node"
echo > .echo_tmp
@@ -374,7 +376,7 @@ set_numa_pages()
node=$(basename $d)
echo -n "Number of pages for $node: "
read Pages
- echo "echo $Pages > $d/hugepages/hugepages-2048kB/nr_hugepages"
>> .echo_tmp
+ echo "echo $Pages >
$d/hugepages/hugepages-${HUGEPGSZ}/nr_hugepages" >> .echo_tmp
done
echo "Reserving hugepages"
sudo sh .echo_tmp
--
2.1.0
[dpdk-dev] [PATCH 2/2] tools/setup.sh: Support built-in kernel modules
probe the kernel module existence through /sys/module/ to make it work
with both module and inbuilt kernel module
Signed-off-by: Jerin Jacob
---
tools/setup.sh | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/setup.sh b/tools/setup.sh
index b290b87..6097ab7 100755
--- a/tools/setup.sh
+++ b/tools/setup.sh
@@ -427,7 +427,7 @@ grep_meminfo()
#
show_nics()
{
- if /sbin/lsmod | grep -q -e igb_uio -e vfio_pci; then
+ if [ -d /sys/module/vfio_pci -o -d /sys/module/igb_uio ]; then
${RTE_SDK}/tools/dpdk_nic_bind.py --status
else
echo "# Please load the 'igb_uio' or 'vfio-pci' kernel module
before "
@@ -440,7 +440,7 @@ show_nics()
#
bind_nics_to_vfio()
{
- if /sbin/lsmod | grep -q vfio_pci ; then
+ if [ -d /sys/module/vfio_pci ]; then
${RTE_SDK}/tools/dpdk_nic_bind.py --status
echo ""
echo -n "Enter PCI address of device to bind to VFIO driver: "
@@ -458,7 +458,7 @@ bind_nics_to_vfio()
#
bind_nics_to_igb_uio()
{
- if /sbin/lsmod | grep -q igb_uio ; then
+ if [ -d /sys/module/igb_uio ]; then
${RTE_SDK}/tools/dpdk_nic_bind.py --status
echo ""
echo -n "Enter PCI address of device to bind to IGB UIO driver:
"
--
2.1.0
[dpdk-dev] [PATCH v5 1/2] i40evf: allocate virtchnl cmd buffer for each vf
On Thu, Mar 10, 2016 at 11:41:10AM +0800, Jingjing Wu wrote: > Currently, i40evf PMD uses a global static buffer to send virtchnl > command to host driver. It is shared by multi VFs. > This patch changed to allocate virtchnl cmd buffer for each VF. > > Signed-off-by: Jingjing Wu > Acked-by: Helin Zhang > --- > drivers/net/i40e/i40e_ethdev.h| 2 + > drivers/net/i40e/i40e_ethdev_vf.c | 178 > +++--- > 2 files changed, 71 insertions(+), 109 deletions(-) > Hi Jingjing, I get some compilation errors when I apply this to dpdk-next-net. /home/bruce/next-net/dpdk-next-net/drivers/net/i40e/i40e_ethdev_vf.c: In function ?i40evf_add_del_all_mac_addr?: /home/bruce/next-net/dpdk-next-net/drivers/net/i40e/i40e_ethdev_vf.c:1801:21: error: ?cmd_result_buffer? undeclared (first use in this function) args.out_buffer = cmd_result_buffer; ^ This is with Fedora 23 with gcc 5.3.1 /Bruce
[dpdk-dev] [PATCH] app/test/test_table_acl: fix incorrect IP header
This patch fixes the incorrect IP header in ACL table test.
Signed-off-by: Fan Zhang
---
app/test/test_table_acl.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/app/test/test_table_acl.c b/app/test/test_table_acl.c
index 38e3a8e..2fc5f24 100644
--- a/app/test/test_table_acl.c
+++ b/app/test/test_table_acl.c
@@ -1,7 +1,7 @@
/*-
* BSD LICENSE
*
- * Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+ * Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -45,7 +45,9 @@
**/
struct ipv4_5tuple {
+ uint8_t ttl;
uint8_t proto;
+ uint16_t checksum;
uint32_t ip_src;
uint32_t ip_dst;
uint16_t port_src;
--
2.5.0
[dpdk-dev] [PATCH] examples/ip_pipeline: fix configuration parser
Fixes: 377cd98e ("example/ip_pipeline: add link identification")
Signed-off-by: Fan Zhang
Acked-by: Cristian Dumitrescu
---
examples/ip_pipeline/config_parse.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/examples/ip_pipeline/config_parse.c
b/examples/ip_pipeline/config_parse.c
index e39c23e..152889d 100644
--- a/examples/ip_pipeline/config_parse.c
+++ b/examples/ip_pipeline/config_parse.c
@@ -678,6 +678,8 @@ parse_eal(struct app_params *app,
p->pci_blacklist[i] =
strdup(entry->value);
PARSE_ERROR_MALLOC(p->pci_blacklist[i]);
+
+ break;
}
PARSE_ERROR_MESSAGE((i < APP_MAX_LINKS),
@@ -702,6 +704,8 @@ parse_eal(struct app_params *app,
p->pci_whitelist[i] = strdup(entry->value);
PARSE_ERROR_MALLOC(p->pci_whitelist[i]);
+
+ break;
}
PARSE_ERROR_MESSAGE((i < APP_MAX_LINKS),
@@ -720,6 +724,8 @@ parse_eal(struct app_params *app,
p->vdev[i] = strdup(entry->value);
PARSE_ERROR_MALLOC(p->vdev[i]);
+
+ break;
}
PARSE_ERROR_MESSAGE((i < APP_MAX_LINKS),
--
2.5.0
[dpdk-dev] [PATCH 0/3 v3] virtio: Tx performance improvements
On Mon, Mar 14, 2016 at 10:56:27AM +, Bruce Richardson wrote: > On Fri, Mar 04, 2016 at 10:19:18AM -0800, Stephen Hemminger wrote: > > This patch series uses virtio negotiated features to allow for > > more packets to be queued to host even though the default QEMU/KVM > > virtio queue is very small 256 elements. > > > > Stephen Hemminger (3): > > virtio: use indirect ring elements > > virtio: use any layout on transmit > > virtio: optimize transmit enqueue > > > These patches require an ack to merge. Virtio maintainers, can you please > review and ack if ok. Thomas meant to merge this set in last release. It was delayed due to a build error. So, I think it's okay to merge it. Anyway, here is mine: Acked-by: Yuanhan Liu --yliu
[dpdk-dev] [PATCH] virtio: fix wrong features returned for legacy virtio
On Mon, Mar 14, 2016 at 10:48:31AM +, Bruce Richardson wrote:
> On Thu, Mar 10, 2016 at 03:50:54PM +0800, Yuanhan Liu wrote:
> > On Thu, Mar 10, 2016 at 08:43:37AM +0100, David Marchand wrote:
> > > On Thu, Mar 10, 2016 at 8:01 AM, Yuanhan Liu
> > > wrote:
> > > > Declare dst as type uint32_t instead of uint64_t, otherwise, we will get
> > > > a random upper 32 bit feature bits, as the following io port read reads
> > > > lower 32 bit only. It could lead a feature bits that include
> > > > VIRTIO_F_VERSION_1
> > > > (the 32th bit) for legacy virtio, which is obviously wrong.
> > > >
> > > > Fixes: b8f04520ad71 ("virtio: use PCI ioport API")
> > > >
> > > > Cc: David Marchand
> > > > Signed-off-by: Yuanhan Liu
> > >
> > > Argh, good catch.
> > > Relooked at my patch, this should be the only bug (of this kind ;-)).
> >
> > Yes, I also have a check while making this patch.
> >
> > --yliu
> > >
> > > Reviewed-by: David Marchand
> > >
> > >
> > > --
> > > David Marchand
> Hi,
>
> this patch no longer applies to dpdk-next-net/rel_16_04 branch due to changes
> in legacy_get_features function.
Hi Bruce,
It's a patch based on Thomas' tree. And this patch fixes an regression
at there, too.
--yliu
> Is it still needed? If so, please do a V2.
>
> Regards,
> /Bruce
[dpdk-dev] dpdk hash lookup function crashed (segment fault)
Hello,
On Sun, Mar 13, 2016 at 10:38 AM, ?? wrote:
> Hi all,
> When I use the dpdk lookup function, I met the segment fault problem. Can
> anybody help to look at why this happens. I will put the aim what I want to
> do and the related piece of code, and my debug message,
>
>
> This problem is that in dpdk multi process - client and server example,
> dpdk-2.2.0/examples/multi_process/client_server_mp
> My aim is that server create a hash table, then share it to client. Client
> will write the hash table, server will read the hash table. I am using dpdk
> hash table. What I did is that server create a hash table (table and array
> entries), return the table address. I use memzone pass the table address to
> client. In client, the second lookup gets segment fault. The system gets
> crashed. I will put some related code here.
> create hash table function:
>
Let me see if I understand correctly. You're allocating a hash table
on huge-page backed memory.
You pass a pointer to that table over a shared memory structure.
Is that correct?
I don't think something being in a huge-page necessarily means it is
shared. That is, allocating your hash table using rte_calloc in the
primary isn't sufficient to make it available in the secondary.
Further, even if it was, I do not think that it would work, because
there are a bunch of pointers involved (i.e. ft->data). As far as I'm
aware, each process has its own "view" of the shared memory. It maps
it into its own local address space, and gives it an address according
to what is currently available there.
Most of my IPC with DPDK has involved passing packets around; I'm not
sure what the strategy is for hash tables. Synchronization issues
aside, I think you will need to put the hash table in its entirety in
shared memory, and avoid global pointers: either offset into the
shared memory, or have a structure with no pointers at all. From that,
you can probably build up local pointers.
Maybe somebody else can correct me or come up with a better idea.
Hope that helps,
Kyle
> struct onvm_ft*
>
> onvm_ft_create(int cnt, int entry_size) {
>
> struct rte_hash* hash;
>
> struct onvm_ft* ft;
>
> struct rte_hash_parameters ipv4_hash_params = {
>
> .name = NULL,
>
> .entries = cnt,
>
> .key_len = sizeof(struct onvm_ft_ipv4_5tuple),
>
> .hash_func = NULL,
>
> .hash_func_init_val = 0,
>
> };
>
>
>
>
> char s[64];
>
> /* create ipv4 hash table. use core number and cycle counter to get a
> unique name. */
>
> ipv4_hash_params.name = s;
>
> ipv4_hash_params.socket_id = rte_socket_id();
>
> snprintf(s, sizeof(s), "onvm_ft_%d-%"PRIu64, rte_lcore_id(),
> rte_get_tsc_cycles());
>
> hash = rte_hash_create(&ipv4_hash_params);
>
> if (hash == NULL) {
>
> return NULL;
>
> }
>
> ft = (struct onvm_ft*)rte_calloc("table", 1, sizeof(struct onvm_ft),
> 0);
>
> if (ft == NULL) {
>
> rte_hash_free(hash);
>
> return NULL;
>
> }
>
> ft->hash = hash;
>
> ft->cnt = cnt;
>
> ft->entry_size = entry_size;
>
> /* Create data array for storing values */
>
> ft->data = rte_calloc("entry", cnt, entry_size, 0);
>
> if (ft->data == NULL) {
>
> rte_hash_free(hash);
>
> rte_free(ft);
>
> return NULL;
>
> }
>
> return ft;
>
> }
>
>
>
>
> related structure:
>
> struct onvm_ft {
>
> struct rte_hash* hash;
>
> char* data;
>
> int cnt;
>
> int entry_size;
>
> };
>
>
>
>
> in server side, I will call the create function, use memzone share it to
> client. The following is what I do:
>
> related variables:
>
> struct onvm_ft *sdn_ft;
>
> struct onvm_ft **sdn_ft_p;
>
> const struct rte_memzone *mz_ftp;
>
>
>
>
> sdn_ft = onvm_ft_create(1024, sizeof(struct onvm_flow_entry));
>
> if(sdn_ft == NULL) {
>
> rte_exit(EXIT_FAILURE, "Unable to create flow table\n");
>
> }
>
> mz_ftp = rte_memzone_reserve(MZ_FTP_INFO, sizeof(struct onvm_ft *),
>
> rte_socket_id(), NO_FLAGS);
>
> if (mz_ftp == NULL) {
>
> rte_exit(EXIT_FAILURE, "Canot reserve memory zone for flow
> table pointer\n");
>
> }
>
> memset(mz_ftp->addr, 0, sizeof(struct onvm_ft *));
>
> sdn_ft_p = mz_ftp->addr;
>
> *sdn_ft_p = sdn_ft;
>
>
>
>
> In client side:
>
> struct onvm_ft *sdn_ft;
>
> static void
>
> map_flow_table(void) {
>
> const struct rte_memzone *mz_ftp;
>
> struct onvm_ft **ftp;
>
>
>
>
> mz_ftp = rte_memzone_lookup(MZ_FTP_INFO);
>
> if (mz_ftp == NULL)
>
> rte_exit(EXIT_FAILURE, "Cannot get flow table pointer\n");
>
> ftp = mz_ftp->addr;
>
> sdn_ft = *ftp;
>
> }
>
>
>
>
[dpdk-dev] [PATCH] doc: update release notes for ip_pipeline app
This patch updates the release notes with the features that have been added to ip_pipeline application. Signed-off-by: Jasvinder Singh Acked-by: Cristian Dumitrescu --- doc/guides/rel_notes/release_16_04.rst | 13 + 1 file changed, 13 insertions(+) diff --git a/doc/guides/rel_notes/release_16_04.rst b/doc/guides/rel_notes/release_16_04.rst index b729b67..a4e02fc 100644 --- a/doc/guides/rel_notes/release_16_04.rst +++ b/doc/guides/rel_notes/release_16_04.rst @@ -127,6 +127,15 @@ This section should contain new features added in this release. Sample format: Added new Crypto PMD to support null crypto operations in SW. +* **IP Pipeline Application.** + + The following features have been added to ip_pipeline application; + + * Added CPU utilization measurement and idle cycle rate computation. + * Added link idenfication support through existing port-mask option or by +specifying PCI device in every LINK section in the configuration file. + * Added load balancing support in passthrough pipeline. + Resolved Issues --- @@ -172,6 +181,10 @@ Libraries Fix crc32c hash functions to return a valid crc32c value for data lengths not multiple of 4 bytes. +* **librte_port: fixed segmentation fault for ring and ethdev writer nodrop.** + + Fix core dump issue on txq and swq when dropless is set to yes. + Examples -- 2.5.0
[dpdk-dev] [PATCH v5] examples/l2fwd-cat: PQoS CAT and CDP, example of libpqos usage
This patch implements PQoS as a sample application. PQoS allows management of the CPUs last level cache, which can be useful for DPDK to ensure quality of service. The sample app links against the existing 01.org PQoS library (https://github.com/01org/intel-cmt-cat). White paper demonstrating example use case "Increasing Platform Determinism with Platform Quality of Service for the Data Plane Development Kit" (http://www.intel.com/content/www/us/en/communications/increasing-platform-determinism-pqos-dpdk-white-paper.html) Signed-off-by: Wojciech Andralojc Signed-off-by: Tomasz Kantecki Signed-off-by: Marcel D Cornu --- Version 5: * Example app renamed to "l2fwd-cat" * Updated rst doc, added link to white paper Version 4: * PQOS_INSTALL_PATH must be defined to build example file * Updated example's Makefiles, MAINTAINERS and rst doc, Version 3: * Updated rst docs * Fixed checkpatch warnings * Updated comments in code Version 2: * Added signal handlers to do clean-up on SIGINT and SIGTERM * Clean-up function modified to zero globals (needed for testing) * Init function modified to return more applicable errnos Version 1: * Initial version Details of "--l3ca" app parameter to configure Intel CAT and CDP features: --l3ca=bitmask@ --l3ca=(code_bitmask,data_bitmask)@ makes selected CPU's use specified CAT bitmasks, bitmasks must be expressed in hexadecimal form CAT and CDP features allow management of the CPU's last level cache. CAT introduces classes of service (COS) that are essentially bitmasks. In current CAT implementations, a bit in a COS bitmask corresponds to one cache way in the last level cache. A CPU core is always assigned to one of the CAT classes. By programming CPU core assignment and COS bitmasks, applications can be given exclusive, shared, or mixed access to the CPU's last level cache. CDP extends CAT so that there are two bitmasks per COS, one for data and one for code. The number of classes and number of valid bits in a COS bitmask is CPU model specific and COS bitmasks need to be contiguous. Sample code calls this bitmask a cbm or a capacity bitmask. By default, after reset, all CPU cores are assigned to COS 0 and all classes are programmed to allow fill into all cache ways. CDP is off by default. For more information about CAT please see https://github.com/01org/intel-cmt-cat Known issues and limitations: - --l3ca must be a first app parameter --- MAINTAINERS | 4 + doc/guides/sample_app_ug/index.rst | 1 + doc/guides/sample_app_ug/l2_forward_cat.rst | 245 +++ examples/Makefile | 3 + examples/l2fwd-cat/Makefile | 70 ++ examples/l2fwd-cat/cat.c| 996 examples/l2fwd-cat/cat.h| 72 ++ examples/l2fwd-cat/l2fwd-cat.c | 224 +++ 8 files changed, 1615 insertions(+) create mode 100644 doc/guides/sample_app_ug/l2_forward_cat.rst create mode 100644 examples/l2fwd-cat/Makefile create mode 100644 examples/l2fwd-cat/cat.c create mode 100644 examples/l2fwd-cat/cat.h create mode 100644 examples/l2fwd-cat/l2fwd-cat.c diff --git a/MAINTAINERS b/MAINTAINERS index f10b26a..6d420f0 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -624,3 +624,7 @@ F: doc/guides/sample_app_ug/vmdq_dcb_forwarding.rst M: Pablo de Lara M: Daniel Mrzyglod F: examples/ptpclient/ + +M: Tomasz Kantecki +F: doc/guides/sample_app_ug/l2_forward_cat.rst +F: examples/l2wd-cat/ diff --git a/doc/guides/sample_app_ug/index.rst b/doc/guides/sample_app_ug/index.rst index 88375d2..eea6a45 100644 --- a/doc/guides/sample_app_ug/index.rst +++ b/doc/guides/sample_app_ug/index.rst @@ -49,6 +49,7 @@ Sample Applications User Guide keep_alive l2_forward_job_stats l2_forward_real_virtual +l2_forward_cat l3_forward l3_forward_power_man l3_forward_access_ctrl diff --git a/doc/guides/sample_app_ug/l2_forward_cat.rst b/doc/guides/sample_app_ug/l2_forward_cat.rst new file mode 100644 index 000..b6ab54d --- /dev/null +++ b/doc/guides/sample_app_ug/l2_forward_cat.rst @@ -0,0 +1,245 @@ +.. BSD LICENSE +Copyright(c) 2016 Intel Corporation. All rights reserved. +All rights reserved. + +Redistribution and use in source and binary forms, with or without +modification, are permitted provided that the following conditions +are met: + +* Redistributions of source code must retain the above copyright +notice, this list of conditions and the following disclaimer. +* Redistributions in binary form must reproduce the above copyright +notice, this list of conditions and the following disclaimer in +the documentation and/or other materials provided with the +distribution. +* Neither the name of Intel Corporation nor the names of its +contributors may be used to endorse or promote products derived +from this software without specific prior written permission. + +THIS SOFTWA
[dpdk-dev] [PATCH v2 1/5] mem: add --single-file to create single mem-backed file
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon > Sent: Tuesday, March 8, 2016 10:31 AM > To: dev at dpdk.org > Cc: nakajima.yoshihiro at lab.ntt.co.jp; mst at redhat.com; p.fedin at > samsung.com; > ann.zhuangyanying at huawei.com > Subject: Re: [dpdk-dev] [PATCH v2 1/5] mem: add --single-file to create > single mem-backed file > > 2016-03-08 17:04, Yuanhan Liu: > > On Tue, Mar 08, 2016 at 10:49:30AM +0200, Panu Matilainen wrote: > > > On 03/07/2016 03:13 PM, Yuanhan Liu wrote: > > > >To me, maybe you could base the SINGLE_FILE_SEGMENTS option, and add > > > >another option, say --no-sort (I confess this name sucks, but you get > > > >my point). With that, we could make sure to create as least huge page > > > >files as possible, to fit your case. > > > > > > Note that SINGLE_FILE_SEGMENTS is a nasty hack that only the IVSHMEM > config > > > uses, getting rid of it (by replacing with a runtime switch) would be > great. > > > > Can't agree more. > > +1 > > > BTW, FYI, Jianfeng and I had a private talk, and we came to agree that > > it might be better to handle it outside the normal huge page init stage, > > just like this patch does, but adding the support of multiple huge page > > sizes. Let's not add more messy code there. > > > > --yliu > > > > > OTOH IVSHMEM itself seems to have fallen out of the fashion since the > memnic > > > driver is unmaintained and broken since dpdk 2.0... CC'ing the IVSHMEM > > > maintainer in case he has thoughts on this. > > The ivshmem config was not used for memnic which was using ivshmem only for > data path. > CONFIG_RTE_LIBRTE_IVSHMEM and CONFIG_RTE_EAL_SINGLE_FILE_SEGMENTS are more > about full memory sharing. > I have the feeling it could be dropped. > It there are some users, I'd like to see a justification and a rework to > remove these build options. Just to clarify - is this suggesting the removal of the IVSHMEM library itself, or just some of the config options? The reason I ask is that although we don't currently use it in OVS with DPDK, I've seen at least one person using it in conjunction with the ring interface. There may be others, so I want to cross-post if there's a deprecation discussion. Kevin.
[dpdk-dev] [PATCH] virtio: fix wrong features returned for legacy virtio
On Mon, Mar 14, 2016 at 08:44:32PM +0800, Yuanhan Liu wrote:
> On Mon, Mar 14, 2016 at 10:48:31AM +, Bruce Richardson wrote:
> > On Thu, Mar 10, 2016 at 03:50:54PM +0800, Yuanhan Liu wrote:
> > > On Thu, Mar 10, 2016 at 08:43:37AM +0100, David Marchand wrote:
> > > > On Thu, Mar 10, 2016 at 8:01 AM, Yuanhan Liu
> > > > wrote:
> > > > > Declare dst as type uint32_t instead of uint64_t, otherwise, we will
> > > > > get
> > > > > a random upper 32 bit feature bits, as the following io port read
> > > > > reads
> > > > > lower 32 bit only. It could lead a feature bits that include
> > > > > VIRTIO_F_VERSION_1
> > > > > (the 32th bit) for legacy virtio, which is obviously wrong.
> > > > >
> > > > > Fixes: b8f04520ad71 ("virtio: use PCI ioport API")
> > > > >
> > > > > Cc: David Marchand
> > > > > Signed-off-by: Yuanhan Liu
> > > >
> > > > Argh, good catch.
> > > > Relooked at my patch, this should be the only bug (of this kind ;-)).
> > >
> > > Yes, I also have a check while making this patch.
> > >
> > > --yliu
> > > >
> > > > Reviewed-by: David Marchand
> > > >
> > > >
> > > > --
> > > > David Marchand
> > Hi,
> >
> > this patch no longer applies to dpdk-next-net/rel_16_04 branch due to
> > changes
> > in legacy_get_features function.
>
> Hi Bruce,
>
> It's a patch based on Thomas' tree. And this patch fixes an regression
> at there, too.
>
> --yliu
>
Ok, thanks for the info.
Thomas, I'm delegating this patch to you in patchwork to apply to your tree.
/Bruce
[dpdk-dev] [PATCH] ixgbe: avoid unnessary break when checking at the tail of rx hwring
When checking rx ring queue, it's possible that loop will break at the tail
while there are packets still in the queue header.
Signed-off-by: Jianbo Liu
---
drivers/net/ixgbe/ixgbe_rxtx_vec.c | 68 +-
1 file changed, 38 insertions(+), 30 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_rxtx_vec.c
b/drivers/net/ixgbe/ixgbe_rxtx_vec.c
index ccd93c7..611e431 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx_vec.c
+++ b/drivers/net/ixgbe/ixgbe_rxtx_vec.c
@@ -206,10 +206,9 @@ static inline uint16_t
_recv_raw_pkts_vec(struct ixgbe_rx_queue *rxq, struct rte_mbuf **rx_pkts,
uint16_t nb_pkts, uint8_t *split_packet)
{
- volatile union ixgbe_adv_rx_desc *rxdp;
+ volatile union ixgbe_adv_rx_desc *rxdp, *rxdp_end;
struct ixgbe_rx_entry *sw_ring;
- uint16_t nb_pkts_recd;
- int pos;
+ uint16_t rev;
uint64_t var;
__m128i shuf_msk;
__m128i crc_adjust = _mm_set_epi16(
@@ -232,6 +231,7 @@ _recv_raw_pkts_vec(struct ixgbe_rx_queue *rxq, struct
rte_mbuf **rx_pkts,
/* Just the act of getting into the function from the application is
* going to cost about 7 cycles */
rxdp = rxq->rx_ring + rxq->rx_tail;
+ rxdp_end = rxq->rx_ring + rxq->nb_rx_desc;
_mm_prefetch((const void *)rxdp, _MM_HINT_T0);
@@ -275,9 +275,7 @@ _recv_raw_pkts_vec(struct ixgbe_rx_queue *rxq, struct
rte_mbuf **rx_pkts,
* [C*. extract the end-of-packet bit, if requested]
* D. fill info. from desc to mbuf
*/
- for (pos = 0, nb_pkts_recd = 0; pos < nb_pkts;
- pos += RTE_IXGBE_DESCS_PER_LOOP,
- rxdp += RTE_IXGBE_DESCS_PER_LOOP) {
+ for (rev = 0; rev < nb_pkts; ) {
__m128i descs0[RTE_IXGBE_DESCS_PER_LOOP];
__m128i descs[RTE_IXGBE_DESCS_PER_LOOP];
__m128i pkt_mb1, pkt_mb2, pkt_mb3, pkt_mb4;
@@ -285,17 +283,17 @@ _recv_raw_pkts_vec(struct ixgbe_rx_queue *rxq, struct
rte_mbuf **rx_pkts,
__m128i mbp1, mbp2; /* two mbuf pointer in one XMM reg. */
/* B.1 load 1 mbuf point */
- mbp1 = _mm_loadu_si128((__m128i *)&sw_ring[pos]);
+ mbp1 = _mm_loadu_si128((__m128i *)&sw_ring[0]);
/* Read desc statuses backwards to avoid race condition */
/* A.1 load 4 pkts desc */
descs0[3] = _mm_loadu_si128((__m128i *)(rxdp + 3));
/* B.2 copy 2 mbuf point into rx_pkts */
- _mm_storeu_si128((__m128i *)&rx_pkts[pos], mbp1);
+ _mm_storeu_si128((__m128i *)&rx_pkts[rev], mbp1);
/* B.1 load 1 mbuf point */
- mbp2 = _mm_loadu_si128((__m128i *)&sw_ring[pos+2]);
+ mbp2 = _mm_loadu_si128((__m128i *)&sw_ring[2]);
descs0[2] = _mm_loadu_si128((__m128i *)(rxdp + 2));
/* B.1 load 2 mbuf point */
@@ -303,13 +301,13 @@ _recv_raw_pkts_vec(struct ixgbe_rx_queue *rxq, struct
rte_mbuf **rx_pkts,
descs0[0] = _mm_loadu_si128((__m128i *)(rxdp));
/* B.2 copy 2 mbuf point into rx_pkts */
- _mm_storeu_si128((__m128i *)&rx_pkts[pos+2], mbp2);
+ _mm_storeu_si128((__m128i *)&rx_pkts[rev + 2], mbp2);
if (split_packet) {
- rte_prefetch0(&rx_pkts[pos]->cacheline1);
- rte_prefetch0(&rx_pkts[pos + 1]->cacheline1);
- rte_prefetch0(&rx_pkts[pos + 2]->cacheline1);
- rte_prefetch0(&rx_pkts[pos + 3]->cacheline1);
+ rte_prefetch0(&rx_pkts[rev]->cacheline1);
+ rte_prefetch0(&rx_pkts[rev + 1]->cacheline1);
+ rte_prefetch0(&rx_pkts[rev + 2]->cacheline1);
+ rte_prefetch0(&rx_pkts[rev + 3]->cacheline1);
}
/* A* mask out 0~3 bits RSS type */
@@ -333,7 +331,7 @@ _recv_raw_pkts_vec(struct ixgbe_rx_queue *rxq, struct
rte_mbuf **rx_pkts,
sterr_tmp1 = _mm_unpackhi_epi32(descs[1], descs[0]);
/* set ol_flags with vlan packet type */
- desc_to_olflags_v(descs0, &rx_pkts[pos]);
+ desc_to_olflags_v(descs0, &rx_pkts[rev]);
/* D.2 pkt 3,4 set in_port/nb_seg and remove crc */
pkt_mb4 = _mm_add_epi16(pkt_mb4, crc_adjust);
@@ -348,9 +346,9 @@ _recv_raw_pkts_vec(struct ixgbe_rx_queue *rxq, struct
rte_mbuf **rx_pkts,
staterr = _mm_unpacklo_epi32(sterr_tmp1, sterr_tmp2);
/* D.3 copy final 3,4 data to rx_pkts */
- _mm_storeu_si128((void *)&rx_pkts[pos+3]->rx_descriptor_fields1,
+ _mm_storeu_si128((void *)&rx_pkts[rev+3]->rx_descriptor_fields1,
pkt_mb4);
- _mm_storeu_si128((void *)&rx_pkts[pos+2]->rx_descriptor_fields1,
+ _mm_storeu_si128((void *)&rx_p
[dpdk-dev] [PATCH 0/3] sched: patches for 2.2
> -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Sunday, March 13, 2016 11:09 PM > To: Dumitrescu, Cristian ; Stephen > Hemminger > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH 0/3] sched: patches for 2.2 > > 2016-03-13 22:47, Dumitrescu, Cristian: > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > > 2016-03-08 07:49, Dumitrescu, Cristian: > > > > Regarding Stephen's patches, I think there is a pending issue regarding > the > > > legal side of the Copyright, which is attributed to Intel, although > Stephen's > > > code is relicensed with BSD license by permission from the original code > > > author (which also submitted the code to Linux kernel under GPL). This > was > > > already flagged. This is a legal issue and I do not feel comfortable with > ack-ing > > > this patch until the legal resolution on this is crystal clear. > > > > > > > > I also think the new files called rte_reciprocal.[hc] implement an > algorithm > > > that is very generic and totally independent of the QoS code, therefore it > > > should be placed into a different folder that is globally visible to other > > > libraries (librte_eal/common ?) just in case other usages for this > > > algorithm > > > are identified in the future. I suggest we break the patch into two > separate > > > patches submitted independently: one introducing the > rte_reciprocal.[hc] > > > algorithm to librte_eal/common and the second containing just the > > > librte_sched changes, which are small. I am thinking ahead here: once we > > > have the 2x64-bit multiplication solution in place, we should not have > > > rte_reciprocal.[hc] hanging in librte_sched folder without being used > here, > > > while it might be used by other parts of DPDK. > > > > > > Let's keep the improvement as-is to test it in the first release > > > candidate. > > > We can move the code and/or fix the file header later. > > > > > > Series applied, thanks. > > > > Hi Thomas, > > > > I am OK with this, as long as Stephen commits to fix the copyright in the > > header file > > There is no copyright issue. Just an Intel mention in the disclaimer. Thanks, Thomas, for confirming this. My knowledge on copyright issues is limited, so I was not sure whether this is an issue or not. > > > and move the rte_reciprocal.[hc] into a common area like > > librte_eal/common in time for the next release candidate. > > If it is moved as a public API, it must be better documented. > If it stay here, it must be removed from SYMLINK-y-include. My vote would go for making this a public API, moving it to a common place (like librte_eal/common) and better documenting it. I already see other libraries that would benefit from a faster implementation of division (e.g. librte_meter), there are probably others as well. I'd like to get Stephen's opinion on this.
[dpdk-dev] [PATCH v8 00/11] Add API to get supported packet types
To achieve this, a new function pointer, dev_supported_ptypes_get, is added into struct eth_dev_ops. For those devices who do not implement it, it means it does not support any ptypes. v8: - Rebased on dpdk-next-net/rel_16_04 branch. - Rename ptypes_info -> supported_ptypes. - Abandon info about newly added API in release_16_04.rst. - concise -> correct. v7: - 2.2 -> 16.04 - Add note: this API better invoked after device is already started. - Update release_16_04.rst for newly added API. v6: - Remove extern in function declaration. - Update rte_ether_version.map. v5: - Exclude l3fwd change from this series, as a separated one. - Fix malposition of mlx4 code in mlx5 commit introduced in v4. v4: - Change how to use this API: to previously agreement reached in mail. v3: - Change how to use this API: api to allocate mem for storing ptype array; and caller to free the mem. - Change how to return back ptypes from PMDs: return a pointer to corresponding static const array of supported ptypes, terminated by RTE_PTYPE_UNKNOWN. - Fix l3fwd parse_packet_type() when EXACT_MATCH is enabled. - Fix l3fwd memory leak when calling the API. v2: - Move ptype_mask filter function from each PMDs into ether layer. - Add ixgbe vPMD's ptype info. - Fix code style issues. Signed-off-by: Jianfeng Tan Acked-by: Konstantin Ananyev Acked-by: Adrien Mazarguil Jianfeng Tan (11): ethdev: add API to query supported packet types cxgbe: add dev_supported_ptypes_get implementation e1000: add dev_supported_ptypes_get implementation enic: add dev_supported_ptypes_get implementation fm10k: add dev_supported_ptypes_get implementation i40e: add dev_supported_ptypes_get implementation ixgbe: add dev_supported_ptypes_get implementation mlx4: add dev_supported_ptypes_get implementation mlx5: add dev_supported_ptypes_get implementation nfp: add dev_supported_ptypes_get implementation vmxnet3: add dev_supported_ptypes_get implementation drivers/net/cxgbe/cxgbe_ethdev.c | 15 ++ drivers/net/e1000/igb_ethdev.c | 30 drivers/net/enic/enic_ethdev.c | 14 ++ drivers/net/fm10k/fm10k_ethdev.c | 50 ++ drivers/net/fm10k/fm10k_rxtx.c | 3 ++ drivers/net/fm10k/fm10k_rxtx_vec.c | 3 ++ drivers/net/i40e/i40e_ethdev.c | 1 + drivers/net/i40e/i40e_ethdev_vf.c | 1 + drivers/net/i40e/i40e_rxtx.c | 46 ++- drivers/net/i40e/i40e_rxtx.h | 1 + drivers/net/ixgbe/ixgbe_ethdev.c | 38 ++ drivers/net/ixgbe/ixgbe_ethdev.h | 3 ++ drivers/net/ixgbe/ixgbe_rxtx.c | 4 ++- drivers/net/mlx4/mlx4.c| 21 ++ drivers/net/mlx5/mlx5.c| 1 + drivers/net/mlx5/mlx5.h| 1 + drivers/net/mlx5/mlx5_ethdev.c | 20 ++ drivers/net/mlx5/mlx5_rxtx.c | 2 ++ drivers/net/nfp/nfp_net.c | 19 + drivers/net/vmxnet3/vmxnet3_ethdev.c | 17 lib/librte_ether/rte_ethdev.c | 27 ++ lib/librte_ether/rte_ethdev.h | 27 ++ lib/librte_ether/rte_ether_version.map | 5 23 files changed, 347 insertions(+), 2 deletions(-) -- 2.1.4
[dpdk-dev] [PATCH v8 01/11] ethdev: add API to query supported packet types
Add a new API rte_eth_dev_get_supported_ptypes to query what packet types
can be filled by given already started device (or its pmd rx burst function
has already been decided).
Signed-off-by: Jianfeng Tan
Acked-by: Konstantin Ananyev
Acked-by: Adrien Mazarguil
---
lib/librte_ether/rte_ethdev.c | 27 +++
lib/librte_ether/rte_ethdev.h | 27 +++
lib/librte_ether/rte_ether_version.map | 5 +
3 files changed, 59 insertions(+)
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index a6e83c1..52fb62c 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -1616,6 +1616,33 @@ rte_eth_dev_info_get(uint8_t port_id, struct
rte_eth_dev_info *dev_info)
dev_info->driver_name = dev->data->drv_name;
}
+int
+rte_eth_dev_get_supported_ptypes(uint8_t port_id, uint32_t ptype_mask,
+uint32_t *ptypes, int num)
+{
+ int i, j;
+ struct rte_eth_dev *dev;
+ const uint32_t *all_ptypes;
+
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+ dev = &rte_eth_devices[port_id];
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_supported_ptypes_get,
+ -ENOTSUP);
+ all_ptypes = (*dev->dev_ops->dev_supported_ptypes_get)(dev);
+
+ if (!all_ptypes)
+ return 0;
+
+ for (i = 0, j = 0; all_ptypes[i] != RTE_PTYPE_UNKNOWN; ++i)
+ if (all_ptypes[i] & ptype_mask) {
+ if (j < num)
+ ptypes[j] = all_ptypes[i];
+ j++;
+ }
+
+ return j;
+}
+
void
rte_eth_macaddr_get(uint8_t port_id, struct ether_addr *mac_addr)
{
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index e2893ba..7770f24 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -1021,6 +1021,9 @@ typedef void (*eth_dev_infos_get_t)(struct rte_eth_dev
*dev,
struct rte_eth_dev_info *dev_info);
/**< @internal Get specific informations of an Ethernet device. */
+typedef const uint32_t *(*eth_dev_supported_ptypes_get_t)(struct rte_eth_dev
*dev);
+/**< @internal Get supported ptypes of an Ethernet device. */
+
typedef int (*eth_queue_start_t)(struct rte_eth_dev *dev,
uint16_t queue_id);
/**< @internal Start rx and tx of a queue of an Ethernet device. */
@@ -1347,6 +1350,7 @@ struct eth_dev_ops {
eth_queue_stats_mapping_set_t queue_stats_mapping_set;
/**< Configure per queue stat counter mapping. */
eth_dev_infos_get_tdev_infos_get; /**< Get device info. */
+ eth_dev_supported_ptypes_get_t dev_supported_ptypes_get; /** Get
supported ptypes */
mtu_set_t mtu_set; /**< Set MTU. */
vlan_filter_set_t vlan_filter_set; /**< Filter VLAN Setup. */
vlan_tpid_set_tvlan_tpid_set; /**< Outer VLAN TPID
Setup. */
@@ -2270,6 +2274,29 @@ void rte_eth_macaddr_get(uint8_t port_id, struct
ether_addr *mac_addr);
void rte_eth_dev_info_get(uint8_t port_id, struct rte_eth_dev_info *dev_info);
/**
+ * Retrieve the supported packet types of an Ethernet device.
+ *
+ * @note
+ * Better to invoke this API after the device is already started or rx burst
+ * function is decided, to obtain correct supported ptypes.
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param ptype_mask
+ * A hint of what kind of packet type which the caller is interested in.
+ * @param ptypes
+ * An array pointer to store adequent packet types, allocated by caller.
+ * @param num
+ * Size of the array pointed by param ptypes.
+ * @return
+ * - (>0) Number of supported ptypes. If it exceeds param num, exceeding
+ * packet types will not be filled in the given array.
+ * - (0 or -ENOTSUP) if PMD does not fill the specified ptype.
+ * - (-ENODEV) if *port_id* invalid.
+ */
+int rte_eth_dev_get_supported_ptypes(uint8_t port_id, uint32_t ptype_mask,
+uint32_t *ptypes, int num);
+
+/**
* Retrieve the MTU of an Ethernet device.
*
* @param port_id
diff --git a/lib/librte_ether/rte_ether_version.map
b/lib/librte_ether/rte_ether_version.map
index d8db24d..0f00dcb 100644
--- a/lib/librte_ether/rte_ether_version.map
+++ b/lib/librte_ether/rte_ether_version.map
@@ -117,3 +117,8 @@ DPDK_2.2 {
local: *;
};
+DPDK_16.04 {
+ rte_eth_dev_get_supported_ptypes;
+
+ local: *;
+} DPDK_2.2;
--
2.1.4
[dpdk-dev] [PATCH v8 02/11] cxgbe: add dev_supported_ptypes_get implementation
Signed-off-by: Jianfeng Tan
Acked-by: Konstantin Ananyev
Acked-by: Adrien Mazarguil
---
drivers/net/cxgbe/cxgbe_ethdev.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/net/cxgbe/cxgbe_ethdev.c b/drivers/net/cxgbe/cxgbe_ethdev.c
index 8c6dd59..1ee80b0 100644
--- a/drivers/net/cxgbe/cxgbe_ethdev.c
+++ b/drivers/net/cxgbe/cxgbe_ethdev.c
@@ -767,6 +767,20 @@ static int cxgbe_flow_ctrl_set(struct rte_eth_dev *eth_dev,
&pi->link_cfg);
}
+static const uint32_t *
+cxgbe_dev_supported_ptypes_get(struct rte_eth_dev *eth_dev)
+{
+ static const uint32_t ptypes[] = {
+ RTE_PTYPE_L3_IPV4,
+ RTE_PTYPE_L3_IPV6,
+ RTE_PTYPE_UNKNOWN
+ };
+
+ if (eth_dev->rx_pkt_burst == cxgbe_recv_pkts)
+ return ptypes;
+ return NULL;
+}
+
static struct eth_dev_ops cxgbe_eth_dev_ops = {
.dev_start = cxgbe_dev_start,
.dev_stop = cxgbe_dev_stop,
@@ -777,6 +791,7 @@ static struct eth_dev_ops cxgbe_eth_dev_ops = {
.allmulticast_disable = cxgbe_dev_allmulticast_disable,
.dev_configure = cxgbe_dev_configure,
.dev_infos_get = cxgbe_dev_info_get,
+ .dev_supported_ptypes_get = cxgbe_dev_supported_ptypes_get,
.link_update= cxgbe_dev_link_update,
.mtu_set= cxgbe_dev_mtu_set,
.tx_queue_setup = cxgbe_dev_tx_queue_setup,
--
2.1.4
[dpdk-dev] [PATCH v8 03/11] e1000: add dev_supported_ptypes_get implementation
Signed-off-by: Jianfeng Tan
Acked-by: Konstantin Ananyev
Acked-by: Adrien Mazarguil
---
drivers/net/e1000/igb_ethdev.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index f889876..413c794 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -104,6 +104,7 @@ static void eth_igb_stats_reset(struct rte_eth_dev *dev);
static void eth_igb_xstats_reset(struct rte_eth_dev *dev);
static void eth_igb_infos_get(struct rte_eth_dev *dev,
struct rte_eth_dev_info *dev_info);
+static const uint32_t *eth_igb_supported_ptypes_get(struct rte_eth_dev *dev);
static void eth_igbvf_infos_get(struct rte_eth_dev *dev,
struct rte_eth_dev_info *dev_info);
static int eth_igb_flow_ctrl_get(struct rte_eth_dev *dev,
@@ -324,6 +325,7 @@ static const struct eth_dev_ops eth_igb_ops = {
.stats_reset = eth_igb_stats_reset,
.xstats_reset = eth_igb_xstats_reset,
.dev_infos_get= eth_igb_infos_get,
+ .dev_supported_ptypes_get = eth_igb_supported_ptypes_get,
.mtu_set = eth_igb_mtu_set,
.vlan_filter_set = eth_igb_vlan_filter_set,
.vlan_tpid_set= eth_igb_vlan_tpid_set,
@@ -385,6 +387,7 @@ static const struct eth_dev_ops igbvf_eth_dev_ops = {
.xstats_reset = eth_igbvf_stats_reset,
.vlan_filter_set = igbvf_vlan_filter_set,
.dev_infos_get= eth_igbvf_infos_get,
+ .dev_supported_ptypes_get = eth_igb_supported_ptypes_get,
.rx_queue_setup = eth_igb_rx_queue_setup,
.rx_queue_release = eth_igb_rx_queue_release,
.tx_queue_setup = eth_igb_tx_queue_setup,
@@ -1919,6 +1922,33 @@ eth_igb_infos_get(struct rte_eth_dev *dev, struct
rte_eth_dev_info *dev_info)
dev_info->tx_desc_lim = tx_desc_lim;
}
+static const uint32_t *
+eth_igb_supported_ptypes_get(struct rte_eth_dev *dev)
+{
+ static const uint32_t ptypes[] = {
+ /* refers to igb_rxd_pkt_info_to_pkt_type() */
+ RTE_PTYPE_L2_ETHER,
+ RTE_PTYPE_L3_IPV4,
+ RTE_PTYPE_L3_IPV4_EXT,
+ RTE_PTYPE_L3_IPV6,
+ RTE_PTYPE_L3_IPV6_EXT,
+ RTE_PTYPE_L4_TCP,
+ RTE_PTYPE_L4_UDP,
+ RTE_PTYPE_L4_SCTP,
+ RTE_PTYPE_TUNNEL_IP,
+ RTE_PTYPE_INNER_L3_IPV6,
+ RTE_PTYPE_INNER_L3_IPV6_EXT,
+ RTE_PTYPE_INNER_L4_TCP,
+ RTE_PTYPE_INNER_L4_UDP,
+ RTE_PTYPE_UNKNOWN
+ };
+
+ if (dev->rx_pkt_burst == eth_igb_recv_pkts ||
+ dev->rx_pkt_burst == eth_igb_recv_scattered_pkts)
+ return ptypes;
+ return NULL;
+}
+
static void
eth_igbvf_infos_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
{
--
2.1.4
[dpdk-dev] [PATCH v8 04/11] enic: add dev_supported_ptypes_get implementation
Signed-off-by: Jianfeng Tan
Acked-by: Konstantin Ananyev
Acked-by: Adrien Mazarguil
---
drivers/net/enic/enic_ethdev.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/net/enic/enic_ethdev.c b/drivers/net/enic/enic_ethdev.c
index 6f2ada5..bab0f7d 100644
--- a/drivers/net/enic/enic_ethdev.c
+++ b/drivers/net/enic/enic_ethdev.c
@@ -438,6 +438,19 @@ static void enicpmd_dev_info_get(struct rte_eth_dev
*eth_dev,
};
}
+static const uint32_t *enicpmd_dev_supported_ptypes_get(struct rte_eth_dev
*dev)
+{
+ static const uint32_t ptypes[] = {
+ RTE_PTYPE_L3_IPV4,
+ RTE_PTYPE_L3_IPV6,
+ RTE_PTYPE_UNKNOWN
+ };
+
+ if (dev->rx_pkt_burst == enic_recv_pkts)
+ return ptypes;
+ return NULL;
+}
+
static void enicpmd_dev_promiscuous_enable(struct rte_eth_dev *eth_dev)
{
struct enic *enic = pmd_priv(eth_dev);
@@ -561,6 +574,7 @@ static const struct eth_dev_ops enicpmd_eth_dev_ops = {
.stats_reset = enicpmd_dev_stats_reset,
.queue_stats_mapping_set = NULL,
.dev_infos_get= enicpmd_dev_info_get,
+ .dev_supported_ptypes_get = enicpmd_dev_supported_ptypes_get,
.mtu_set = NULL,
.vlan_filter_set = enicpmd_vlan_filter_set,
.vlan_tpid_set= NULL,
--
2.1.4
[dpdk-dev] [PATCH v8 05/11] fm10k: add dev_supported_ptypes_get implementation
Signed-off-by: Jianfeng Tan
Acked-by: Konstantin Ananyev
Acked-by: Adrien Mazarguil
---
drivers/net/fm10k/fm10k_ethdev.c | 50 ++
drivers/net/fm10k/fm10k_rxtx.c | 3 +++
drivers/net/fm10k/fm10k_rxtx_vec.c | 3 +++
3 files changed, 56 insertions(+)
diff --git a/drivers/net/fm10k/fm10k_ethdev.c b/drivers/net/fm10k/fm10k_ethdev.c
index 4b07a8b..b510487 100644
--- a/drivers/net/fm10k/fm10k_ethdev.c
+++ b/drivers/net/fm10k/fm10k_ethdev.c
@@ -1412,6 +1412,55 @@ fm10k_dev_infos_get(struct rte_eth_dev *dev,
};
}
+#ifdef RTE_LIBRTE_FM10K_RX_OLFLAGS_ENABLE
+static const uint32_t *
+fm10k_dev_supported_ptypes_get(struct rte_eth_dev *dev)
+{
+ if (dev->rx_pkt_burst == fm10k_recv_pkts ||
+ dev->rx_pkt_burst == fm10k_recv_scattered_pkts) {
+ static uint32_t ptypes[] = {
+ /* refers to rx_desc_to_ol_flags() */
+ RTE_PTYPE_L2_ETHER,
+ RTE_PTYPE_L3_IPV4,
+ RTE_PTYPE_L3_IPV4_EXT,
+ RTE_PTYPE_L3_IPV6,
+ RTE_PTYPE_L3_IPV6_EXT,
+ RTE_PTYPE_L4_TCP,
+ RTE_PTYPE_L4_UDP,
+ RTE_PTYPE_UNKNOWN
+ };
+
+ return ptypes;
+ } else if (dev->rx_pkt_burst == fm10k_recv_pkts_vec ||
+ dev->rx_pkt_burst == fm10k_recv_scattered_pkts_vec) {
+ static uint32_t ptypes_vec[] = {
+ /* refers to fm10k_desc_to_pktype_v() */
+ RTE_PTYPE_L3_IPV4,
+ RTE_PTYPE_L3_IPV4_EXT,
+ RTE_PTYPE_L3_IPV6,
+ RTE_PTYPE_L3_IPV6_EXT,
+ RTE_PTYPE_L4_TCP,
+ RTE_PTYPE_L4_UDP,
+ RTE_PTYPE_TUNNEL_GENEVE,
+ RTE_PTYPE_TUNNEL_NVGRE,
+ RTE_PTYPE_TUNNEL_VXLAN,
+ RTE_PTYPE_TUNNEL_GRE,
+ RTE_PTYPE_UNKNOWN
+ };
+
+ return ptypes_vec;
+ }
+
+ return NULL;
+}
+#else
+static const uint32_t *
+fm10k_dev_supported_ptypes_get(struct rte_eth_dev *dev __rte_unused)
+{
+ return NULL;
+}
+#endif
+
static int
fm10k_vlan_filter_set(struct rte_eth_dev *dev, uint16_t vlan_id, int on)
{
@@ -2578,6 +2627,7 @@ static const struct eth_dev_ops fm10k_eth_dev_ops = {
.xstats_reset = fm10k_stats_reset,
.link_update= fm10k_link_update,
.dev_infos_get = fm10k_dev_infos_get,
+ .dev_supported_ptypes_get = fm10k_dev_supported_ptypes_get,
.vlan_filter_set= fm10k_vlan_filter_set,
.vlan_offload_set = fm10k_vlan_offload_set,
.mac_addr_add = fm10k_macaddr_add,
diff --git a/drivers/net/fm10k/fm10k_rxtx.c b/drivers/net/fm10k/fm10k_rxtx.c
index 66db5b6..81ed4e7 100644
--- a/drivers/net/fm10k/fm10k_rxtx.c
+++ b/drivers/net/fm10k/fm10k_rxtx.c
@@ -65,6 +65,9 @@ static inline void dump_rxd(union fm10k_rx_desc *rxd)
}
#endif
+/* @note: When this function is changed, make corresponding change to
+ * fm10k_dev_supported_ptypes_get()
+ */
static inline void
rx_desc_to_ol_flags(struct rte_mbuf *m, const union fm10k_rx_desc *d)
{
diff --git a/drivers/net/fm10k/fm10k_rxtx_vec.c
b/drivers/net/fm10k/fm10k_rxtx_vec.c
index 1c78725..f8efe8f 100644
--- a/drivers/net/fm10k/fm10k_rxtx_vec.c
+++ b/drivers/net/fm10k/fm10k_rxtx_vec.c
@@ -149,6 +149,9 @@ fm10k_desc_to_olflags_v(__m128i descs[4], struct rte_mbuf
**rx_pkts)
rx_pkts[3]->ol_flags = vol.e[3];
}
+/* @note: When this function is changed, make corresponding change to
+ * fm10k_dev_supported_ptypes_get().
+ */
static inline void
fm10k_desc_to_pktype_v(__m128i descs[4], struct rte_mbuf **rx_pkts)
{
--
2.1.4
[dpdk-dev] [PATCH v8 06/11] i40e: add dev_supported_ptypes_get implementation
Signed-off-by: Jianfeng Tan
Acked-by: Konstantin Ananyev
Acked-by: Adrien Mazarguil
---
drivers/net/i40e/i40e_ethdev.c| 1 +
drivers/net/i40e/i40e_ethdev_vf.c | 1 +
drivers/net/i40e/i40e_rxtx.c | 46 ++-
drivers/net/i40e/i40e_rxtx.h | 1 +
4 files changed, 48 insertions(+), 1 deletion(-)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index b05d9cd..81f1104 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -443,6 +443,7 @@ static const struct eth_dev_ops i40e_eth_dev_ops = {
.xstats_reset = i40e_dev_stats_reset,
.queue_stats_mapping_set = i40e_dev_queue_stats_mapping_set,
.dev_infos_get= i40e_dev_info_get,
+ .dev_supported_ptypes_get = i40e_dev_supported_ptypes_get,
.vlan_filter_set = i40e_vlan_filter_set,
.vlan_tpid_set= i40e_vlan_tpid_set,
.vlan_offload_set = i40e_vlan_offload_set,
diff --git a/drivers/net/i40e/i40e_ethdev_vf.c
b/drivers/net/i40e/i40e_ethdev_vf.c
index 6b7b350..510191e 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -201,6 +201,7 @@ static const struct eth_dev_ops i40evf_eth_dev_ops = {
.xstats_reset = i40evf_dev_xstats_reset,
.dev_close= i40evf_dev_close,
.dev_infos_get= i40evf_dev_info_get,
+ .dev_supported_ptypes_get = i40e_dev_supported_ptypes_get,
.vlan_filter_set = i40evf_vlan_filter_set,
.vlan_offload_set = i40evf_vlan_offload_set,
.vlan_pvid_set= i40evf_vlan_pvid_set,
diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
index f8efdce..8a260c5 100644
--- a/drivers/net/i40e/i40e_rxtx.c
+++ b/drivers/net/i40e/i40e_rxtx.c
@@ -194,7 +194,10 @@ i40e_get_iee15888_flags(struct rte_mbuf *mb, uint64_t
qword)
}
#endif
-/* For each value it means, datasheet of hardware can tell more details */
+/* For each value it means, datasheet of hardware can tell more details
+ *
+ * @note: fix i40e_dev_supported_ptypes_get() if any change here.
+ */
static inline uint32_t
i40e_rxd_pkt_type_mapping(uint8_t ptype)
{
@@ -2093,6 +2096,47 @@ i40e_dev_tx_queue_stop(struct rte_eth_dev *dev, uint16_t
tx_queue_id)
return 0;
}
+const uint32_t *
+i40e_dev_supported_ptypes_get(struct rte_eth_dev *dev)
+{
+ static const uint32_t ptypes[] = {
+ /* refers to i40e_rxd_pkt_type_mapping() */
+ RTE_PTYPE_L2_ETHER,
+ RTE_PTYPE_L2_ETHER_TIMESYNC,
+ RTE_PTYPE_L2_ETHER_LLDP,
+ RTE_PTYPE_L2_ETHER_ARP,
+ RTE_PTYPE_L3_IPV4_EXT_UNKNOWN,
+ RTE_PTYPE_L3_IPV6_EXT_UNKNOWN,
+ RTE_PTYPE_L4_FRAG,
+ RTE_PTYPE_L4_ICMP,
+ RTE_PTYPE_L4_NONFRAG,
+ RTE_PTYPE_L4_SCTP,
+ RTE_PTYPE_L4_TCP,
+ RTE_PTYPE_L4_UDP,
+ RTE_PTYPE_TUNNEL_GRENAT,
+ RTE_PTYPE_TUNNEL_IP,
+ RTE_PTYPE_INNER_L2_ETHER,
+ RTE_PTYPE_INNER_L2_ETHER_VLAN,
+ RTE_PTYPE_INNER_L3_IPV4_EXT_UNKNOWN,
+ RTE_PTYPE_INNER_L3_IPV6_EXT_UNKNOWN,
+ RTE_PTYPE_INNER_L4_FRAG,
+ RTE_PTYPE_INNER_L4_ICMP,
+ RTE_PTYPE_INNER_L4_NONFRAG,
+ RTE_PTYPE_INNER_L4_SCTP,
+ RTE_PTYPE_INNER_L4_TCP,
+ RTE_PTYPE_INNER_L4_UDP,
+ RTE_PTYPE_UNKNOWN
+ };
+
+ if (dev->rx_pkt_burst == i40e_recv_pkts ||
+#ifdef RTE_LIBRTE_I40E_RX_ALLOW_BULK_ALLOC
+ dev->rx_pkt_burst == i40e_recv_pkts_bulk_alloc ||
+#endif
+ dev->rx_pkt_burst == i40e_recv_scattered_pkts)
+ return ptypes;
+ return NULL;
+}
+
int
i40e_dev_rx_queue_setup(struct rte_eth_dev *dev,
uint16_t queue_idx,
diff --git a/drivers/net/i40e/i40e_rxtx.h b/drivers/net/i40e/i40e_rxtx.h
index 5c2f5c2..98179f0 100644
--- a/drivers/net/i40e/i40e_rxtx.h
+++ b/drivers/net/i40e/i40e_rxtx.h
@@ -200,6 +200,7 @@ int i40e_dev_rx_queue_start(struct rte_eth_dev *dev,
uint16_t rx_queue_id);
int i40e_dev_rx_queue_stop(struct rte_eth_dev *dev, uint16_t rx_queue_id);
int i40e_dev_tx_queue_start(struct rte_eth_dev *dev, uint16_t tx_queue_id);
int i40e_dev_tx_queue_stop(struct rte_eth_dev *dev, uint16_t tx_queue_id);
+const uint32_t *i40e_dev_supported_ptypes_get(struct rte_eth_dev *dev);
int i40e_dev_rx_queue_setup(struct rte_eth_dev *dev,
uint16_t queue_idx,
uint16_t nb_desc,
--
2.1.4
[dpdk-dev] [PATCH v8 07/11] ixgbe: add dev_supported_ptypes_get implementation
Signed-off-by: Jianfeng Tan
Acked-by: Konstantin Ananyev
Acked-by: Adrien Mazarguil
---
drivers/net/ixgbe/ixgbe_ethdev.c | 38 ++
drivers/net/ixgbe/ixgbe_ethdev.h | 3 +++
drivers/net/ixgbe/ixgbe_rxtx.c | 4 +++-
3 files changed, 44 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index afe6582..7a3b3aa 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -172,6 +172,7 @@ static int ixgbe_dev_queue_stats_mapping_set(struct
rte_eth_dev *eth_dev,
uint8_t is_rx);
static void ixgbe_dev_info_get(struct rte_eth_dev *dev,
struct rte_eth_dev_info *dev_info);
+static const uint32_t *ixgbe_dev_supported_ptypes_get(struct rte_eth_dev *dev);
static void ixgbevf_dev_info_get(struct rte_eth_dev *dev,
struct rte_eth_dev_info *dev_info);
static int ixgbe_dev_mtu_set(struct rte_eth_dev *dev, uint16_t mtu);
@@ -436,6 +437,7 @@ static const struct eth_dev_ops ixgbe_eth_dev_ops = {
.xstats_reset = ixgbe_dev_xstats_reset,
.queue_stats_mapping_set = ixgbe_dev_queue_stats_mapping_set,
.dev_infos_get= ixgbe_dev_info_get,
+ .dev_supported_ptypes_get = ixgbe_dev_supported_ptypes_get,
.mtu_set = ixgbe_dev_mtu_set,
.vlan_filter_set = ixgbe_vlan_filter_set,
.vlan_tpid_set= ixgbe_vlan_tpid_set,
@@ -522,6 +524,7 @@ static const struct eth_dev_ops ixgbevf_eth_dev_ops = {
.allmulticast_enable = ixgbevf_dev_allmulticast_enable,
.allmulticast_disable = ixgbevf_dev_allmulticast_disable,
.dev_infos_get= ixgbevf_dev_info_get,
+ .dev_supported_ptypes_get = ixgbe_dev_supported_ptypes_get,
.mtu_set = ixgbevf_dev_set_mtu,
.vlan_filter_set = ixgbevf_vlan_filter_set,
.vlan_strip_queue_set = ixgbevf_vlan_strip_queue_set,
@@ -2867,6 +2870,41 @@ ixgbe_dev_info_get(struct rte_eth_dev *dev, struct
rte_eth_dev_info *dev_info)
dev_info->flow_type_rss_offloads = IXGBE_RSS_OFFLOAD_ALL;
}
+static const uint32_t *
+ixgbe_dev_supported_ptypes_get(struct rte_eth_dev *dev)
+{
+ static const uint32_t ptypes[] = {
+ /* For non-vec functions,
+* refers to ixgbe_rxd_pkt_info_to_pkt_type();
+* for vec functions,
+* refers to _recv_raw_pkts_vec().
+*/
+ RTE_PTYPE_L2_ETHER,
+ RTE_PTYPE_L3_IPV4,
+ RTE_PTYPE_L3_IPV4_EXT,
+ RTE_PTYPE_L3_IPV6,
+ RTE_PTYPE_L3_IPV6_EXT,
+ RTE_PTYPE_L4_SCTP,
+ RTE_PTYPE_L4_TCP,
+ RTE_PTYPE_L4_UDP,
+ RTE_PTYPE_TUNNEL_IP,
+ RTE_PTYPE_INNER_L3_IPV6,
+ RTE_PTYPE_INNER_L3_IPV6_EXT,
+ RTE_PTYPE_INNER_L4_TCP,
+ RTE_PTYPE_INNER_L4_UDP,
+ RTE_PTYPE_UNKNOWN
+ };
+
+ if (dev->rx_pkt_burst == ixgbe_recv_pkts ||
+ dev->rx_pkt_burst == ixgbe_recv_pkts_lro_single_alloc ||
+ dev->rx_pkt_burst == ixgbe_recv_pkts_lro_bulk_alloc ||
+ dev->rx_pkt_burst == ixgbe_recv_pkts_bulk_alloc ||
+ dev->rx_pkt_burst == ixgbe_recv_pkts_vec ||
+ dev->rx_pkt_burst == ixgbe_recv_scattered_pkts_vec)
+ return ptypes;
+ return NULL;
+}
+
static void
ixgbevf_dev_info_get(struct rte_eth_dev *dev,
struct rte_eth_dev_info *dev_info)
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.h b/drivers/net/ixgbe/ixgbe_ethdev.h
index 5c3aa16..b75e795 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.h
+++ b/drivers/net/ixgbe/ixgbe_ethdev.h
@@ -380,6 +380,9 @@ void ixgbevf_dev_rxtx_start(struct rte_eth_dev *dev);
uint16_t ixgbe_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts,
uint16_t nb_pkts);
+uint16_t ixgbe_recv_pkts_bulk_alloc(void *rx_queue, struct rte_mbuf **rx_pkts,
+ uint16_t nb_pkts);
+
uint16_t ixgbe_recv_pkts_lro_single_alloc(void *rx_queue,
struct rte_mbuf **rx_pkts, uint16_t nb_pkts);
uint16_t ixgbe_recv_pkts_lro_bulk_alloc(void *rx_queue,
diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
index fd98f62..655fa05 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx.c
+++ b/drivers/net/ixgbe/ixgbe_rxtx.c
@@ -907,6 +907,8 @@ end_of_tx:
#define IXGBE_PACKET_TYPE_MAX 0X80
#define IXGBE_PACKET_TYPE_MASK 0X7F
#define IXGBE_PACKET_TYPE_SHIFT 0X04
+
+/* @note: fix ixgbe_dev_supported_ptypes_get() if any change here. */
static inline uint32_t
ixgbe_rxd_pkt_info_to_pkt_type(uint16_t pkt_info)
{
@@ -1255,7 +1257,7 @@ rx_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts,
}
/* split requests into chunks of size RTE_PMD_IXGBE_RX_MAX_BURST */
-static uint16_t
+uin
[dpdk-dev] [PATCH v8 08/11] mlx4: add dev_supported_ptypes_get implementation
Signed-off-by: Jianfeng Tan
Acked-by: Konstantin Ananyev
Acked-by: Adrien Mazarguil
---
drivers/net/mlx4/mlx4.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
index 67025c7..61ecf08 100644
--- a/drivers/net/mlx4/mlx4.c
+++ b/drivers/net/mlx4/mlx4.c
@@ -2876,6 +2876,8 @@ rxq_cleanup(struct rxq *rxq)
* @param flags
* RX completion flags returned by poll_length_flags().
*
+ * @note: fix mlx4_dev_supported_ptypes_get() if any change here.
+ *
* @return
* Packet type for struct rte_mbuf.
*/
@@ -4304,6 +4306,24 @@ mlx4_dev_infos_get(struct rte_eth_dev *dev, struct
rte_eth_dev_info *info)
priv_unlock(priv);
}
+static const uint32_t *
+mlx4_dev_supported_ptypes_get(struct rte_eth_dev *dev)
+{
+ static const uint32_t ptypes[] = {
+ /* refers to rxq_cq_to_pkt_type() */
+ RTE_PTYPE_L3_IPV4,
+ RTE_PTYPE_L3_IPV6,
+ RTE_PTYPE_INNER_L3_IPV4,
+ RTE_PTYPE_INNER_L3_IPV6,
+ RTE_PTYPE_UNKNOWN
+ };
+
+ if (dev->rx_pkt_burst == mlx4_rx_burst ||
+ dev->rx_pkt_burst == mlx4_rx_burst_sp)
+ return ptypes;
+ return NULL;
+}
+
/**
* DPDK callback to get device statistics.
*
@@ -5041,6 +5061,7 @@ static const struct eth_dev_ops mlx4_dev_ops = {
.stats_reset = mlx4_stats_reset,
.queue_stats_mapping_set = NULL,
.dev_infos_get = mlx4_dev_infos_get,
+ .dev_supported_ptypes_get = mlx4_dev_supported_ptypes_get,
.vlan_filter_set = mlx4_vlan_filter_set,
.vlan_tpid_set = NULL,
.vlan_strip_queue_set = NULL,
--
2.1.4
[dpdk-dev] [PATCH v8 09/11] mlx5: add dev_supported_ptypes_get implementation
Signed-off-by: Jianfeng Tan
Acked-by: Konstantin Ananyev
Acked-by: Adrien Mazarguil
---
drivers/net/mlx5/mlx5.c| 1 +
drivers/net/mlx5/mlx5.h| 1 +
drivers/net/mlx5/mlx5_ethdev.c | 20
drivers/net/mlx5/mlx5_rxtx.c | 2 ++
4 files changed, 24 insertions(+)
diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
index ad69ec2..8e2c909 100644
--- a/drivers/net/mlx5/mlx5.c
+++ b/drivers/net/mlx5/mlx5.c
@@ -157,6 +157,7 @@ static const struct eth_dev_ops mlx5_dev_ops = {
.stats_get = mlx5_stats_get,
.stats_reset = mlx5_stats_reset,
.dev_infos_get = mlx5_dev_infos_get,
+ .dev_supported_ptypes_get = mlx5_dev_supported_ptypes_get,
.vlan_filter_set = mlx5_vlan_filter_set,
.rx_queue_setup = mlx5_rx_queue_setup,
.tx_queue_setup = mlx5_tx_queue_setup,
diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index 43b24fb..8b9b96e 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -158,6 +158,7 @@ int priv_get_mtu(struct priv *, uint16_t *);
int priv_set_flags(struct priv *, unsigned int, unsigned int);
int mlx5_dev_configure(struct rte_eth_dev *);
void mlx5_dev_infos_get(struct rte_eth_dev *, struct rte_eth_dev_info *);
+const uint32_t *mlx5_dev_supported_ptypes_get(struct rte_eth_dev *dev);
int mlx5_link_update(struct rte_eth_dev *, int);
int mlx5_dev_set_mtu(struct rte_eth_dev *, uint16_t);
int mlx5_dev_get_flow_ctrl(struct rte_eth_dev *, struct rte_eth_fc_conf *);
diff --git a/drivers/net/mlx5/mlx5_ethdev.c b/drivers/net/mlx5/mlx5_ethdev.c
index 6704382..50551ea 100644
--- a/drivers/net/mlx5/mlx5_ethdev.c
+++ b/drivers/net/mlx5/mlx5_ethdev.c
@@ -525,6 +525,26 @@ mlx5_dev_infos_get(struct rte_eth_dev *dev, struct
rte_eth_dev_info *info)
priv_unlock(priv);
}
+const uint32_t *
+mlx5_dev_supported_ptypes_get(struct rte_eth_dev *dev)
+{
+ static const uint32_t ptypes[] = {
+ /* refers to rxq_cq_to_pkt_type() */
+ RTE_PTYPE_L3_IPV4,
+ RTE_PTYPE_L3_IPV6,
+ RTE_PTYPE_INNER_L3_IPV4,
+ RTE_PTYPE_INNER_L3_IPV6,
+ RTE_PTYPE_UNKNOWN
+
+ };
+
+ if (dev->rx_pkt_burst == mlx5_rx_burst ||
+ dev->rx_pkt_burst == mlx5_rx_burst_sp)
+ return ptypes;
+ return NULL;
+
+}
+
/**
* DPDK callback to retrieve physical link information (unlocked version).
*
diff --git a/drivers/net/mlx5/mlx5_rxtx.c b/drivers/net/mlx5/mlx5_rxtx.c
index 4919189..0128139 100644
--- a/drivers/net/mlx5/mlx5_rxtx.c
+++ b/drivers/net/mlx5/mlx5_rxtx.c
@@ -670,6 +670,8 @@ stop:
* @param flags
* RX completion flags returned by poll_length_flags().
*
+ * @note: fix mlx5_dev_supported_ptypes_get() if any change here.
+ *
* @return
* Packet type for struct rte_mbuf.
*/
--
2.1.4
[dpdk-dev] [PATCH v8 10/11] nfp: add dev_supported_ptypes_get implementation
Signed-off-by: Jianfeng Tan
Acked-by: Konstantin Ananyev
Acked-by: Adrien Mazarguil
---
drivers/net/nfp/nfp_net.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c
index 573b6bc..163cac8 100644
--- a/drivers/net/nfp/nfp_net.c
+++ b/drivers/net/nfp/nfp_net.c
@@ -1063,6 +1063,24 @@ nfp_net_infos_get(struct rte_eth_dev *dev, struct
rte_eth_dev_info *dev_info)
dev_info->hash_key_size = NFP_NET_CFG_RSS_KEY_SZ;
}
+static const uint32_t *
+nfp_net_supported_ptypes_get(struct rte_eth_dev *dev)
+{
+ static const uint32_t ptypes[] = {
+ /* refers to nfp_net_set_hash() */
+ RTE_PTYPE_INNER_L3_IPV4,
+ RTE_PTYPE_INNER_L3_IPV6,
+ RTE_PTYPE_INNER_L3_IPV6_EXT,
+ RTE_PTYPE_INNER_L4_MASK,
+ RTE_PTYPE_UNKNOWN
+ };
+
+
+ if (dev->rx_pkt_burst == nfp_net_recv_pkts)
+ return ptypes;
+ return num;
+}
+
static uint32_t
nfp_net_rx_queue_count(struct rte_eth_dev *dev, uint16_t queue_idx)
{
@@ -2283,6 +2301,7 @@ static struct eth_dev_ops nfp_net_eth_dev_ops = {
.stats_get = nfp_net_stats_get,
.stats_reset= nfp_net_stats_reset,
.dev_infos_get = nfp_net_infos_get,
+ .dev_supported_ptypes_get = nfp_net_supported_ptypes_get,
.mtu_set= nfp_net_dev_mtu_set,
.vlan_offload_set = nfp_net_vlan_offload_set,
.reta_update= nfp_net_reta_update,
--
2.1.4
[dpdk-dev] [PATCH v8 11/11] vmxnet3: add dev_supported_ptypes_get implementation
Signed-off-by: Jianfeng Tan
Acked-by: Konstantin Ananyev
Acked-by: Adrien Mazarguil
---
drivers/net/vmxnet3/vmxnet3_ethdev.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/net/vmxnet3/vmxnet3_ethdev.c
b/drivers/net/vmxnet3/vmxnet3_ethdev.c
index a5c9ba5..f2b6b92 100644
--- a/drivers/net/vmxnet3/vmxnet3_ethdev.c
+++ b/drivers/net/vmxnet3/vmxnet3_ethdev.c
@@ -86,6 +86,8 @@ static void vmxnet3_dev_stats_get(struct rte_eth_dev *dev,
struct rte_eth_stats *stats);
static void vmxnet3_dev_info_get(struct rte_eth_dev *dev,
struct rte_eth_dev_info *dev_info);
+static const uint32_t *
+vmxnet3_dev_supported_ptypes_get(struct rte_eth_dev *dev);
static int vmxnet3_dev_vlan_filter_set(struct rte_eth_dev *dev,
uint16_t vid, int on);
static void vmxnet3_dev_vlan_offload_set(struct rte_eth_dev *dev, int mask);
@@ -119,6 +121,7 @@ static const struct eth_dev_ops vmxnet3_eth_dev_ops = {
.stats_get= vmxnet3_dev_stats_get,
.mac_addr_set = vmxnet3_mac_addr_set,
.dev_infos_get= vmxnet3_dev_info_get,
+ .dev_supported_ptypes_get = vmxnet3_dev_supported_ptypes_get,
.vlan_filter_set = vmxnet3_dev_vlan_filter_set,
.vlan_offload_set = vmxnet3_dev_vlan_offload_set,
.rx_queue_setup = vmxnet3_dev_rx_queue_setup,
@@ -734,6 +737,20 @@ vmxnet3_dev_info_get(__attribute__((unused))struct
rte_eth_dev *dev,
DEV_TX_OFFLOAD_TCP_TSO;
}
+static const uint32_t *
+vmxnet3_dev_supported_ptypes_get(struct rte_eth_dev *dev)
+{
+ static const uint32_t ptypes[] = {
+ RTE_PTYPE_L3_IPV4_EXT,
+ RTE_PTYPE_L3_IPV4,
+ RTE_PTYPE_UNKNOWN
+ };
+
+ if (dev->rx_pkt_burst == vmxnet3_recv_pkts)
+ return ptypes;
+ return NULL;
+}
+
static void
vmxnet3_mac_addr_set(struct rte_eth_dev *dev, struct ether_addr *mac_addr)
{
--
2.1.4
[dpdk-dev] [PATCH v2 1/5] mem: add --single-file to create single mem-backed file
2016-03-14 13:53, Traynor, Kevin: > From: Thomas Monjalon > > 2016-03-08 17:04, Yuanhan Liu: > > > On Tue, Mar 08, 2016 at 10:49:30AM +0200, Panu Matilainen wrote: > > > > On 03/07/2016 03:13 PM, Yuanhan Liu wrote: > > > > Note that SINGLE_FILE_SEGMENTS is a nasty hack that only the IVSHMEM > > config > > > > uses, getting rid of it (by replacing with a runtime switch) would be > > great. > > > > > > Can't agree more. > > > > +1 > > > > > > OTOH IVSHMEM itself seems to have fallen out of the fashion since the > > memnic > > > > driver is unmaintained and broken since dpdk 2.0... CC'ing the IVSHMEM > > > > maintainer in case he has thoughts on this. > > > > The ivshmem config was not used for memnic which was using ivshmem only for > > data path. > > CONFIG_RTE_LIBRTE_IVSHMEM and CONFIG_RTE_EAL_SINGLE_FILE_SEGMENTS are more > > about full memory sharing. > > I have the feeling it could be dropped. > > It there are some users, I'd like to see a justification and a rework to > > remove these build options. > > Just to clarify - is this suggesting the removal of the IVSHMEM library > itself, > or just some of the config options? I have no strong opinion about the library. About the config options, yes they should be removed. Note that they are not documented, so we don't really know the motivation to have them. > The reason I ask is that although we don't currently use it in OVS with DPDK, > I've seen at least one person using it in conjunction with the ring interface. > There may be others, so I want to cross-post if there's a deprecation > discussion. Thank you for sharing.
[dpdk-dev] [PATCH v5 0/4] Use common Linux tools to control DPDK ports
On 3/9/2016 11:41 AM, Ferruh Yigit wrote: > This patch sent to keep record of latest status of the work. > > > This work is to make DPDK ports more visible and to enable using common > Linux tools to configure DPDK ports. > > Patch is based on KNI but contains only control functionality of it, > also this patch does not include any Linux kernel network driver as > part of it. > > Basically with the help of a kernel module (KCP), virtual Linux network > interfaces named as "dpdk$" are created per DPDK port, control messages > sent to these virtual interfaces are forwarded to DPDK, and response > sent back to Linux application. > > Virtual interfaces created when DPDK application started and destroyed > automatically when DPDK application terminated. > > Communication between kernel-space and DPDK done using netlink socket. > > In long term this patch intends to replace the KNI and KNI will be > depreciated. > Self-NACK: Will work on netdev to upstream this.
[dpdk-dev] [PATCH v3 0/2] slow data path communication between DPDK port and Linux
On 3/9/2016 11:17 AM, Ferruh Yigit wrote: > This patch sent to keep record of latest status of the work. > > > This is slow data path communication implementation based on existing KNI. > > Difference is: librte_kni converted into a PMD, kdp kernel module is almost > same except all control path functionality removed and some simplification > done. > > Motivation is to simplify slow path data communication. > Now any application can use this new PMD to send/get data to Linux kernel. > > PMD supports two communication methods: > > 1) KDP kernel module > PMD initialization functions handles creating virtual interfaces (with help of > kdp kernel module) and created FIFO. FIFO is used to share data between > userspace and kernelspace. This is default method. > > 2) tun/tap module > When KDP module is not inserted, PMD creates tap interface and transfers > packets using tap interface. > > In long term this patch intends to replace the KNI and KNI will be > depreciated. > Self-NACK: Will work on another option that does not introduce new kernel module.
[dpdk-dev] [PATCH] app/test/test_table_acl: fix incorrect IP
Date: Mon, 14 Mar 2016 12:22:01 + From: Fan Zhang To: dev at dpdk.org Subject: [dpdk-dev] [PATCH] app/test/test_table_acl: fix incorrect IP header Message-ID: <1457958122-20136-1-git-send-email-roy.fan.zhang at intel.com> This patch fixes the incorrect IP header in ACL table test. Signed-off-by: Fan Zhang I have reviewed this, it looks fine to me, but test_acl maintainer should also Ack this. Reviewed-by: Ian Betts Acked-by: Ian Betts Ian Betts Intel Shannon Limited Registered in Ireland Registered Office Collinstown Industrial Park, Leixlip, County Kildare Registered Number:308263 Business address: Dromore House, East Park, Shannon, Co. Clare
[dpdk-dev] [PATCH v3 1/3] mk: clear up libm and librt linkage confusion
On 3/10/2016 1:15 PM, Panu Matilainen wrote: > There are two places that need -lm (test app and librte_sched) and > exactly one that needs -lrt (librte_sched). Add the relevant > DT_NEEDED entries to both, and eliminate the bogus discrepancy > between Linux and BSD EXECENV_LDLIBS wrt these libs. > > Signed-off-by: Panu Matilainen > --- > app/test/Makefile| 2 ++ > lib/librte_sched/Makefile| 3 +++ > mk/exec-env/linuxapp/rte.vars.mk | 2 +- > mk/rte.app.mk| 6 ++ > 4 files changed, 8 insertions(+), 5 deletions(-) > > diff --git a/app/test/Makefile b/app/test/Makefile > index ec33e1a..00e4df2 100644 > --- a/app/test/Makefile > +++ b/app/test/Makefile > @@ -160,6 +160,8 @@ CFLAGS += $(WERROR_FLAGS) > > CFLAGS += -D_GNU_SOURCE > > +LDLIBS += -lm > + > # Disable VTA for memcpy test > ifeq ($(CC), gcc) > ifeq ($(shell test $(GCC_VERSION) -ge 44 && echo 1), 1) > diff --git a/lib/librte_sched/Makefile b/lib/librte_sched/Makefile > index b1cb285..4d631f6 100644 > --- a/lib/librte_sched/Makefile > +++ b/lib/librte_sched/Makefile > @@ -41,6 +41,9 @@ CFLAGS += $(WERROR_FLAGS) > > CFLAGS_rte_red.o := -D_GNU_SOURCE > > +LDLIBS += -lm > +LDLIBS += -lrt > + > EXPORT_MAP := rte_sched_version.map > > LIBABIVER := 1 > diff --git a/mk/exec-env/linuxapp/rte.vars.mk > b/mk/exec-env/linuxapp/rte.vars.mk > index 5fd7d85..d51bd17 100644 > --- a/mk/exec-env/linuxapp/rte.vars.mk > +++ b/mk/exec-env/linuxapp/rte.vars.mk > @@ -48,7 +48,7 @@ endif > # Workaround lack of DT_NEEDED entry > EXECENV_LDFLAGS = --no-as-needed > > -EXECENV_LDLIBS = -lrt -lm > +EXECENV_LDLIBS = > EXECENV_ASFLAGS = > > ifeq ($(CONFIG_RTE_BUILD_SHARED_LIB),y) > diff --git a/mk/rte.app.mk b/mk/rte.app.mk > index daac09f..cadc7ab 100644 > --- a/mk/rte.app.mk > +++ b/mk/rte.app.mk > @@ -77,11 +77,7 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_LPM)+= -lrte_lpm > _LDLIBS-$(CONFIG_RTE_LIBRTE_POWER) += -lrte_power > _LDLIBS-$(CONFIG_RTE_LIBRTE_ACL)+= -lrte_acl > _LDLIBS-$(CONFIG_RTE_LIBRTE_METER) += -lrte_meter > - > _LDLIBS-$(CONFIG_RTE_LIBRTE_SCHED) += -lrte_sched > -_LDLIBS-$(CONFIG_RTE_LIBRTE_SCHED) += -lm > -_LDLIBS-$(CONFIG_RTE_LIBRTE_SCHED) += -lrt > - > _LDLIBS-$(CONFIG_RTE_LIBRTE_VHOST) += -lrte_vhost > > ifeq ($(CONFIG_RTE_LIBRTE_VHOST_NUMA),y) > @@ -104,6 +100,8 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_XENVIRT)+= -lxenstore > _LDLIBS-$(CONFIG_RTE_LIBRTE_MPIPE_PMD) += -lgxio > # QAT PMD has a dependency on libcrypto (from openssl) for calculating HMAC > precomputes > _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_QAT)+= -lcrypto > +_LDLIBS-$(CONFIG_RTE_LIBRTE_SCHED) += -lm > +_LDLIBS-$(CONFIG_RTE_LIBRTE_SCHED) += -lrt > endif # !CONFIG_RTE_BUILD_SHARED_LIBS > > _LDLIBS-y += --start-group > This is causing a shared library compilation error with gcc: " == Build app/test-acl LD testacl /root/dpdk/build/lib/librte_meter.so: error: undefined reference to 'ceil' collect2: error: ld returned 1 exit status " There is an indirect libm dependency from test-acl. Adding -lm fixes the issue. But this issue not seen by everybody, not sure why I am getting this but not others. Also clang compiles fine, only fails with gcc. I am using Fedora 23, gcc version: gcc (GCC) 5.3.1 20151207 (Red Hat 5.3.1-2) I will dig some more. Regards, ferruh
[dpdk-dev] Patch "Increased number of next hops for LPM IPv4" break IP Pipeline application
Hi Michal, Your patch "Increased number of next hops for LPM IPv4" (http://dpdk.org/ml/archives/dev/2016-March/035269.html) is breaking the IP Pipeline application. Without this patch, the application runs successfully. The IP Pipeline failed on executing the following command: ./build/ip_pipeline -f ./config/edge_router_downstream.cfg -s ./config/edge_router_downstream.sh -p 0xf The error messages: [PIPELINE1] Routing TABLE: rte_table_lpm_create: Invalid number_tbl8s PIPELINE: rte_pipeline_table_create: Table creation failed PANIC in app_init_pipelines(): Pipeline instance "PIPELINE1" back-end init error Regards, Fan
[dpdk-dev] [PATCH v8 01/11] ethdev: add API to query supported packet types
On 3/14/2016 7:42 AM, Jianfeng Tan wrote:
> Add a new API rte_eth_dev_get_supported_ptypes to query what packet types
> can be filled by given already started device (or its pmd rx burst function
> has already been decided).
>
> Signed-off-by: Jianfeng Tan
> Acked-by: Konstantin Ananyev
> Acked-by: Adrien Mazarguil
> ---
<...>
> +DPDK_16.04 {
> + rte_eth_dev_get_supported_ptypes;
Other script files tends to put a blank line before function names.
> +
> + local: *;
This line is not required.
> +} DPDK_2.2;
>
[dpdk-dev] [PATCH v5 0/4] Use common Linux tools to control DPDK ports
Is there some technical reason or is it just the push-back you are getting from some of the maintainers? I chimed in on one of the other threads already, but I'm extremely disappointed that usability and serviceability improvements to existing DPDK capabilities (KNI) are getting blocked like this. For companies building network appliances based on DPDK, having a kernel module that isn't in the tree just isn't that big of a deal. Long term goals for getting this upstream are great, but why not take advantage of incremental improvements in the meantime? Jay On Mon, Mar 14, 2016 at 10:31 AM, Ferruh Yigit wrote: > On 3/9/2016 11:41 AM, Ferruh Yigit wrote: > > This patch sent to keep record of latest status of the work. > > > > > > This work is to make DPDK ports more visible and to enable using common > > Linux tools to configure DPDK ports. > > > > Patch is based on KNI but contains only control functionality of it, > > also this patch does not include any Linux kernel network driver as > > part of it. > > > > Basically with the help of a kernel module (KCP), virtual Linux network > > interfaces named as "dpdk$" are created per DPDK port, control messages > > sent to these virtual interfaces are forwarded to DPDK, and response > > sent back to Linux application. > > > > Virtual interfaces created when DPDK application started and destroyed > > automatically when DPDK application terminated. > > > > Communication between kernel-space and DPDK done using netlink socket. > > > > In long term this patch intends to replace the KNI and KNI will be > > depreciated. > > > > Self-NACK: Will work on netdev to upstream this. > >
[dpdk-dev] Huge pages to be allocated based on number of mbufs
Hi, We are planning to support virtio, vmxnet3, ixgbe, i40e, bxn2x and SR-IOV on some of them with DPDK. We have seen that even if we give correct number of mbufs given the number hugepages reserved, rte_eth_tx_queue_setup() may still fail with no enough memory (I saw this on i40evf but worked on virtio and vmxnet3). We like to know what's the recommended way to determine how many hugepages we should allocate given the number of mbufs such that queue setup APIs also don't fail. Since we will be running on low-end systems too we need to be careful about reserving hugepages. Thanks, /Saurabh
[dpdk-dev] [PATCH v2 1/5] mem: add --single-file to create single mem-backed file
> -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Monday, March 14, 2016 2:45 PM > To: Traynor, Kevin > Cc: dev at dpdk.org; nakajima.yoshihiro at lab.ntt.co.jp; mst at redhat.com; > p.fedin at samsung.com; ann.zhuangyanying at huawei.com > Subject: Re: [dpdk-dev] [PATCH v2 1/5] mem: add --single-file to create > single mem-backed file > > 2016-03-14 13:53, Traynor, Kevin: > > From: Thomas Monjalon > > > 2016-03-08 17:04, Yuanhan Liu: > > > > On Tue, Mar 08, 2016 at 10:49:30AM +0200, Panu Matilainen wrote: > > > > > On 03/07/2016 03:13 PM, Yuanhan Liu wrote: > > > > > Note that SINGLE_FILE_SEGMENTS is a nasty hack that only the IVSHMEM > > > config > > > > > uses, getting rid of it (by replacing with a runtime switch) would be > > > great. > > > > > > > > Can't agree more. > > > > > > +1 > > > > > > > > OTOH IVSHMEM itself seems to have fallen out of the fashion since the > > > memnic > > > > > driver is unmaintained and broken since dpdk 2.0... CC'ing the > IVSHMEM > > > > > maintainer in case he has thoughts on this. > > > > > > The ivshmem config was not used for memnic which was using ivshmem only > for > > > data path. > > > CONFIG_RTE_LIBRTE_IVSHMEM and CONFIG_RTE_EAL_SINGLE_FILE_SEGMENTS are > more > > > about full memory sharing. > > > I have the feeling it could be dropped. > > > It there are some users, I'd like to see a justification and a rework to > > > remove these build options. > > > > Just to clarify - is this suggesting the removal of the IVSHMEM library > itself, > > or just some of the config options? > > I have no strong opinion about the library. > About the config options, yes they should be removed. Note that they are not > documented, so we don't really know the motivation to have them. ok, thanks for clarifying. As there's no imminent plans to remove the library, I won't cross post. > > > The reason I ask is that although we don't currently use it in OVS with > DPDK, > > I've seen at least one person using it in conjunction with the ring > interface. > > There may be others, so I want to cross-post if there's a deprecation > discussion. > > Thank you for sharing.
[dpdk-dev] [PATCH v6 0/4] DPDK polling-mode driver for Amazon Elastic Network Adapters (ENA)
v3: Additional features for Amazon ENA: * Low Latenycy Queue (LLQ) for Tx * RSS v4: * Improved doc * Improved style according to checkpatch script * Fixed build problems on: i686, clang, +shared, +debug v5: * Removed 'cvos' environment code from ena Makefile * Driver symbol version fixed to DPDK_16.04 * Max MTU is read from device attributes v6: * Updated ENA communication layer * Added check if DPDK queue size is supported by device * Checkpatch results: 6 warns >80, 0 warns >90, no whitespace issues * defined likely/unlikely (can compile with ARM toolchain) * Updated doc/guides/nics/overview.rst w/ ENA * Removed metioned #pragma for "-Wcast-qual" Jan Medala (4): ena: Amazon ENA documentation ena: Amazon ENA communication layer ena: Amazon ENA communication layer for DPDK platform ena: DPDK polling-mode driver for Amazon Elastic Network Adapters (ENA) MAINTAINERS |8 + config/common_base | 11 + doc/guides/nics/ena.rst | 251 ++ doc/guides/nics/index.rst |1 + doc/guides/nics/overview.rst| 116 +- drivers/net/Makefile|1 + drivers/net/ena/Makefile| 61 + drivers/net/ena/base/ena_com.c | 2809 +++ drivers/net/ena/base/ena_com.h | 1052 + drivers/net/ena/base/ena_defs/ena_admin_defs.h | 1979 drivers/net/ena/base/ena_defs/ena_common_defs.h | 54 + drivers/net/ena/base/ena_defs/ena_eth_io_defs.h | 1488 drivers/net/ena/base/ena_defs/ena_gen_info.h| 35 + drivers/net/ena/base/ena_defs/ena_includes.h| 39 + drivers/net/ena/base/ena_defs/ena_regs_defs.h | 135 ++ drivers/net/ena/base/ena_eth_com.c | 508 drivers/net/ena/base/ena_eth_com.h | 153 ++ drivers/net/ena/base/ena_plat.h | 51 + drivers/net/ena/base/ena_plat_dpdk.h| 233 ++ drivers/net/ena/ena_ethdev.c| 1445 drivers/net/ena/ena_ethdev.h| 160 ++ drivers/net/ena/ena_logs.h | 74 + drivers/net/ena/ena_platform.h | 59 + drivers/net/ena/rte_pmd_ena_version.map |4 + mk/rte.app.mk |1 + 25 files changed, 10670 insertions(+), 58 deletions(-) create mode 100644 doc/guides/nics/ena.rst create mode 100644 drivers/net/ena/Makefile create mode 100644 drivers/net/ena/base/ena_com.c create mode 100644 drivers/net/ena/base/ena_com.h create mode 100644 drivers/net/ena/base/ena_defs/ena_admin_defs.h create mode 100644 drivers/net/ena/base/ena_defs/ena_common_defs.h create mode 100644 drivers/net/ena/base/ena_defs/ena_eth_io_defs.h create mode 100644 drivers/net/ena/base/ena_defs/ena_gen_info.h create mode 100644 drivers/net/ena/base/ena_defs/ena_includes.h create mode 100644 drivers/net/ena/base/ena_defs/ena_regs_defs.h create mode 100644 drivers/net/ena/base/ena_eth_com.c create mode 100644 drivers/net/ena/base/ena_eth_com.h create mode 100644 drivers/net/ena/base/ena_plat.h create mode 100644 drivers/net/ena/base/ena_plat_dpdk.h create mode 100644 drivers/net/ena/ena_ethdev.c create mode 100644 drivers/net/ena/ena_ethdev.h create mode 100644 drivers/net/ena/ena_logs.h create mode 100644 drivers/net/ena/ena_platform.h create mode 100644 drivers/net/ena/rte_pmd_ena_version.map -- 1.9.1
[dpdk-dev] [PATCH v6 1/4] ena: Amazon ENA documentation
Signed-off-by: Alexander Matushevsky Signed-off-by: Jan Medala Signed-off-by: Jakub Palider --- MAINTAINERS | 8 ++ doc/guides/nics/ena.rst | 251 +++ doc/guides/nics/index.rst| 1 + doc/guides/nics/overview.rst | 116 ++-- 4 files changed, 318 insertions(+), 58 deletions(-) create mode 100644 doc/guides/nics/ena.rst diff --git a/MAINTAINERS b/MAINTAINERS index f10b26a..d37aad6 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -260,6 +260,14 @@ Linux AF_PACKET M: John W. Linville F: drivers/net/af_packet/ +Amazon ena +M: Jan Medala +M: Jakub Palider +M: Netanel Belgazal +M: Evgeny Schemeilin +F: drivers/net/ena/ +F: doc/guides/nics/ena.rst + Chelsio cxgbe M: Rahul Lakkireddy F: drivers/net/cxgbe/ diff --git a/doc/guides/nics/ena.rst b/doc/guides/nics/ena.rst new file mode 100644 index 000..9f93848 --- /dev/null +++ b/doc/guides/nics/ena.rst @@ -0,0 +1,251 @@ +.. BSD LICENSE + +Copyright (c) 2015-2016 Amazon.com, Inc. or its affiliates. +All rights reserved. + +Redistribution and use in source and binary forms, with or without +modification, are permitted provided that the following conditions +are met: + +* Redistributions of source code must retain the above copyright +notice, this list of conditions and the following disclaimer. +* Redistributions in binary form must reproduce the above copyright +notice, this list of conditions and the following disclaimer in +the documentation and/or other materials provided with the +distribution. +* Neither the name of Amazon.com, Inc. nor the names of its +contributors may be used to endorse or promote products derived +from this software without specific prior written permission. + +THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS +"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT +LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR +A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT +OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, +SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT +LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, +DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY +THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT +(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE +OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + +ENA Poll Mode Driver + + +The ENA PMD is a DPDK poll-mode driver for the Amazon Elastic +Network Adapter (ENA) family. + +Overview + + +The ENA driver exposes a lightweight management interface with a +minimal set of memory mapped registers and an extendable command set +through an Admin Queue. + +The driver supports a wide range of ENA adapters, is link-speed +independent (i.e., the same driver is used for 10GbE, 25GbE, 40GbE, +etc.), and it negotiates and supports an extendable feature set. + +ENA adapters allow high speed and low overhead Ethernet traffic +processing by providing a dedicated Tx/Rx queue pair per CPU core. + +The ENA driver supports industry standard TCP/IP offload features such +as checksum offload and TCP transmit segmentation offload (TSO). + +Receive-side scaling (RSS) is supported for multi-core scaling. + +Some of the ENA devices support a working mode called Low-latency +Queue (LLQ), which saves several more microseconds. + +Management Interface + + +ENA management interface is exposed by means of: + +* Device Registers +* Admin Queue (AQ) and Admin Completion Queue (ACQ) + +ENA device memory-mapped PCIe space for registers (MMIO registers) +are accessed only during driver initialization and are not involved +in further normal device operation. + +AQ is used for submitting management commands, and the +results/responses are reported asynchronously through ACQ. + +ENA introduces a very small set of management commands with room for +vendor-specific extensions. Most of the management operations are +framed in a generic Get/Set feature command. + +The following admin queue commands are supported: + +* Create I/O submission queue +* Create I/O completion queue +* Destroy I/O submission queue +* Destroy I/O completion queue +* Get feature +* Set feature +* Get statistics + +Refer to ``ena_admin_defs.h`` for the list of supported Get/Set Feature +properties. + +Data Path Interface +--- + +I/O operations are based on Tx and Rx Submission Queues (Tx SQ and Rx +SQ correspondingly). Each SQ has a completion queue (CQ) associated +with it. + +The SQs and CQs are implemented as descriptor rings in contiguous +physical memory. + +Refer to ``ena_eth_io_defs.h`` for the detailed structure of the descriptor + +The driver supports multi-queue for both Tx and Rx.
[dpdk-dev] [PATCH v6 2/4] ena: Amazon ENA communication layer
Low level common abstraction for ENA device communication.
Signed-off-by: Netanel Belgazal
Signed-off-by: Jan Medala
Signed-off-by: Jakub Palider
---
drivers/net/ena/base/ena_com.c | 2809 +++
drivers/net/ena/base/ena_com.h | 1052 +
drivers/net/ena/base/ena_defs/ena_admin_defs.h | 1979
drivers/net/ena/base/ena_defs/ena_common_defs.h | 54 +
drivers/net/ena/base/ena_defs/ena_eth_io_defs.h | 1488
drivers/net/ena/base/ena_defs/ena_gen_info.h| 35 +
drivers/net/ena/base/ena_defs/ena_includes.h| 39 +
drivers/net/ena/base/ena_defs/ena_regs_defs.h | 135 ++
drivers/net/ena/base/ena_eth_com.c | 508
drivers/net/ena/base/ena_eth_com.h | 153 ++
drivers/net/ena/base/ena_plat.h | 51 +
11 files changed, 8303 insertions(+)
create mode 100644 drivers/net/ena/base/ena_com.c
create mode 100644 drivers/net/ena/base/ena_com.h
create mode 100644 drivers/net/ena/base/ena_defs/ena_admin_defs.h
create mode 100644 drivers/net/ena/base/ena_defs/ena_common_defs.h
create mode 100644 drivers/net/ena/base/ena_defs/ena_eth_io_defs.h
create mode 100644 drivers/net/ena/base/ena_defs/ena_gen_info.h
create mode 100644 drivers/net/ena/base/ena_defs/ena_includes.h
create mode 100644 drivers/net/ena/base/ena_defs/ena_regs_defs.h
create mode 100644 drivers/net/ena/base/ena_eth_com.c
create mode 100644 drivers/net/ena/base/ena_eth_com.h
create mode 100644 drivers/net/ena/base/ena_plat.h
diff --git a/drivers/net/ena/base/ena_com.c b/drivers/net/ena/base/ena_com.c
new file mode 100644
index 000..c7355eb
--- /dev/null
+++ b/drivers/net/ena/base/ena_com.c
@@ -0,0 +1,2809 @@
+/*-
+* BSD LICENSE
+*
+* Copyright (c) 2015-2016 Amazon.com, Inc. or its affiliates.
+* All rights reserved.
+*
+* Redistribution and use in source and binary forms, with or without
+* modification, are permitted provided that the following conditions
+* are met:
+*
+* * Redistributions of source code must retain the above copyright
+* notice, this list of conditions and the following disclaimer.
+* * Redistributions in binary form must reproduce the above copyright
+* notice, this list of conditions and the following disclaimer in
+* the documentation and/or other materials provided with the
+* distribution.
+* * Neither the name of copyright holder nor the names of its
+* contributors may be used to endorse or promote products derived
+* from this software without specific prior written permission.
+*
+* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+* "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+* LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+* A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+* OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+* THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+*/
+
+#include "ena_com.h"
+
+/*/
+/*/
+
+/* Timeout in micro-sec */
+#define ADMIN_CMD_TIMEOUT_US (100)
+
+#define ENA_ASYNC_QUEUE_DEPTH 4
+#define ENA_ADMIN_QUEUE_DEPTH 32
+
+#define ENA_EXTENDED_STAT_GET_FUNCT(_funct_queue) (_funct_queue & 0x)
+#define ENA_EXTENDED_STAT_GET_QUEUE(_funct_queue) (_funct_queue >> 16)
+
+#define MIN_ENA_VER (((ENA_COMMON_SPEC_VERSION_MAJOR) << \
+ ENA_REGS_VERSION_MAJOR_VERSION_SHIFT) \
+ | (ENA_COMMON_SPEC_VERSION_MINOR))
+
+#define ENA_CTRL_MAJOR 0
+#define ENA_CTRL_MINOR 0
+#define ENA_CTRL_SUB_MINOR 1
+
+#define MIN_ENA_CTRL_VER \
+ (((ENA_CTRL_MAJOR) << \
+ (ENA_REGS_CONTROLLER_VERSION_MAJOR_VERSION_SHIFT)) | \
+ ((ENA_CTRL_MINOR) << \
+ (ENA_REGS_CONTROLLER_VERSION_MINOR_VERSION_SHIFT)) | \
+ (ENA_CTRL_SUB_MINOR))
+
+#define ENA_DMA_ADDR_TO_UINT32_LOW(x) ((u32)((u64)(x)))
+#define ENA_DMA_ADDR_TO_UINT32_HIGH(x) ((u32)(((u64)(x)) >> 32))
+
+#define ENA_MMIO_READ_TIMEOUT 0x
+
+static int ena_alloc_cnt;
+
+/*/
+/*/
+/*/
+
+enum ena_cmd_status {
+ ENA_CMD_SUBMITTED,
+ ENA_CMD_COMPLETED,
+ /* Abort - canceled by the driver */
+ ENA_CMD_ABORTED,
+};
+
+struct ena_comp_ctx {
+ ena_wait_event_t
[dpdk-dev] [PATCH v6 3/4] ena: Amazon ENA communication layer for DPDK platform
Implementation of platform specific code for ENA communication layer.
Signed-off-by: Evgeny Schemeilin
Signed-off-by: Jan Medala
Signed-off-by: Jakub Palider
---
drivers/net/ena/base/ena_plat_dpdk.h | 233 +++
1 file changed, 233 insertions(+)
create mode 100644 drivers/net/ena/base/ena_plat_dpdk.h
diff --git a/drivers/net/ena/base/ena_plat_dpdk.h
b/drivers/net/ena/base/ena_plat_dpdk.h
new file mode 100644
index 000..8674fc1
--- /dev/null
+++ b/drivers/net/ena/base/ena_plat_dpdk.h
@@ -0,0 +1,233 @@
+/*-
+* BSD LICENSE
+*
+* Copyright (c) 2015-2016 Amazon.com, Inc. or its affiliates.
+* All rights reserved.
+*
+* Redistribution and use in source and binary forms, with or without
+* modification, are permitted provided that the following conditions
+* are met:
+*
+* * Redistributions of source code must retain the above copyright
+* notice, this list of conditions and the following disclaimer.
+* * Redistributions in binary form must reproduce the above copyright
+* notice, this list of conditions and the following disclaimer in
+* the documentation and/or other materials provided with the
+* distribution.
+* * Neither the name of copyright holder nor the names of its
+* contributors may be used to endorse or promote products derived
+* from this software without specific prior written permission.
+*
+* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+* "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+* LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+* A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+* OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+* THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+*/
+
+#ifndef DPDK_ENA_COM_ENA_PLAT_DPDK_H_
+#define DPDK_ENA_COM_ENA_PLAT_DPDK_H_
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+typedef uint64_t u64;
+typedef uint32_t u32;
+typedef uint16_t u16;
+typedef uint8_t u8;
+
+typedef uint64_t dma_addr_t;
+
+#define ena_atomic32_t rte_atomic32_t
+#define ena_mem_handle_t void *
+
+#define SZ_256 (256)
+#define SZ_4K (4096)
+
+#defineENA_COM_OK 0
+#defineENA_COM_NO_MEM -ENOMEM
+#defineENA_COM_INVAL -EINVAL
+#defineENA_COM_NO_SPACE-ENOSPC
+#defineENA_COM_NO_DEVICE -ENODEV
+#defineENA_COM_PERMISSION -EPERM
+#defineENA_COM_TIMER_EXPIRED -ETIME
+#defineENA_COM_FAULT -EFAULT
+
+#define cacheline_aligned __rte_cache_aligned
+
+#define ENA_ABORT() abort()
+
+#define ENA_MSLEEP(x) rte_delay_ms(x)
+#define ENA_UDELAY(x) rte_delay_us(x)
+
+#ifndef unlikely
+#define unlikely(c) __builtin_expect(!!(c), 0)
+#endif
+#ifndef likely
+#define likely(c) __builtin_expect(!!(c), 1)
+#endif
+
+#define memcpy_toio memcpy
+#define wmb rte_wmb
+#define rmb rte_wmb
+#define mb rte_mb
+#define __iomem
+
+#define US_PER_S 100
+#define ENA_GET_SYSTEM_USECS() \
+ (rte_get_timer_cycles() * US_PER_S / rte_get_timer_hz())
+
+#define ENA_ASSERT(cond, format, arg...) \
+ do {\
+ if (unlikely(!(cond))) {\
+ printf("Assertion failed on %s:%s:%d:" format, \
+ __FILE__, __func__, __LINE__, ##arg); \
+ rte_exit(EXIT_FAILURE, "ASSERTION FAILED\n"); \
+ } \
+ } while (0)
+
+#define max_t(type, x, y) ({ \
+ type __max1 = (x); \
+ type __max2 = (y); \
+ __max1 > __max2 ? __max1 : __max2; })
+
+#define min_t(type, x, y) ({ \
+ type __min1 = (x); \
+ type __min2 = (y); \
+ __min1 < __min2 ? __min1 : __min2; })
+
+#define ENA_MAX32(x, y) max_t(u32, (x), (y))
+#define ENA_MAX16(x, y) max_t(u16, (x), (y))
+#define ENA_MAX8(x, y) max_t(u8, (x), (y))
+#define ENA_MIN32(x, y) min_t(u32, (x), (y))
+#define ENA_MIN16(x, y) min_t(u16, (x), (y))
+#define ENA_MIN8(x, y) min_t(u8, (x), (y))
+
+#define U64_C(x) x ## ULL
+#define BIT(nr) (1UL << (nr))
+#define BITS_PER_LONG (__SIZEOF_LONG__ * 8)
+#define GENMASK(h, l) (((~0UL) << (l)) & (~0UL >> (BITS_PER_LONG - 1 - (h
+#define GENMASK_ULL(h, l) (((U64_C(1) << ((h) - (l) + 1)) - 1) << (l))
+
+#ifdef RTE_LIBRTE_ENA_COM_DEBUG
+#define ena_trc_dbg(format, arg...)
[dpdk-dev] [PATCH v6 4/4] ena: DPDK polling-mode driver for Amazon Elastic Network Adapters (ENA)
This is a PMD for the Amazon ethernet ENA family. The driver operates variety of ENA adapters through feature negotiation with the adapter and upgradable commands set. ENA driver handles PCI Physical and Virtual ENA functions. Signed-off-by: Evgeny Schemeilin Signed-off-by: Jan Medala Signed-off-by: Jakub Palider --- config/common_base | 11 + drivers/net/Makefile|1 + drivers/net/ena/Makefile| 61 ++ drivers/net/ena/ena_ethdev.c| 1445 +++ drivers/net/ena/ena_ethdev.h| 160 drivers/net/ena/ena_logs.h | 74 ++ drivers/net/ena/ena_platform.h | 59 ++ drivers/net/ena/rte_pmd_ena_version.map |4 + mk/rte.app.mk |1 + 9 files changed, 1816 insertions(+) create mode 100644 drivers/net/ena/Makefile create mode 100644 drivers/net/ena/ena_ethdev.c create mode 100644 drivers/net/ena/ena_ethdev.h create mode 100644 drivers/net/ena/ena_logs.h create mode 100644 drivers/net/ena/ena_platform.h create mode 100644 drivers/net/ena/rte_pmd_ena_version.map diff --git a/config/common_base b/config/common_base index 52bd34f..472a9e9 100644 --- a/config/common_base +++ b/config/common_base @@ -135,6 +135,17 @@ CONFIG_RTE_ETHDEV_RXTX_CALLBACKS=y CONFIG_RTE_NIC_BYPASS=n # +# Compile burst-oriented Amazon ENA PMD driver +# +CONFIG_RTE_LIBRTE_ENA_PMD=y +CONFIG_RTE_LIBRTE_ENA_DEBUG_INIT=y +CONFIG_RTE_LIBRTE_ENA_DEBUG_RX=n +CONFIG_RTE_LIBRTE_ENA_DEBUG_TX=n +CONFIG_RTE_LIBRTE_ENA_DEBUG_TX_FREE=n +CONFIG_RTE_LIBRTE_ENA_DEBUG_DRIVER=n +CONFIG_RTE_LIBRTE_ENA_COM_DEBUG=n + +# # Compile burst-oriented IGB & EM PMD drivers # CONFIG_RTE_LIBRTE_EM_PMD=y diff --git a/drivers/net/Makefile b/drivers/net/Makefile index 0c3393f..612e85e 100644 --- a/drivers/net/Makefile +++ b/drivers/net/Makefile @@ -36,6 +36,7 @@ DIRS-$(CONFIG_RTE_LIBRTE_BNX2X_PMD) += bnx2x DIRS-$(CONFIG_RTE_LIBRTE_PMD_BOND) += bonding DIRS-$(CONFIG_RTE_LIBRTE_CXGBE_PMD) += cxgbe DIRS-$(CONFIG_RTE_LIBRTE_E1000_PMD) += e1000 +DIRS-$(CONFIG_RTE_LIBRTE_ENA_PMD) += ena DIRS-$(CONFIG_RTE_LIBRTE_ENIC_PMD) += enic DIRS-$(CONFIG_RTE_LIBRTE_FM10K_PMD) += fm10k DIRS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e diff --git a/drivers/net/ena/Makefile b/drivers/net/ena/Makefile new file mode 100644 index 000..ac2b55d --- /dev/null +++ b/drivers/net/ena/Makefile @@ -0,0 +1,61 @@ +# +# BSD LICENSE +# +# Copyright (c) 2015-2016 Amazon.com, Inc. or its affiliates. +# All rights reserved. +# +# Redistribution and use in source and binary forms, with or without +# modification, are permitted provided that the following conditions +# are met: +# +# * Redistributions of source code must retain the above copyright +# notice, this list of conditions and the following disclaimer. +# * Redistributions in binary form must reproduce the above copyright +# notice, this list of conditions and the following disclaimer in +# the documentation and/or other materials provided with the +# distribution. +# * Neither the name of copyright holder nor the names of its +# contributors may be used to endorse or promote products derived +# from this software without specific prior written permission. +# +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS +# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT +# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR +# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT +# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, +# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT +# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, +# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY +# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT +# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE +# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. +# + +include $(RTE_SDK)/mk/rte.vars.mk + +# +# library name +# +LIB = librte_pmd_ena.a +CFLAGS += $(WERROR_FLAGS) -O2 +INCLUDES :=-I$(SRCDIR) -I$(SRCDIR)/base/ena_defs -I$(SRCDIR)/base + +EXPORT_MAP := rte_pmd_ena_version.map +LIBABIVER := 1 + +VPATH += $(SRCDIR)/base +# +# all source are stored in SRCS-y +# +SRCS-$(CONFIG_RTE_LIBRTE_ENA_PMD) += ena_ethdev.c +SRCS-$(CONFIG_RTE_LIBRTE_ENA_PMD) += ena_com.c +SRCS-$(CONFIG_RTE_LIBRTE_ENA_PMD) += ena_eth_com.c + +# this lib depends upon: +DEPDIRS-$(CONFIG_RTE_LIBRTE_ENA_PMD) += lib/librte_eal lib/librte_ether +DEPDIRS-$(CONFIG_RTE_LIBRTE_ENA_PMD) += lib/librte_mempool lib/librte_mbuf +DEPDIRS-$(CONFIG_RTE_LIBRTE_ENA_PMD) += lib/librte_net lib/librte_malloc + +CFLAGS += $(INCLUDES) + +include $(RTE_SDK)/mk/rte.lib.mk diff --git a/drivers/net/ena/ena_ethdev.c b/drivers/net/ena/ena_ethdev.c new file mode 100644 index 000..6e04957 --- /dev/null +++ b/drivers/net/ena/ena_ethdev.c @@ -0,0 +1,1445 @@ +/*
[dpdk-dev] [PATCH v6 3/4] ena: Amazon ENA communication layer for DPDK platform
> +#ifndef unlikely
> +#define unlikely(c) __builtin_expect(!!(c), 0)
> +#endif
> +#ifndef likely
> +#define likely(c) __builtin_expect(!!(c), 1)
> +#endif
Including lib/librte_eal/common/include/rte_branch_prediction.h should
be enough.
> +#define max_t(type, x, y) ({ \
> + type __max1 = (x); \
> + type __max2 = (y); \
> + __max1 > __max2 ? __max1 : __max2; })
> +
> +#define min_t(type, x, y) ({ \
> + type __min1 = (x); \
> + type __min2 = (y); \
> + __min1 < __min2 ? __min1 : __min2; })
> +
> +#define ENA_MAX32(x, y) max_t(u32, (x), (y))
> +#define ENA_MAX16(x, y) max_t(u16, (x), (y))
> +#define ENA_MAX8(x, y) max_t(u8, (x), (y))
> +#define ENA_MIN32(x, y) min_t(u32, (x), (y))
> +#define ENA_MIN16(x, y) min_t(u16, (x), (y))
> +#define ENA_MIN8(x, y) min_t(u8, (x), (y))
There are RTE_MIN and RTE_MAX in lib/librte_eal/common/include/rte_common.h.
[dpdk-dev] [PATCH v10 0/8] ethdev: 100G and link speed API refactoring
Re-spin of the Marc's patchset. The first version was sent 10 months ago! There are still too few tests and reviews but it is now time to move forward with this rework. Some issues were remaining in v9 and were difficult to see because it was mainly one big patch. That's why I've split it in several steps and fixed/reworked some pieces. There will be an exception to integrate this feature in 16.04-rc2. Please test and review shortly, thanks! This series of patches adds the following capabilities: * speed_capa bitmap in rte_eth_dev_info, which is filled by the PMDs according to the physical device capabilities. * refactors link API in ethdev to allow the definition of the advertised link speeds, fix speed (no auto-negociation) or advertise all supported speeds (default). WARNING: this patch series, specifically the patch 6/8, is NOT tested for most of the drivers. Reviewing and testing are required by PMD maintainers. Marc Sune (6): ethdev: use constants for link duplex app/testpmd: move speed and duplex parsing in a function ethdev: rename link speed constants ethdev: add speed capabilities ethdev: redesign link speed config ethdev: convert speed number to bitmap flag Thomas Monjalon (2): ethdev: use constants for link state ethdev: add 100G link speed v10: - rebase - rework release notes - rearrange patch splitting - fix doxygen comments - fix typos - removed log format of link.link_speed as %d (keep %u) - complete ETH_LINK_[DOWN/UP] replacement from 0/1 - change ETH_LINK_SPEED_AUTONEG to 1 - replace ETH_LINK_SPEED_NEG by ETH_LINK_SPEED_AUTONEG (1) - replace ETH_LINK_SPEED_NO_AUTONEG by ETH_LINK_SPEED_FIXED (0) - rework rte_eth_speed_to_bm_flag to rte_eth_speed_bitflag - complete 100G support in testpmd v9: rebased to current HEAD. Reverted numeric speed to 32 bit in struct rte_eth_link (no atomic link get > 64bit). Fixed mlx5 driver compilation and link speeds. Moved documentation to release_16_04.rst and fixed several issues. Upgrade NIC notes with speed capabilities. v8: Rebased to current HEAD. Modified em driver impl. to not touch base files. Merged patch 5 into 3 (map file). Changed numeric speed to a 64 bit value. Filled-in speed capabilities for drivers bnx2x, cxgbe, mlx5 and nfp in addition to the ones of previous patch sets. v7: Rebased to current HEAD. Moved documentation to v2.3. Still needs testing from PMD maintainers. v6: Move link_duplex to be part of bitfield. Fixed i40 autoneg flag link update code. Added rte_eth_speed_to_bm_flag() to .map file. Fixed other spelling issues. Rebased to current HEAD. v5: revert to v2 speed capabilities patch. Fixed MLX4 speed capabilities (thanks N. Laranjeiro). Refactored link speed API to allow setting advertised speeds (3/4). Added NO_AUTONEG option to explicitely disable auto-negociation. Updated 2.2 rel. notes (4/4). Rebased to current HEAD. v4: fixed errata in the documentation of field speeds of rte_eth_conf, and commit 1/2 message. rebased to v2.1.0. v3 was incorrectly based on ~2.1.0-rc1. v3: rebase to v2.1. unified ETH_LINK_SPEED and ETH_SPEED_CAP into ETH_SPEED. Converted field speed in struct rte_eth_conf to speed, to allow a bitmap for defining the announced speeds, as suggested M. Brorup. Fixed spelling issues. v2: rebase, converted speed_capa into 32 bits bitmap, fixed alignment (checkpatch). app/test-pipeline/init.c | 2 +- app/test-pmd/cmdline.c | 125 ++--- app/test-pmd/testpmd.c | 2 +- app/test/test_pmd_perf.c | 2 +- app/test/virtual_pmd.c | 8 +- doc/guides/nics/overview.rst | 1 + doc/guides/rel_notes/release_16_04.rst | 22 doc/guides/testpmd_app_ug/testpmd_funcs.rst| 2 +- drivers/net/af_packet/rte_eth_af_packet.c | 9 +- drivers/net/bnx2x/bnx2x_ethdev.c | 7 +- drivers/net/bnx2x/elink.c | 2 +- drivers/net/bonding/rte_eth_bond_8023ad.c | 14 +-- drivers/net/bonding/rte_eth_bond_api.c | 4 +- drivers/net/bonding/rte_eth_bond_pmd.c | 12 +- drivers/net/cxgbe/base/t4_hw.c | 8 +- drivers/net/cxgbe/cxgbe_ethdev.c | 1 + drivers/net/e1000/em_ethdev.c | 111 +- drivers/net/e1000/igb_ethdev.c | 104 + drivers/net/fm10k/fm10k_ethdev.c | 6 +- drivers/net/i40e/i40e_ethdev.c | 76 +++-- drivers/net/i40e/i40e_ethdev_vf.c | 11 +- drivers/net/ixgbe/ixgbe_ethdev.c | 76 ++--- drivers/net/mlx4/mlx4.c| 4 + drivers/net/mlx5/mlx5_ethde
[dpdk-dev] [PATCH v10 1/8] ethdev: use constants for link state
Define and use ETH_LINK_UP and ETH_LINK_DOWN where appropriate.
Signed-off-by: Marc Sune
Signed-off-by: Thomas Monjalon
---
app/test-pipeline/init.c | 2 +-
app/test-pmd/testpmd.c | 2 +-
app/test/test_pmd_perf.c | 2 +-
app/test/virtual_pmd.c | 6 +++---
drivers/net/af_packet/rte_eth_af_packet.c| 6 +++---
drivers/net/bnx2x/bnx2x_ethdev.c | 2 +-
drivers/net/bnx2x/elink.c| 2 +-
drivers/net/bonding/rte_eth_bond_api.c | 4 ++--
drivers/net/bonding/rte_eth_bond_pmd.c | 12 ++--
drivers/net/e1000/em_ethdev.c| 6 +++---
drivers/net/e1000/igb_ethdev.c | 4 ++--
drivers/net/fm10k/fm10k_ethdev.c | 2 +-
drivers/net/i40e/i40e_ethdev_vf.c| 2 +-
drivers/net/ixgbe/ixgbe_ethdev.c | 4 ++--
drivers/net/mpipe/mpipe_tilegx.c | 12 ++--
drivers/net/nfp/nfp_net.c| 2 +-
drivers/net/null/rte_eth_null.c | 6 +++---
drivers/net/pcap/rte_eth_pcap.c | 6 +++---
drivers/net/ring/rte_eth_ring.c | 10 +-
drivers/net/szedata2/rte_eth_szedata2.c | 6 +++---
drivers/net/virtio/virtio_ethdev.c | 6 +++---
drivers/net/vmxnet3/vmxnet3_ethdev.c | 2 +-
drivers/net/xenvirt/rte_eth_xenvirt.c| 6 +++---
examples/exception_path/main.c | 2 +-
examples/ip_fragmentation/main.c | 2 +-
examples/ip_pipeline/init.c | 2 +-
examples/ip_reassembly/main.c| 2 +-
examples/ipsec-secgw/ipsec-secgw.c | 2 +-
examples/ipv4_multicast/main.c | 2 +-
examples/kni/main.c | 2 +-
examples/l2fwd-crypto/main.c | 2 +-
examples/l2fwd-ivshmem/host/host.c | 2 +-
examples/l2fwd-jobstats/main.c | 2 +-
examples/l2fwd-keepalive/main.c | 2 +-
examples/l2fwd/main.c| 2 +-
examples/l3fwd-acl/main.c| 2 +-
examples/l3fwd-power/main.c | 2 +-
examples/l3fwd/main.c| 2 +-
examples/link_status_interrupt/main.c| 2 +-
examples/load_balancer/init.c| 2 +-
examples/multi_process/client_server_mp/mp_server/init.c | 2 +-
examples/multi_process/l2fwd_fork/main.c | 2 +-
examples/multi_process/symmetric_mp/main.c | 2 +-
examples/performance-thread/l3fwd-thread/main.c | 2 +-
lib/librte_ether/rte_ethdev.h| 5 -
45 files changed, 81 insertions(+), 78 deletions(-)
diff --git a/app/test-pipeline/init.c b/app/test-pipeline/init.c
index db2196b..aef082f 100644
--- a/app/test-pipeline/init.c
+++ b/app/test-pipeline/init.c
@@ -205,7 +205,7 @@ app_ports_check_link(void)
link.link_speed / 1000,
link.link_status ? "UP" : "DOWN");
- if (link.link_status == 0)
+ if (link.link_status == ETH_LINK_DOWN)
all_ports_up = 0;
}
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 38b9051..f713f39 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -1641,7 +1641,7 @@ check_all_ports_link_status(uint32_t port_mask)
continue;
}
/* clear all_ports_up flag if any link down */
- if (link.link_status == 0) {
+ if (link.link_status == ETH_LINK_DOWN) {
all_ports_up = 0;
break;
}
diff --git a/app/test/test_pmd_perf.c b/app/test/test_pmd_perf.c
index 48e16c9..59803f7 100644
--- a/app/test/test_pmd_perf.c
+++ b/app/test/test_pmd_perf.c
@@ -192,7 +192,7 @@ check_all_ports_link_status(uint8_t port_num, uint32_t
port_mask)
continue;
}
/* clear all_ports_up flag if any link down */
- if (link.link_status == 0) {
+ if (link.link_status == ETH_LINK_DOWN) {
all_ports_up = 0;
break;
}
diff --git a/app/test/virtual_pmd.c b/app/test/virtual_pmd.c
index a538c8a..b1d40d7 100644
--- a/app/test/vir
[dpdk-dev] [PATCH v10 2/8] ethdev: use constants for link duplex
From: Marc Sune
Some duplex values are replaced from 0 to half-duplex when link is down.
Some drivers are still using their own constants for duplex modes.
Signed-off-by: Marc Sune
---
drivers/net/e1000/em_ethdev.c | 2 +-
drivers/net/e1000/igb_ethdev.c | 2 +-
drivers/net/ixgbe/ixgbe_ethdev.c | 2 +-
drivers/net/virtio/virtio_ethdev.c | 2 +-
drivers/net/virtio/virtio_ethdev.h | 2 --
lib/librte_ether/rte_ethdev.h | 2 +-
6 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/net/e1000/em_ethdev.c b/drivers/net/e1000/em_ethdev.c
index 58f9c7a..2f3529f 100644
--- a/drivers/net/e1000/em_ethdev.c
+++ b/drivers/net/e1000/em_ethdev.c
@@ -1076,7 +1076,7 @@ eth_em_link_update(struct rte_eth_dev *dev, int
wait_to_complete)
link.link_status = ETH_LINK_UP;
} else if (!link_check && (link.link_status == ETH_LINK_UP)) {
link.link_speed = 0;
- link.link_duplex = 0;
+ link.link_duplex = ETH_LINK_HALF_DUPLEX;
link.link_status = ETH_LINK_DOWN;
}
rte_em_dev_atomic_write_link_status(dev, &link);
diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index 614d8cb..0e58fa9 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -2024,7 +2024,7 @@ eth_igb_link_update(struct rte_eth_dev *dev, int
wait_to_complete)
link.link_status = ETH_LINK_UP;
} else if (!link_check) {
link.link_speed = 0;
- link.link_duplex = 0;
+ link.link_duplex = ETH_LINK_HALF_DUPLEX;
link.link_status = ETH_LINK_DOWN;
}
rte_igb_dev_atomic_write_link_status(dev, &link);
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 62a8dff..99c55bd 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -2959,7 +2959,7 @@ ixgbe_dev_link_update(struct rte_eth_dev *dev, int
wait_to_complete)
link.link_status = ETH_LINK_DOWN;
link.link_speed = 0;
- link.link_duplex = 0;
+ link.link_duplex = ETH_LINK_HALF_DUPLEX;
memset(&old, 0, sizeof(old));
rte_ixgbe_dev_atomic_read_link_status(dev, &old);
diff --git a/drivers/net/virtio/virtio_ethdev.c
b/drivers/net/virtio/virtio_ethdev.c
index 76a0faf..aa5ae10 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -1383,7 +1383,7 @@ virtio_dev_link_update(struct rte_eth_dev *dev,
__rte_unused int wait_to_complet
memset(&link, 0, sizeof(link));
virtio_dev_atomic_read_link_status(dev, &link);
old = link;
- link.link_duplex = FULL_DUPLEX;
+ link.link_duplex = ETH_LINK_FULL_DUPLEX;
link.link_speed = SPEED_10G;
if (vtpci_with_feature(hw, VIRTIO_NET_F_STATUS)) {
diff --git a/drivers/net/virtio/virtio_ethdev.h
b/drivers/net/virtio/virtio_ethdev.h
index fed9571..66423a0 100644
--- a/drivers/net/virtio/virtio_ethdev.h
+++ b/drivers/net/virtio/virtio_ethdev.h
@@ -42,8 +42,6 @@
#define SPEED_100 100
#define SPEED_1000 1000
#define SPEED_10G 1
-#define HALF_DUPLEX1
-#define FULL_DUPLEX2
#ifndef PAGE_SIZE
#define PAGE_SIZE 4096
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 6704a82..12b552d 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -246,7 +246,7 @@ struct rte_eth_stats {
*/
struct rte_eth_link {
uint16_t link_speed; /**< ETH_LINK_SPEED_[10, 100, 1000, 1] */
- uint16_t link_duplex; /**< ETH_LINK_[HALF_DUPLEX, FULL_DUPLEX] */
+ uint16_t link_duplex; /**< ETH_LINK_[HALF/FULL]_DUPLEX */
uint8_t link_status : 1; /**< ETH_LINK_[DOWN/UP] */
}__attribute__((aligned(8))); /**< aligned for atomic64 read/write */
--
2.7.0
[dpdk-dev] [PATCH v10 3/8] app/testpmd: move speed and duplex parsing in a function
From: Marc Sune
The code for checking and parsing speed/duplex was duplicated.
The new function is also checking the speed/duplex combination.
Signed-off-by: Marc Sune
---
app/test-pmd/cmdline.c | 99 --
1 file changed, 47 insertions(+), 52 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 9d52b8c..37be5cd 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -983,6 +983,49 @@ struct cmd_config_speed_all {
cmdline_fixed_string_t value2;
};
+static int
+parse_and_check_speed_duplex(char *speedstr, char *duplexstr, uint16_t *speed)
+{
+
+ int duplex;
+
+ if (!strcmp(duplexstr, "half")) {
+ duplex = ETH_LINK_HALF_DUPLEX;
+ } else if (!strcmp(duplexstr, "full")) {
+ duplex = ETH_LINK_FULL_DUPLEX;
+ } else if (!strcmp(duplexstr, "auto")) {
+ duplex = ETH_LINK_FULL_DUPLEX;
+ } else {
+ printf("Unknown duplex parameter\n");
+ return -1;
+ }
+
+ if (!strcmp(speedstr, "10")) {
+ *speed = ETH_LINK_SPEED_10;
+ } else if (!strcmp(speedstr, "100")) {
+ *speed = ETH_LINK_SPEED_100;
+ } else {
+ if (duplex != ETH_LINK_FULL_DUPLEX) {
+ printf("Invalid speed/duplex parameters\n");
+ return -1;
+ }
+ if (!strcmp(speedstr, "1000")) {
+ *speed = ETH_LINK_SPEED_1000;
+ } else if (!strcmp(speedstr, "1")) {
+ *speed = ETH_LINK_SPEED_10G;
+ } else if (!strcmp(speedstr, "4")) {
+ *speed = ETH_LINK_SPEED_40G;
+ } else if (!strcmp(speedstr, "auto")) {
+ *speed = ETH_LINK_SPEED_AUTONEG;
+ } else {
+ printf("Unknown speed parameter\n");
+ return -1;
+ }
+ }
+
+ return 0;
+}
+
static void
cmd_config_speed_all_parsed(void *parsed_result,
__attribute__((unused)) struct cmdline *cl,
@@ -998,33 +1041,9 @@ cmd_config_speed_all_parsed(void *parsed_result,
return;
}
- if (!strcmp(res->value1, "10"))
- link_speed = ETH_LINK_SPEED_10;
- else if (!strcmp(res->value1, "100"))
- link_speed = ETH_LINK_SPEED_100;
- else if (!strcmp(res->value1, "1000"))
- link_speed = ETH_LINK_SPEED_1000;
- else if (!strcmp(res->value1, "1"))
- link_speed = ETH_LINK_SPEED_10G;
- else if (!strcmp(res->value1, "4"))
- link_speed = ETH_LINK_SPEED_40G;
- else if (!strcmp(res->value1, "auto"))
- link_speed = ETH_LINK_SPEED_AUTONEG;
- else {
- printf("Unknown parameter\n");
+ if (parse_and_check_speed_duplex(res->value1, res->value2,
+ &link_speed) < 0)
return;
- }
-
- if (!strcmp(res->value2, "half"))
- link_duplex = ETH_LINK_HALF_DUPLEX;
- else if (!strcmp(res->value2, "full"))
- link_duplex = ETH_LINK_FULL_DUPLEX;
- else if (!strcmp(res->value2, "auto"))
- link_duplex = ETH_LINK_AUTONEG_DUPLEX;
- else {
- printf("Unknown parameter\n");
- return;
- }
FOREACH_PORT(pid, ports) {
ports[pid].dev_conf.link_speed = link_speed;
@@ -1097,33 +1116,9 @@ cmd_config_speed_specific_parsed(void *parsed_result,
if (port_id_is_invalid(res->id, ENABLED_WARN))
return;
- if (!strcmp(res->value1, "10"))
- link_speed = ETH_LINK_SPEED_10;
- else if (!strcmp(res->value1, "100"))
- link_speed = ETH_LINK_SPEED_100;
- else if (!strcmp(res->value1, "1000"))
- link_speed = ETH_LINK_SPEED_1000;
- else if (!strcmp(res->value1, "1"))
- link_speed = ETH_LINK_SPEED_1;
- else if (!strcmp(res->value1, "4"))
- link_speed = ETH_LINK_SPEED_40G;
- else if (!strcmp(res->value1, "auto"))
- link_speed = ETH_LINK_SPEED_AUTONEG;
- else {
- printf("Unknown parameter\n");
- return;
- }
-
- if (!strcmp(res->value2, "half"))
- link_duplex = ETH_LINK_HALF_DUPLEX;
- else if (!strcmp(res->value2, "full"))
- link_duplex = ETH_LINK_FULL_DUPLEX;
- else if (!strcmp(res->value2, "auto"))
- link_duplex = ETH_LINK_AUTONEG_DUPLEX;
- else {
- printf("Unknown parameter\n");
+ if (parse_and_check_speed_duplex(res->value1, res->value2,
+ &link_speed) < 0)
return;
- }
ports[res->id].dev_conf.link_speed = link_speed;
ports[res->id].dev_conf.link_duplex = link_duplex;
--
2
[dpdk-dev] [PATCH v10 4/8] ethdev: rename link speed constants
From: Marc Sune
The speed numbers ETH_LINK_SPEED_ are renamed ETH_SPEED_NUM_.
The prefix ETH_LINK_SPEED_ is kept for AUTONEG and will be used
for bit flags in next patch.
Signed-off-by: Marc Sune
---
app/test-pmd/cmdline.c| 10 +-
app/test/virtual_pmd.c| 2 +-
drivers/net/af_packet/rte_eth_af_packet.c | 2 +-
drivers/net/bonding/rte_eth_bond_8023ad.c | 12 ++--
drivers/net/cxgbe/base/t4_hw.c| 8
drivers/net/e1000/em_ethdev.c | 8
drivers/net/e1000/igb_ethdev.c| 8
drivers/net/i40e/i40e_ethdev.c| 30 +++---
drivers/net/i40e/i40e_ethdev_vf.c | 2 +-
drivers/net/ixgbe/ixgbe_ethdev.c | 22 +++---
drivers/net/mpipe/mpipe_tilegx.c | 4 ++--
drivers/net/nfp/nfp_net.c | 2 +-
drivers/net/null/rte_eth_null.c | 2 +-
drivers/net/pcap/rte_eth_pcap.c | 2 +-
drivers/net/ring/rte_eth_ring.c | 2 +-
drivers/net/szedata2/rte_eth_szedata2.c | 2 +-
drivers/net/vmxnet3/vmxnet3_ethdev.c | 2 +-
drivers/net/xenvirt/rte_eth_xenvirt.c | 2 +-
lib/librte_ether/rte_ethdev.h | 29 ++---
19 files changed, 79 insertions(+), 72 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 37be5cd..874129a 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -1001,20 +1001,20 @@ parse_and_check_speed_duplex(char *speedstr, char
*duplexstr, uint16_t *speed)
}
if (!strcmp(speedstr, "10")) {
- *speed = ETH_LINK_SPEED_10;
+ *speed = ETH_SPEED_NUM_10M;
} else if (!strcmp(speedstr, "100")) {
- *speed = ETH_LINK_SPEED_100;
+ *speed = ETH_SPEED_NUM_100M;
} else {
if (duplex != ETH_LINK_FULL_DUPLEX) {
printf("Invalid speed/duplex parameters\n");
return -1;
}
if (!strcmp(speedstr, "1000")) {
- *speed = ETH_LINK_SPEED_1000;
+ *speed = ETH_SPEED_NUM_1G;
} else if (!strcmp(speedstr, "1")) {
- *speed = ETH_LINK_SPEED_10G;
+ *speed = ETH_SPEED_NUM_10G;
} else if (!strcmp(speedstr, "4")) {
- *speed = ETH_LINK_SPEED_40G;
+ *speed = ETH_SPEED_NUM_40G;
} else if (!strcmp(speedstr, "auto")) {
*speed = ETH_LINK_SPEED_AUTONEG;
} else {
diff --git a/app/test/virtual_pmd.c b/app/test/virtual_pmd.c
index b1d40d7..b4bd2f2 100644
--- a/app/test/virtual_pmd.c
+++ b/app/test/virtual_pmd.c
@@ -604,7 +604,7 @@ virtual_ethdev_create(const char *name, struct ether_addr
*mac_addr,
TAILQ_INIT(&(eth_dev->link_intr_cbs));
eth_dev->data->dev_link.link_status = ETH_LINK_DOWN;
- eth_dev->data->dev_link.link_speed = ETH_LINK_SPEED_1;
+ eth_dev->data->dev_link.link_speed = ETH_SPEED_NUM_10G;
eth_dev->data->dev_link.link_duplex = ETH_LINK_FULL_DUPLEX;
eth_dev->data->mac_addrs = rte_zmalloc(name, ETHER_ADDR_LEN, 0);
diff --git a/drivers/net/af_packet/rte_eth_af_packet.c
b/drivers/net/af_packet/rte_eth_af_packet.c
index 24f909f..ff0d299 100644
--- a/drivers/net/af_packet/rte_eth_af_packet.c
+++ b/drivers/net/af_packet/rte_eth_af_packet.c
@@ -116,7 +116,7 @@ static const char *valid_arguments[] = {
static const char *drivername = "AF_PACKET PMD";
static struct rte_eth_link pmd_link = {
- .link_speed = 1,
+ .link_speed = ETH_SPEED_NUM_10G,
.link_duplex = ETH_LINK_FULL_DUPLEX,
.link_status = ETH_LINK_DOWN,
};
diff --git a/drivers/net/bonding/rte_eth_bond_8023ad.c
b/drivers/net/bonding/rte_eth_bond_8023ad.c
index b3b30f6..5f9c9b3 100644
--- a/drivers/net/bonding/rte_eth_bond_8023ad.c
+++ b/drivers/net/bonding/rte_eth_bond_8023ad.c
@@ -711,22 +711,22 @@ link_speed_key(uint16_t speed) {
case ETH_LINK_SPEED_AUTONEG:
key_speed = 0x00;
break;
- case ETH_LINK_SPEED_10:
+ case ETH_SPEED_NUM_10M:
key_speed = BOND_LINK_SPEED_KEY_10M;
break;
- case ETH_LINK_SPEED_100:
+ case ETH_SPEED_NUM_100M:
key_speed = BOND_LINK_SPEED_KEY_100M;
break;
- case ETH_LINK_SPEED_1000:
+ case ETH_SPEED_NUM_1G:
key_speed = BOND_LINK_SPEED_KEY_1000M;
break;
- case ETH_LINK_SPEED_10G:
+ case ETH_SPEED_NUM_10G:
key_speed = BOND_LINK_SPEED_KEY_10G;
break;
- case ETH_LINK_SPEED_20G:
+ case ETH_SPEED_NUM_20G:
key_speed = BOND_LINK_SPEED_KEY_20G;
break;
- case ETH_LINK_SPEED_40G:
+ case ETH_SPEED_NUM_40G:
k
[dpdk-dev] [PATCH v10 5/8] ethdev: add speed capabilities
From: Marc Sune The speed capabilities of a device can be retrieved with rte_eth_dev_info_get(). The new field speed_capa is initialized in the drivers without taking care of device characteristics in this patch. When the capabilities of a driver are accurate, the table in overview.rst must be filled. Signed-off-by: Marc Sune --- doc/guides/nics/overview.rst | 1 + doc/guides/rel_notes/release_16_04.rst | 8 drivers/net/bnx2x/bnx2x_ethdev.c | 1 + drivers/net/cxgbe/cxgbe_ethdev.c | 1 + drivers/net/e1000/em_ethdev.c | 4 drivers/net/e1000/igb_ethdev.c | 4 drivers/net/fm10k/fm10k_ethdev.c | 4 drivers/net/i40e/i40e_ethdev.c | 8 drivers/net/ixgbe/ixgbe_ethdev.c | 8 drivers/net/mlx4/mlx4.c| 2 ++ drivers/net/mlx5/mlx5_ethdev.c | 3 +++ drivers/net/nfp/nfp_net.c | 2 ++ lib/librte_ether/rte_ethdev.h | 21 + 13 files changed, 67 insertions(+) diff --git a/doc/guides/nics/overview.rst b/doc/guides/nics/overview.rst index 2d4f014..893da5f 100644 --- a/doc/guides/nics/overview.rst +++ b/doc/guides/nics/overview.rst @@ -88,6 +88,7 @@ Most of these differences are summarized below. = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = link status X X X X link status event X X + speed capabilities Rx interrupt X X X X queue start/stop X X X X X X MTU update X diff --git a/doc/guides/rel_notes/release_16_04.rst b/doc/guides/rel_notes/release_16_04.rst index b729b67..fd24a6f 100644 --- a/doc/guides/rel_notes/release_16_04.rst +++ b/doc/guides/rel_notes/release_16_04.rst @@ -47,6 +47,11 @@ This section should contain new features added in this release. Sample format: A new function ``rte_pktmbuf_alloc_bulk()`` has been added to allow the user to allocate a bulk of mbufs. +* **Added device link speed capabilities.** + + The structure ``rte_eth_dev_info`` has now a ``speed_capa`` bitmap, which + allows the application to know the supported speeds of each device. + * **Virtio 1.0.** Enabled virtio 1.0 support for virtio pmd driver. @@ -208,6 +213,9 @@ This section should contain API changes. Sample format: * Add a short 1-2 sentence description of the API change. Use fixed width quotes for ``rte_function_names`` or ``rte_struct_names``. Use the past tense. +* The ethdev structure ``rte_eth_dev_info`` was changed to support device + speed capabilities. + * The functions ``rte_eth_dev_udp_tunnel_add`` and ``rte_eth_dev_udp_tunnel_delete`` have been renamed into ``rte_eth_dev_udp_tunnel_port_add`` and ``rte_eth_dev_udp_tunnel_port_delete``. diff --git a/drivers/net/bnx2x/bnx2x_ethdev.c b/drivers/net/bnx2x/bnx2x_ethdev.c index f109900..b86784e 100644 --- a/drivers/net/bnx2x/bnx2x_ethdev.c +++ b/drivers/net/bnx2x/bnx2x_ethdev.c @@ -347,6 +347,7 @@ bnx2x_dev_infos_get(struct rte_eth_dev *dev, __rte_unused struct rte_eth_dev_inf dev_info->min_rx_bufsize = BNX2X_MIN_RX_BUF_SIZE; dev_info->max_rx_pktlen = BNX2X_MAX_RX_PKT_LEN; dev_info->max_mac_addrs = BNX2X_MAX_MAC_ADDRS; + dev_info->speed_capa = ETH_LINK_SPEED_10G | ETH_LINK_SPEED_20G; } static void diff --git a/drivers/net/cxgbe/cxgbe_ethdev.c b/drivers/net/cxgbe/cxgbe_ethdev.c index 97ef152..05b954d 100644 --- a/drivers/net/cxgbe/cxgbe_ethdev.c +++ b/drivers/net/cxgbe/cxgbe_ethdev.c @@ -171,6 +171,7 @@ static void cxgbe_dev_info_get(struct rte_eth_dev *eth_dev, device_info->rx_desc_lim = cxgbe_desc_lim; device_info->tx_desc_lim = cxgbe_desc_lim; + device_info->speed_capa = ETH_LINK_SPEED_10G | ETH_LINK_SPEED_40G; } static void cxgbe_dev_promiscuous_enable(struct rte_eth_dev *eth_dev) diff --git a/drivers/net/e1000/em_ethdev.c b/drivers/net/e1000/em_ethdev.c index 84845e7..ddd 100644 --- a/drivers/net/e1000/em_ethdev.c +++ b/drivers/net/e1000/em_ethdev.c @@ -1023,6 +1023,10 @@ eth_em_infos_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info) .nb_min = E1000_MIN_RING_DESC, .nb_align = EM_TXD_ALIGN, }; + + dev_info->speed_capa = ETH_LINK_SPEED_10M_HD | ETH_LINK_SPEED_10M | + ETH_LINK_SPEED_100M_HD | ETH_LINK_SPEED_100M | + ETH_LINK_SPEED_1G; } /* return 0 means link status changed, -1 means not changed */ diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c index b4c8982..743fe1b 100644 --- a/drivers/net/e1000/igb_ethdev.c +++ b/drivers/net/e1000/igb_ethdev.c @@ -1910,6 +1910,10 @@ eth_igb_infos_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info) dev_info->rx_desc_lim = rx_desc_lim; dev_info->tx_desc_lim = tx_desc_lim; + + dev_i
[dpdk-dev] [PATCH v10 6/8] ethdev: redesign link speed config
From: Marc Sune
This patch redesigns the API to set the link speed/s configuration
of an ethernet port. Specifically:
- it allows to define a set of advertised speeds for
auto-negociation.
- it allows to disable link auto-negociation (single fixed speed).
- default: auto-negociate all supported speeds.
A flag autoneg in struct rte_eth_link indicates if link speed was a
result of auto-negociation or was fixed by configuration.
Signed-off-by: Marc Sune
Tested-by: Nelio Laranjeiro
Signed-off-by: Thomas Monjalon
---
PLEASE REVIEW CAREFULLY THIS PATCH
app/test-pmd/cmdline.c| 26
doc/guides/rel_notes/release_16_04.rst| 9 +++
drivers/net/af_packet/rte_eth_af_packet.c | 1 +
drivers/net/bnx2x/bnx2x_ethdev.c | 4 +-
drivers/net/bonding/rte_eth_bond_8023ad.c | 2 +-
drivers/net/e1000/em_ethdev.c | 99 +++
drivers/net/e1000/igb_ethdev.c| 94 +++--
drivers/net/i40e/i40e_ethdev.c| 48 +++
drivers/net/i40e/i40e_ethdev_vf.c | 7 ++-
drivers/net/ixgbe/ixgbe_ethdev.c | 46 ++
drivers/net/mlx4/mlx4.c | 2 +
drivers/net/mpipe/mpipe_tilegx.c | 2 +
drivers/net/null/rte_eth_null.c | 1 +
drivers/net/pcap/rte_eth_pcap.c | 1 +
drivers/net/ring/rte_eth_ring.c | 1 +
drivers/net/szedata2/rte_eth_szedata2.c | 2 +-
drivers/net/vmxnet3/vmxnet3_ethdev.c | 1 +
drivers/net/xenvirt/rte_eth_xenvirt.c | 1 +
examples/ip_pipeline/config_parse.c | 3 +-
lib/librte_ether/rte_ethdev.h | 29 +
20 files changed, 195 insertions(+), 184 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 874129a..3bc7bb4 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -984,7 +984,7 @@ struct cmd_config_speed_all {
};
static int
-parse_and_check_speed_duplex(char *speedstr, char *duplexstr, uint16_t *speed)
+parse_and_check_speed_duplex(char *speedstr, char *duplexstr, uint32_t *speed)
{
int duplex;
@@ -1001,20 +1001,22 @@ parse_and_check_speed_duplex(char *speedstr, char
*duplexstr, uint16_t *speed)
}
if (!strcmp(speedstr, "10")) {
- *speed = ETH_SPEED_NUM_10M;
+ *speed = (duplex == ETH_LINK_HALF_DUPLEX) ?
+ ETH_LINK_SPEED_10M_HD : ETH_LINK_SPEED_10M;
} else if (!strcmp(speedstr, "100")) {
- *speed = ETH_SPEED_NUM_100M;
+ *speed = (duplex == ETH_LINK_HALF_DUPLEX) ?
+ ETH_LINK_SPEED_100M_HD : ETH_LINK_SPEED_100M;
} else {
if (duplex != ETH_LINK_FULL_DUPLEX) {
printf("Invalid speed/duplex parameters\n");
return -1;
}
if (!strcmp(speedstr, "1000")) {
- *speed = ETH_SPEED_NUM_1G;
+ *speed = ETH_LINK_SPEED_1G;
} else if (!strcmp(speedstr, "1")) {
- *speed = ETH_SPEED_NUM_10G;
+ *speed = ETH_LINK_SPEED_10G;
} else if (!strcmp(speedstr, "4")) {
- *speed = ETH_SPEED_NUM_40G;
+ *speed = ETH_LINK_SPEED_40G;
} else if (!strcmp(speedstr, "auto")) {
*speed = ETH_LINK_SPEED_AUTONEG;
} else {
@@ -1032,8 +1034,7 @@ cmd_config_speed_all_parsed(void *parsed_result,
__attribute__((unused)) void *data)
{
struct cmd_config_speed_all *res = parsed_result;
- uint16_t link_speed = ETH_LINK_SPEED_AUTONEG;
- uint16_t link_duplex = 0;
+ uint32_t link_speed;
portid_t pid;
if (!all_ports_stopped()) {
@@ -1046,8 +1047,7 @@ cmd_config_speed_all_parsed(void *parsed_result,
return;
FOREACH_PORT(pid, ports) {
- ports[pid].dev_conf.link_speed = link_speed;
- ports[pid].dev_conf.link_duplex = link_duplex;
+ ports[pid].dev_conf.link_speeds = link_speed;
}
cmd_reconfig_device_queue(RTE_PORT_ALL, 1, 1);
@@ -1105,8 +1105,7 @@ cmd_config_speed_specific_parsed(void *parsed_result,
__attribute__((unused)) void *data)
{
struct cmd_config_speed_specific *res = parsed_result;
- uint16_t link_speed = ETH_LINK_SPEED_AUTONEG;
- uint16_t link_duplex = 0;
+ uint32_t link_speed;
if (!all_ports_stopped()) {
printf("Please stop all ports first\n");
@@ -1120,8 +1119,7 @@ cmd_config_speed_specific_parsed(void *parsed_result,
&link_speed) < 0)
return;
- ports[res->id].dev_conf.link_speed = link_speed;
- ports[res->id].dev_conf.link_duplex = link_duplex;
+ ports[res->id].dev_conf.link_speeds = link_speed;
c
[dpdk-dev] [PATCH v10 7/8] ethdev: convert speed number to bitmap flag
From: Marc Sune
It is a helper for the bitmap configuration.
Signed-off-by: Marc Sune
Signed-off-by: Thomas Monjalon
---
lib/librte_ether/rte_ethdev.c | 31 +++
lib/librte_ether/rte_ethdev.h | 13 +
lib/librte_ether/rte_ether_version.map | 1 +
3 files changed, 45 insertions(+)
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index f0e7473..4594f41 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -862,6 +862,37 @@ rte_eth_dev_tx_queue_config(struct rte_eth_dev *dev,
uint16_t nb_queues)
return 0;
}
+uint32_t
+rte_eth_speed_bitflag(uint32_t speed, int duplex)
+{
+ switch (speed) {
+ case ETH_SPEED_NUM_10M:
+ return duplex ? ETH_LINK_SPEED_10M : ETH_LINK_SPEED_10M_HD;
+ case ETH_SPEED_NUM_100M:
+ return duplex ? ETH_LINK_SPEED_100M : ETH_LINK_SPEED_100M_HD;
+ case ETH_SPEED_NUM_1G:
+ return ETH_LINK_SPEED_1G;
+ case ETH_SPEED_NUM_2_5G:
+ return ETH_LINK_SPEED_2_5G;
+ case ETH_SPEED_NUM_5G:
+ return ETH_LINK_SPEED_5G;
+ case ETH_SPEED_NUM_10G:
+ return ETH_LINK_SPEED_10G;
+ case ETH_SPEED_NUM_20G:
+ return ETH_LINK_SPEED_20G;
+ case ETH_SPEED_NUM_25G:
+ return ETH_LINK_SPEED_25G;
+ case ETH_SPEED_NUM_40G:
+ return ETH_LINK_SPEED_40G;
+ case ETH_SPEED_NUM_50G:
+ return ETH_LINK_SPEED_50G;
+ case ETH_SPEED_NUM_56G:
+ return ETH_LINK_SPEED_56G;
+ default:
+ return 0;
+ }
+}
+
int
rte_eth_dev_configure(uint8_t port_id, uint16_t nb_rx_q, uint16_t nb_tx_q,
const struct rte_eth_conf *dev_conf)
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 08881de..5e3bd04 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -1869,6 +1869,19 @@ struct eth_driver {
void rte_eth_driver_register(struct eth_driver *eth_drv);
/**
+ * Convert a numerical speed in Mbps to a bitmap flag that can be used in
+ * the bitmap link_speeds of the struct rte_eth_conf
+ *
+ * @param speed
+ * Numerical speed value in Mbps
+ * @param duplex
+ * ETH_LINK_[HALF/FULL]_DUPLEX (only for 10/100M speeds)
+ * @return
+ * 0 if the speed cannot be mapped
+ */
+uint32_t rte_eth_speed_bitflag(uint32_t speed, int duplex);
+
+/**
* Configure an Ethernet device.
* This function must be invoked first before any other function in the
* Ethernet API. This function can also be re-invoked when a device is in the
diff --git a/lib/librte_ether/rte_ether_version.map
b/lib/librte_ether/rte_ether_version.map
index 5cb4d79..13d9f2e 100644
--- a/lib/librte_ether/rte_ether_version.map
+++ b/lib/librte_ether/rte_ether_version.map
@@ -124,6 +124,7 @@ DPDK_16.04 {
rte_eth_dev_set_vlan_ether_type;
rte_eth_dev_udp_tunnel_port_add;
rte_eth_dev_udp_tunnel_port_delete;
+ rte_eth_speed_bitflag;
rte_eth_tx_buffer_count_callback;
rte_eth_tx_buffer_drop_callback;
rte_eth_tx_buffer_init;
--
2.7.0
[dpdk-dev] [PATCH v10 8/8] ethdev: add 100G link speed
The link speed configuration is now done with bitmaps so 100G speed
requires only a new bit flag.
The actual link speed is a number so its size must be increased from
16-bit to 32-bit.
Signed-off-by: Marc Sune
Tested-by: Nelio Laranjeiro
Signed-off-by: Thomas Monjalon
---
app/test-pmd/cmdline.c | 12 +++-
doc/guides/rel_notes/release_16_04.rst | 5 +
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 2 +-
drivers/net/fm10k/fm10k_ethdev.c| 2 +-
drivers/net/mlx5/mlx5_ethdev.c | 2 +-
drivers/net/nfp/nfp_net.c | 2 +-
drivers/net/szedata2/rte_eth_szedata2.c | 1 +
lib/librte_ether/rte_ethdev.c | 2 ++
lib/librte_ether/rte_ethdev.h | 4 +++-
9 files changed, 22 insertions(+), 10 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 3bc7bb4..3337b7b 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -549,7 +549,7 @@ static void cmd_help_long_parsed(void *parsed_result,
"Detach physical or virtual dev by port_id\n\n"
"port config (port_id|all)"
- " speed (10|100|1000|1|4|auto)"
+ " speed (10|100|1000|1|4|10|auto)"
" duplex (half|full|auto)\n"
"Set speed and duplex for all ports or port_id\n\n"
@@ -1017,6 +1017,8 @@ parse_and_check_speed_duplex(char *speedstr, char
*duplexstr, uint32_t *speed)
*speed = ETH_LINK_SPEED_10G;
} else if (!strcmp(speedstr, "4")) {
*speed = ETH_LINK_SPEED_40G;
+ } else if (!strcmp(speedstr, "10")) {
+ *speed = ETH_LINK_SPEED_100G;
} else if (!strcmp(speedstr, "auto")) {
*speed = ETH_LINK_SPEED_AUTONEG;
} else {
@@ -1064,7 +1066,7 @@ cmdline_parse_token_string_t cmd_config_speed_all_item1 =
TOKEN_STRING_INITIALIZER(struct cmd_config_speed_all, item1, "speed");
cmdline_parse_token_string_t cmd_config_speed_all_value1 =
TOKEN_STRING_INITIALIZER(struct cmd_config_speed_all, value1,
- "10#100#1000#1#4#auto");
+
"10#100#1000#1#4#10#auto");
cmdline_parse_token_string_t cmd_config_speed_all_item2 =
TOKEN_STRING_INITIALIZER(struct cmd_config_speed_all, item2, "duplex");
cmdline_parse_token_string_t cmd_config_speed_all_value2 =
@@ -1074,7 +1076,7 @@ cmdline_parse_token_string_t cmd_config_speed_all_value2 =
cmdline_parse_inst_t cmd_config_speed_all = {
.f = cmd_config_speed_all_parsed,
.data = NULL,
- .help_str = "port config all speed 10|100|1000|1|4|auto duplex "
+ .help_str = "port config all speed 10|100|1000|1|4|10|auto
duplex "
"half|full|auto",
.tokens = {
(void *)&cmd_config_speed_all_port,
@@ -1138,7 +1140,7 @@ cmdline_parse_token_string_t
cmd_config_speed_specific_item1 =
"speed");
cmdline_parse_token_string_t cmd_config_speed_specific_value1 =
TOKEN_STRING_INITIALIZER(struct cmd_config_speed_specific, value1,
- "10#100#1000#1#4#auto");
+
"10#100#1000#1#4#10#auto");
cmdline_parse_token_string_t cmd_config_speed_specific_item2 =
TOKEN_STRING_INITIALIZER(struct cmd_config_speed_specific, item2,
"duplex");
@@ -1149,7 +1151,7 @@ cmdline_parse_token_string_t
cmd_config_speed_specific_value2 =
cmdline_parse_inst_t cmd_config_speed_specific = {
.f = cmd_config_speed_specific_parsed,
.data = NULL,
- .help_str = "port config X speed 10|100|1000|1|4|auto duplex "
+ .help_str = "port config X speed 10|100|1000|1|4|10|auto
duplex "
"half|full|auto",
.tokens = {
(void *)&cmd_config_speed_specific_port,
diff --git a/doc/guides/rel_notes/release_16_04.rst
b/doc/guides/rel_notes/release_16_04.rst
index f6d00f5..4700899 100644
--- a/doc/guides/rel_notes/release_16_04.rst
+++ b/doc/guides/rel_notes/release_16_04.rst
@@ -157,6 +157,11 @@ EAL
Drivers
~~~
+* **ethdev: Fixed overflow for 100Gbps.**
+
+ 100Gbps in Mbps (10) was exceeding 16-bit max value of ``link_speed``
+ in ``rte_eth_link``.
+
* **ethdev: Fixed byte order consistency between fdir flow and mask.**
Fixed issue in ethdev library that the structure for setting
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index efaf2b5..cb4949
[dpdk-dev] [PATCH] cryptodev: fix RTE_PMD_DEBUG_TRACE redefinition
On 10 March 2016 at 19:23, Thomas Monjalon wrote: > 2016-03-03 00:34, Marc Sune: > > RTE_PMD_DEBUG_TRACE used RTE_FUNC_PTR_OR_ERR_RET was redefined > > in rte_cryptodev_pmd.h which produced MACRO redefinition warnings > > when including both rte_cryptodev_pmd.h and rte_ethdev.h. > > > > This commit moves MACRO definition to rte_cryptodev.c to prevent > > this warning. > > It is not the right fix. > This MACRO is only used in that .c file, so it actually makes sense not to be defined in the header file. > > This macro should probably be renamed with a crypto prefix or defined > only once (same thing for ethdev). > The function rte_pmd_debug_trace() and the macros > RTE_PROC_PRIMARY_OR_ERR_RET, > RTE_PROC_PRIMARY_OR_RET, > RTE_FUNC_PTR_OR_ERR_RET, > RTE_FUNC_PTR_OR_RET > should not be in lib/librte_eal/common/include/rte_dev.h. > The macros call RTE_PMD_DEBUG_TRACE which is defined elsewhere. > The rte_log.h is probably a better place. > But why these macros have no PMD prefix? > While I agree, this patch is only trying to solve the compilation error, which I think it is a step forward from what we have now. I am working on C++ linking automated test and I could not include both files in the test. Marc
[dpdk-dev] [PATCH] virtio: fix wrong features returned for legacy virtio
2016-03-10 08:43, David Marchand:
> On Thu, Mar 10, 2016 at 8:01 AM, Yuanhan Liu
> wrote:
> > Declare dst as type uint32_t instead of uint64_t, otherwise, we will get
> > a random upper 32 bit feature bits, as the following io port read reads
> > lower 32 bit only. It could lead a feature bits that include
> > VIRTIO_F_VERSION_1
> > (the 32th bit) for legacy virtio, which is obviously wrong.
> >
> > Fixes: b8f04520ad71 ("virtio: use PCI ioport API")
> >
> > Cc: David Marchand
> > Signed-off-by: Yuanhan Liu
>
> Argh, good catch.
> Relooked at my patch, this should be the only bug (of this kind ;-)).
>
> Reviewed-by: David Marchand
Applied, thanks
[dpdk-dev] [PATCH] hash: fix memcmp function pointer in multi-process environment
Hi
I looked at your info from gdb and source code.
From source code, rte_hash_lookup_with_hash /
__rte_hash_lookup_with_hash() function doesn't invoke rte_hash_reset()
function.
It may be possible that rte_hash_cmp_eq function pointer from one
process is matching to address of rte_hash_reset () in other process.
For quick test, you can do two things.
1. just apply the patch I provided and recompile the dpdk with a -D flag
"RTE_LIB_MP_NO_FUNC_PTR" defined and re-run your test
2. If it still crashes, disable the optimization in Makefiles and see,
using gdb, how you are entering rte_hash_reset() from
__rte_hash_lookup_with_hash(). this will tell you if it was a problem
with function pointers in multi-process environment
Thanks
Dhana
On 03/14/2016 12:38 AM, ?? wrote:
> BTW, the following is my backtrace when the system crashes.
>
> Program received signal SIGSEGV, Segmentation fault.
>
> 0x004883ab in rte_hash_reset (h=0x0)
>
> at
> /home/zhangwei1984/timopenNetVM/dpdk-2.2.0/lib/librte_hash/rte_cuckoo_hash.c:444
>
> 444while (rte_ring_dequeue(h->free_slots, &ptr) == 0)
>
> (gdb) bt
>
> #0 0x004883ab in rte_hash_reset (h=0x0)
>
> at
> /home/zhangwei1984/timopenNetVM/dpdk-2.2.0/lib/librte_hash/rte_cuckoo_hash.c:444
>
> #1 0x0048fdfb in rte_hash_lookup_with_hash (h=0x7fff32cce740,
> key=0x7fffe220, sig=403183624)
>
> at
> /home/zhangwei1984/timopenNetVM/dpdk-2.2.0/lib/librte_hash/rte_cuckoo_hash.c:771
>
> #2 0x0042b551 in onvm_ft_lookup_with_hash
> (table=0x7fff32cbe4c0, pkt=0x7fff390ea9c0,
>
> data=0x7fffe298) at
> /home/zhangwei1984/openNetVM-master/openNetVM/onvm/shared/onvm_flow_table.c:104
>
> #3 0x0042b8c3 in onvm_flow_dir_get_with_hash
> (table=0x7fff32cbe4c0, pkt=0x7fff390ea9c0,
>
> flow_entry=0x7fffe298)
>
> at
> /home/zhangwei1984/openNetVM-master/openNetVM/onvm/shared/onvm_flow_dir.c:14
>
> #4 0x004251d7 in packet_handler (pkt=0x7fff390ea9c0,
> meta=0x7fff390eaa00)
>
> at
> /home/zhangwei1984/openNetVM-master/openNetVM/examples/flow_table/flow_table.c:212
>
> #5 0x00429502 in onvm_nf_run ()
>
> #6 0x004253f1 in main (argc=1, argv=0x7fffe648)
>
> at
> /home/zhangwei1984/openNetVM-master/openNetVM/examples/flow_table/flow_table.c:272
>
> (gdb)
>
>
>
>
> I met a problem which I used the DPDK hash table for multi processes.
> One started as primary process and the other as secondary process.
> I based on the client and server multiprocess example. My aim is that
> server creates a hash table, then share it to the client. The client
> will read and write the hash table, and the server will read the hash
> table. I use rte_calloc allocate the space for hash table, use memzone
> tells the client the hash table address.
> But once I add an entry into the hash table, calling "lookup" function
> will have the segment fault. But for the lookup function, I have
> exactly the same parameters for lookup when the first time calls the
> lookup.
> If I create the hash table inside the client, everything works correctly.
> I put pieces of codes for server and client codes related to the hash
> table. I have spent almost 3 days on this bug. But there is no any
> clue which can help to solve this bug. If any of you can give some
> suggestions, I will be appreciated. I post the question into the mail
> list, but have not yet got any reply.
>
> This problem is that in dpdk multi process - client and server
> example, dpdk-2.2.0/examples/multi_process/client_server_mp
> My aim is that server create a hash table, then share it to client.
> Client will write the hash table, server will read the hash table. I
> am using dpdk hash table. What I did is that server create a hash
> table (table and array entries), return the table address. I use
> memzone pass the table address to client. In client, the second
> lookup gets segment fault. The system gets crashed. I will put some
> related code here.
> create hash table function:
>
> struct onvm_ft*
>
> onvm_ft_create(int cnt, int entry_size) {
>
> struct rte_hash* hash;
>
> struct onvm_ft* ft;
>
> struct rte_hash_parameters ipv4_hash_params = {
>
> .name = NULL,
>
> .entries = cnt,
>
> .key_len = sizeof(struct onvm_ft_ipv4_5tuple),
>
> .hash_func = NULL,
>
> .hash_func_init_val = 0,
>
> };
>
>
> char s[64];
>
> /* create ipv4 hash table. use core number and cycle counter
> to get a unique name. */
>
> ipv4_hash_params.name
