[dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed API refactoring
On 28 March 2016 at 15:42, Thomas Monjalon wrote: > Hi Marc, > > 2016-03-27 21:39, Marc: > > On 27 March 2016 at 11:53, Thomas Monjalon > > wrote: > > > 2016-03-26 11:24, Marc: > > > > On 26 March 2016 at 09:08, Thomas Monjalon < > thomas.monjalon at 6wind.com> > > > > wrote: > > > > > 2016-03-25 22:30, Marc: > > > > > > From v9 to v10 patchset the values ETH_LINK_SPEED_AUTONEG and > > > > > ETH_LINK_SPEED_FIXED were flipped. Reverting this makes it work: > [...] > > > > > > I think having autoneg == 0 is better. Do you agree Thomas? > > > > > > > > > > No I do not agree, because this flag is now used also for > > > > > rte_eth_link.link_autoneg. > > > > > So it is more logic to set it to 1. > > > > > > > > Having to explicitly specify ETH_LINK_SPEED_AUTONEG in link_speeds > during > > > > port configuration for achieving auto-negociation, which is what 98% > of > > > > applications will use, seems anti-natural to me and breaks existing > > > > applications. > > > > > > Yes, you're right. We have to avoid apps modifications. > > > By keeping autoneg the default behaviour (value 0), we avoid issues. > > > > > > > The only benefit of your approach is not to have another macro > #define > > > > ETH_LINK_AUTONEG 1, which is marginal IMHO. > > > > > > Yes, you're right. > > > I suggest adding 2 macros for rte_eth_link.link_autoneg: > > > #define ETH_LINK_FIXED 0 /**< No autonegotiation. */ > > > #define ETH_LINK_AUTONEG1 /**< Autonegotiated. */ > > > > > > and keep these ones to use with rte_eth_conf.link_speeds and > > > rte_eth_dev_info.speed_capa: > > > #define ETH_LINK_SPEED_AUTONEG (0 << 0) /**< Autonegotiate (all > speeds) */ > > > #define ETH_LINK_SPEED_FIXED(1 << 0) /**< Disable autoneg (fixed > speed) */ > > > > > > Opinions? > > > > Agree on all of them. I can add them in the (hopefully) final v14, once > all > > or main drivers have been tested. > > It would be better to make the v14 as soon as possible to let others test > the latest revision. > Thanks > Adding these MACROs (ETH_LINK_FIXED, ETH_LINK_AUTONEG) are the only changes to be done for v14 so far. The rest were there already (v13). There is no point on doing this re-spin now, because these MACROs are anyway not used by applications yet (autoneg flag in rte_link is an addition to this patch set). So I would go for testing drivers on this v13 and collect any changes, eventually, for v14. marc
[dpdk-dev] [PATCH v2] ring: check for zero objects mc dequeue / mp enqueue
Hi Olivier,
We could have two threads (running on different cores in the general
case) that both succeed the cmpset operation. In the dequeue path,
when n == 0, then cons_next == cons_head, and cmpset will always
succeed. Now, if they both see an old r->cons.tail value from a
previous dequeue, they can get stuck in the while
(unlikely(r->cons.tail != cons_head)) loop. I tried, however, to
reproduce (without the patch) and it seems that there is still a
window for deadlock.
I'm pasting some debug output below that shows two processes' state.
It's two receivers doing interleaved mc_dequeue(32)/mc_dequeue(0), and
one sender doing mp_enqueue(32) on the same ring.
gdb --args ./ring-test -l0 --proc-type=primary
gdb --args ./ring-test -l1 --proc-type=secondary
gdb --args ./ring-test -l2 --proc-type=secondary -- tx
This is what I would usually see, process 0 and 1 both stuck at the same state:
663 while (unlikely(r->cons.tail != cons_head)) {
(gdb) p n
$1 = 0
(gdb) p r->cons.tail
$2 = 576416
(gdb) p cons_head
$3 = 576448
(gdb) p cons_next
$4 = 576448
But now I managed to get the two processes stuck at this state too.
process 0:
663 while (unlikely(r->cons.tail != cons_head)) {
(gdb) p n
$1 = 32
(gdb) p r->cons.tail
$2 = 254348832
(gdb) p cons_head
$3 = 254348864
(gdb) p cons_next
$4 = 254348896
proccess 1:
663 while (unlikely(r->cons.tail != cons_head)) {
(gdb) p n
$1 = 32
(gdb) p r->cons.tail
$2 = 254348832
(gdb) p cons_head
$3 = 254348896
(gdb) p cons_next
$4 = 254348928
I haven't been able to trigger this with the patch so far, but it
should be possible.
Lazaros.
On Fri, Mar 25, 2016 at 1:15 PM, Olivier Matz wrote:
> Hi Lazaros,
>
> On 03/17/2016 04:49 PM, Lazaros Koromilas wrote:
>> Issuing a zero objects dequeue with a single consumer has no effect.
>> Doing so with multiple consumers, can get more than one thread to succeed
>> the compare-and-set operation and observe starvation or even deadlock in
>> the while loop that checks for preceding dequeues. The problematic piece
>> of code when n = 0:
>>
>> cons_next = cons_head + n;
>> success = rte_atomic32_cmpset(>cons.head, cons_head, cons_next);
>>
>> The same is possible on the enqueue path.
>
> Just a question about this patch (that has been applied). Thomas
> retitled the commit from your log message:
>
> ring: fix deadlock in zero object multi enqueue or dequeue
> http://dpdk.org/browse/dpdk/commit/?id=d0979646166e
>
> I think this patch does not fix a deadlock, or did I miss something?
>
> As explained in the following links, the ring may not perform well
> if several threads running on the same cpu use it:
>
> http://dpdk.org/ml/archives/dev/2013-November/000714.html
> http://www.dpdk.org/ml/archives/dev/2014-January/001070.html
> http://www.dpdk.org/ml/archives/dev/2014-January/001162.html
> http://dpdk.org/ml/archives/dev/2015-July/020659.html
>
> A deadlock could occur if the threads running on the same core
> have different priority.
>
> Regards,
> Olivier
[dpdk-dev] librte_pmd_ixgbe implementation of ixgbe_dev_rx_queue_count
Hi, Looking into why it hurts performance, I see that ixgbe_dev_rx_queue_count is implemented a scan of elements of rx descriptors, which is very expensive. I am wondering why its implemented the way it is. Could it not just read the head location from the driver? Thanks! Mohammad El-Shabani
[dpdk-dev] is ixgbe supporting multi-segment mbuf?
Hi Wenzhuo, Thanks. For some reason, we have to stick to dpdk 2.0 for now. Is multi-segment mbuf supported in this version (any known issue with multi-seg in this version?) or do we have to upgrade to latest dpdk version for multi-segment support? Clarylin > On Mar 28, 2016, at 6:10 PM, Lu, Wenzhuo wrote: > > > Hi Clarylin, > > >> -Original Message- >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Clarylin L >> Sent: Tuesday, March 29, 2016 4:24 AM >> To: dev at dpdk.org >> Subject: [dpdk-dev] is ixgbe supporting multi-segment mbuf? >> >> ixgbe_recv_scattered_pkts was set to be the rx function. Receiving packets > I see this function is already deprecated. Do you use an old version? Would > you like to try the newest code? > >> smaller than mbuf size works perfectly. However, if an incoming packet is >> greater than the maximum acceptable length of one ?mbuf? data size, receiving >> does not work. In this case, isn't it supposed to use mbuf chaining to >> receive? >> >> The port has both jumbo_frame and enable_scatter being on. are these two >> flags good enough to make mbuf chaining going?
[dpdk-dev] [PATCH 4/4] port: fix ethdev writer burst too big
For f_tx_bulk functions in rte_port_ethdev.c, we may unintentionally
send bursts larger than tx_burst_sz to the underlying ethdev.
Some PMDs (e.g., ixgbe) may truncate this request to their maximum
burst size, resulting in unnecessary enqueuing failures or ethdev
writer retries.
We propose to fix this by moving the tx buffer flushing logic from
*after* the loop that puts all packets into the tx buffer, to *inside*
the loop, testing for a full burst when adding each packet.
Signed-off-by: Robert Sanford
---
lib/librte_port/rte_port_ethdev.c | 20 ++--
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/lib/librte_port/rte_port_ethdev.c
b/lib/librte_port/rte_port_ethdev.c
index 3fb4947..1283338 100644
--- a/lib/librte_port/rte_port_ethdev.c
+++ b/lib/librte_port/rte_port_ethdev.c
@@ -151,7 +151,7 @@ static int rte_port_ethdev_reader_stats_read(void *port,
struct rte_port_ethdev_writer {
struct rte_port_out_stats stats;
- struct rte_mbuf *tx_buf[2 * RTE_PORT_IN_BURST_SIZE_MAX];
+ struct rte_mbuf *tx_buf[RTE_PORT_IN_BURST_SIZE_MAX];
uint32_t tx_burst_sz;
uint16_t tx_buf_count;
uint64_t bsz_mask;
@@ -257,11 +257,11 @@ rte_port_ethdev_writer_tx_bulk(void *port,
p->tx_buf[tx_buf_count++] = pkt;
RTE_PORT_ETHDEV_WRITER_STATS_PKTS_IN_ADD(p, 1);
pkts_mask &= ~pkt_mask;
- }
- p->tx_buf_count = tx_buf_count;
- if (tx_buf_count >= p->tx_burst_sz)
- send_burst(p);
+ p->tx_buf_count = tx_buf_count;
+ if (tx_buf_count >= p->tx_burst_sz)
+ send_burst(p);
+ }
}
return 0;
@@ -328,7 +328,7 @@ static int rte_port_ethdev_writer_stats_read(void *port,
struct rte_port_ethdev_writer_nodrop {
struct rte_port_out_stats stats;
- struct rte_mbuf *tx_buf[2 * RTE_PORT_IN_BURST_SIZE_MAX];
+ struct rte_mbuf *tx_buf[RTE_PORT_IN_BURST_SIZE_MAX];
uint32_t tx_burst_sz;
uint16_t tx_buf_count;
uint64_t bsz_mask;
@@ -466,11 +466,11 @@ rte_port_ethdev_writer_nodrop_tx_bulk(void *port,
p->tx_buf[tx_buf_count++] = pkt;
RTE_PORT_ETHDEV_WRITER_NODROP_STATS_PKTS_IN_ADD(p, 1);
pkts_mask &= ~pkt_mask;
- }
- p->tx_buf_count = tx_buf_count;
- if (tx_buf_count >= p->tx_burst_sz)
- send_burst_nodrop(p);
+ p->tx_buf_count = tx_buf_count;
+ if (tx_buf_count >= p->tx_burst_sz)
+ send_burst_nodrop(p);
+ }
}
return 0;
--
1.7.1
[dpdk-dev] [PATCH 3/4] port: fix full burst checks in f_tx_bulk ops
For several f_tx_bulk functions in rte_port_{ethdev,ring,sched}.c,
it appears that the intent of the bsz_mask logic is to test whether
pkts_mask contains a full burst (i.e., the least
significant bits are set).
There are two problems with the bsz_mask code: 1) It truncates
by using the wrong size for local variable uint32_t bsz_mask, and
2) We may pass oversized bursts to the underlying ethdev/ring/sched,
e.g., tx_burst_sz=16, bsz_mask=0x8000, and pkts_mask=0x1
(17 packets), results in expr==0, and we send a burst larger than
desired (and non-power-of-2) to the underlying tx burst interface.
We propose to effectively set bsz_mask = (1 << tx_burst_sz) - 1
(while avoiding truncation for tx_burst_sz=64), to cache the mask
value of a full burst, and then do a simple compare with pkts_mask
in each f_tx_bulk.
Signed-off-by: Robert Sanford
---
lib/librte_port/rte_port_ethdev.c | 15 ---
lib/librte_port/rte_port_ring.c | 16
lib/librte_port/rte_port_sched.c |7 ++-
3 files changed, 10 insertions(+), 28 deletions(-)
diff --git a/lib/librte_port/rte_port_ethdev.c
b/lib/librte_port/rte_port_ethdev.c
index 1c34602..3fb4947 100644
--- a/lib/librte_port/rte_port_ethdev.c
+++ b/lib/librte_port/rte_port_ethdev.c
@@ -188,7 +188,7 @@ rte_port_ethdev_writer_create(void *params, int socket_id)
port->queue_id = conf->queue_id;
port->tx_burst_sz = conf->tx_burst_sz;
port->tx_buf_count = 0;
- port->bsz_mask = 1LLU << (conf->tx_burst_sz - 1);
+ port->bsz_mask = UINT64_MAX >> (64 - conf->tx_burst_sz);
return port;
}
@@ -229,12 +229,9 @@ rte_port_ethdev_writer_tx_bulk(void *port,
{
struct rte_port_ethdev_writer *p =
(struct rte_port_ethdev_writer *) port;
- uint32_t bsz_mask = p->bsz_mask;
uint32_t tx_buf_count = p->tx_buf_count;
- uint64_t expr = (pkts_mask & (pkts_mask + 1)) |
- ((pkts_mask & bsz_mask) ^ bsz_mask);
- if (expr == 0) {
+ if (pkts_mask == p->bsz_mask) {
uint64_t n_pkts = __builtin_popcountll(pkts_mask);
uint32_t n_pkts_ok;
@@ -369,7 +366,7 @@ rte_port_ethdev_writer_nodrop_create(void *params, int
socket_id)
port->queue_id = conf->queue_id;
port->tx_burst_sz = conf->tx_burst_sz;
port->tx_buf_count = 0;
- port->bsz_mask = 1LLU << (conf->tx_burst_sz - 1);
+ port->bsz_mask = UINT64_MAX >> (64 - conf->tx_burst_sz);
/*
* When n_retries is 0 it means that we should wait for every packet to
@@ -435,13 +432,9 @@ rte_port_ethdev_writer_nodrop_tx_bulk(void *port,
{
struct rte_port_ethdev_writer_nodrop *p =
(struct rte_port_ethdev_writer_nodrop *) port;
-
- uint32_t bsz_mask = p->bsz_mask;
uint32_t tx_buf_count = p->tx_buf_count;
- uint64_t expr = (pkts_mask & (pkts_mask + 1)) |
- ((pkts_mask & bsz_mask) ^ bsz_mask);
- if (expr == 0) {
+ if (pkts_mask == p->bsz_mask) {
uint64_t n_pkts = __builtin_popcountll(pkts_mask);
uint32_t n_pkts_ok;
diff --git a/lib/librte_port/rte_port_ring.c b/lib/librte_port/rte_port_ring.c
index 765ecc5..b36e4ce 100644
--- a/lib/librte_port/rte_port_ring.c
+++ b/lib/librte_port/rte_port_ring.c
@@ -217,7 +217,7 @@ rte_port_ring_writer_create_internal(void *params, int
socket_id,
port->ring = conf->ring;
port->tx_burst_sz = conf->tx_burst_sz;
port->tx_buf_count = 0;
- port->bsz_mask = 1LLU << (conf->tx_burst_sz - 1);
+ port->bsz_mask = UINT64_MAX >> (64 - conf->tx_burst_sz);
port->is_multi = is_multi;
return port;
@@ -299,13 +299,9 @@ rte_port_ring_writer_tx_bulk_internal(void *port,
{
struct rte_port_ring_writer *p =
(struct rte_port_ring_writer *) port;
-
- uint32_t bsz_mask = p->bsz_mask;
uint32_t tx_buf_count = p->tx_buf_count;
- uint64_t expr = (pkts_mask & (pkts_mask + 1)) |
- ((pkts_mask & bsz_mask) ^ bsz_mask);
- if (expr == 0) {
+ if (pkts_mask == p->bsz_mask) {
uint64_t n_pkts = __builtin_popcountll(pkts_mask);
uint32_t n_pkts_ok;
@@ -486,7 +482,7 @@ rte_port_ring_writer_nodrop_create_internal(void *params,
int socket_id,
port->ring = conf->ring;
port->tx_burst_sz = conf->tx_burst_sz;
port->tx_buf_count = 0;
- port->bsz_mask = 1LLU << (conf->tx_burst_sz - 1);
+ port->bsz_mask = UINT64_MAX >> (64 - conf->tx_burst_sz);
port->is_multi = is_multi;
/*
@@ -613,13 +609,9 @@ rte_port_ring_writer_nodrop_tx_bulk_internal(void *port,
{
struct rte_port_ring_writer_nodrop *p =
(struct rte_port_ring_writer_nodrop *) port;
-
- uint32_t bsz_mask = p->bsz_mask;
uint32_t tx_buf_count = p->tx_buf_count;
- uint64_t expr = (pkts_mask & (pkts_mask + 1)) |
-
[dpdk-dev] [PATCH 2/4] port: fix ring writer buffer overflow
Ring writer tx_bulk functions may write past the end of tx_buf[].
Solution is to double the size of tx_buf[].
Signed-off-by: Robert Sanford
---
lib/librte_port/rte_port_ring.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/librte_port/rte_port_ring.c b/lib/librte_port/rte_port_ring.c
index b847fea..765ecc5 100644
--- a/lib/librte_port/rte_port_ring.c
+++ b/lib/librte_port/rte_port_ring.c
@@ -179,7 +179,7 @@ rte_port_ring_reader_stats_read(void *port,
struct rte_port_ring_writer {
struct rte_port_out_stats stats;
- struct rte_mbuf *tx_buf[RTE_PORT_IN_BURST_SIZE_MAX];
+ struct rte_mbuf *tx_buf[2 * RTE_PORT_IN_BURST_SIZE_MAX];
struct rte_ring *ring;
uint32_t tx_burst_sz;
uint32_t tx_buf_count;
@@ -447,7 +447,7 @@ rte_port_ring_writer_stats_read(void *port,
struct rte_port_ring_writer_nodrop {
struct rte_port_out_stats stats;
- struct rte_mbuf *tx_buf[RTE_PORT_IN_BURST_SIZE_MAX];
+ struct rte_mbuf *tx_buf[2 * RTE_PORT_IN_BURST_SIZE_MAX];
struct rte_ring *ring;
uint32_t tx_burst_sz;
uint32_t tx_buf_count;
--
1.7.1
[dpdk-dev] [PATCH 1/4] app/test: enhance test_port_ring_writer
Add code to send two 60-packet bursts to a ring port_out. This tests a ring writer buffer overflow problem and fix (in patch 2/4). Signed-off-by: Robert Sanford --- app/test/test_table_ports.c | 27 +-- 1 files changed, 25 insertions(+), 2 deletions(-) diff --git a/app/test/test_table_ports.c b/app/test/test_table_ports.c index 2532367..0c0ec0a 100644 --- a/app/test/test_table_ports.c +++ b/app/test/test_table_ports.c @@ -149,8 +149,8 @@ test_port_ring_writer(void) /* -- Traffic TX -- */ int expected_pkts, received_pkts; - struct rte_mbuf *mbuf[RTE_PORT_IN_BURST_SIZE_MAX]; - struct rte_mbuf *res_mbuf[RTE_PORT_IN_BURST_SIZE_MAX]; + struct rte_mbuf *mbuf[2 * RTE_PORT_IN_BURST_SIZE_MAX]; + struct rte_mbuf *res_mbuf[2 * RTE_PORT_IN_BURST_SIZE_MAX]; port_ring_writer_params.ring = RING_TX; port_ring_writer_params.tx_burst_sz = RTE_PORT_IN_BURST_SIZE_MAX; @@ -216,5 +216,28 @@ test_port_ring_writer(void) for (i = 0; i < RTE_PORT_IN_BURST_SIZE_MAX; i++) rte_pktmbuf_free(res_mbuf[i]); + /* TX Bulk - send two 60-packet bursts */ + uint64_t pkt_mask = 0xfff0ULL; + + for (i = 0; i < 4; i++) + mbuf[i] = NULL; + for (i = 4; i < 64; i++) + mbuf[i] = rte_pktmbuf_alloc(pool); + rte_port_ring_writer_ops.f_tx_bulk(port, mbuf, pkt_mask); + for (i = 4; i < 64; i++) + mbuf[i] = rte_pktmbuf_alloc(pool); + rte_port_ring_writer_ops.f_tx_bulk(port, mbuf, pkt_mask); + rte_port_ring_writer_ops.f_flush(port); + + expected_pkts = 2 * 60; + received_pkts = rte_ring_sc_dequeue_burst(port_ring_writer_params.ring, + (void **)res_mbuf, 2 * RTE_PORT_IN_BURST_SIZE_MAX); + + if (received_pkts != expected_pkts) + return -10; + + for (i = 0; i < received_pkts; i++) + rte_pktmbuf_free(res_mbuf[i]); + return 0; } -- 1.7.1
[dpdk-dev] [PATCH 0/4] port: fix and test bugs in tx_bulk ops
This patch series does the following: * enhances port ring writer test, to send two large, but not full bursts; exposes ring writer buffer overflow * fixes ring writer buffer overflow * fixes full burst checks in ethdev, ring, and sched f_tx_bulk ops * fixes ethdev writer, to send bursts no larger than specified max Robert Sanford (4): app/test: enhance test_port_ring_writer port: fix ring writer buffer overflow port: fix full burst checks in f_tx_bulk ops port: fix ethdev writer burst too big app/test/test_table_ports.c | 27 +-- lib/librte_port/rte_port_ethdev.c | 35 ++- lib/librte_port/rte_port_ring.c | 20 ++-- lib/librte_port/rte_port_sched.c |7 ++- 4 files changed, 47 insertions(+), 42 deletions(-)
[dpdk-dev] [PATCH] ixgbe: avoid unnessary break when checking at the tail of rx hwring
Hi Qian, On 28 March 2016 at 10:30, Xu, Qian Q wrote: > Jianbo > Could you tell me the case that can reproduce the issue? We can help evaluate > the impact of performance on ixgbe, but I'm not sure how to check if your > patch really fix a problem because I don?t know how to reproduce the problem! > Could you first teach me on how to reproduce your issue? Or you may not > reproduce it by yourself? > It is more an refactoring to original design than fixing an issue. So I don't know how to reproduce either. Can you use your usual performance testing cases first, and see if there is any impact or improvement? Thanks! Jianbo
[dpdk-dev] [PATCH v11 0/8] ethdev: 100G and link speed API refactoring
Hi Marc, 2016-03-27 21:39, Marc: > On 27 March 2016 at 11:53, Thomas Monjalon > wrote: > > 2016-03-26 11:24, Marc: > > > On 26 March 2016 at 09:08, Thomas Monjalon > > > wrote: > > > > 2016-03-25 22:30, Marc: > > > > > From v9 to v10 patchset the values ETH_LINK_SPEED_AUTONEG and > > > > ETH_LINK_SPEED_FIXED were flipped. Reverting this makes it work: [...] > > > > > I think having autoneg == 0 is better. Do you agree Thomas? > > > > > > > > No I do not agree, because this flag is now used also for > > > > rte_eth_link.link_autoneg. > > > > So it is more logic to set it to 1. > > > > > > Having to explicitly specify ETH_LINK_SPEED_AUTONEG in link_speeds during > > > port configuration for achieving auto-negociation, which is what 98% of > > > applications will use, seems anti-natural to me and breaks existing > > > applications. > > > > Yes, you're right. We have to avoid apps modifications. > > By keeping autoneg the default behaviour (value 0), we avoid issues. > > > > > The only benefit of your approach is not to have another macro #define > > > ETH_LINK_AUTONEG 1, which is marginal IMHO. > > > > Yes, you're right. > > I suggest adding 2 macros for rte_eth_link.link_autoneg: > > #define ETH_LINK_FIXED 0 /**< No autonegotiation. */ > > #define ETH_LINK_AUTONEG1 /**< Autonegotiated. */ > > > > and keep these ones to use with rte_eth_conf.link_speeds and > > rte_eth_dev_info.speed_capa: > > #define ETH_LINK_SPEED_AUTONEG (0 << 0) /**< Autonegotiate (all speeds) > > */ > > #define ETH_LINK_SPEED_FIXED(1 << 0) /**< Disable autoneg (fixed > > speed) */ > > > > Opinions? > > Agree on all of them. I can add them in the (hopefully) final v14, once all > or main drivers have been tested. It would be better to make the v14 as soon as possible to let others test the latest revision. Thanks
[dpdk-dev] [PATCH] i40e: fix crash when dcb query
Calling rte_eth_dev_get_dcb_info to get dcb info from i40e
driver if VMDQ is disabled, results in a segmentation fault.
This patch fixes it by treating VMDQ and No-VMDQ respectively
when querying dcb information.
Fixes: 5135f3ca49a7 ("i40e: enable DCB in VMDQ VSIs")
Signed-off-by: Jingjing Wu
---
drivers/net/i40e/i40e_ethdev.c | 27 +++
1 file changed, 23 insertions(+), 4 deletions(-)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 05126e8..3a6c3aa 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -8892,7 +8892,7 @@ i40e_dev_get_dcb_info(struct rte_eth_dev *dev,
struct i40e_vsi *vsi = pf->main_vsi;
struct i40e_dcbx_config *dcb_cfg = >local_dcbx_config;
uint16_t bsf, tc_mapping;
- int i, j;
+ int i, j = 0;
if (dev->data->dev_conf.rxmode.mq_mode & ETH_MQ_RX_DCB_FLAG)
dcb_info->nb_tcs = rte_bsf32(vsi->enabled_tc + 1);
@@ -8903,13 +8903,12 @@ i40e_dev_get_dcb_info(struct rte_eth_dev *dev,
for (i = 0; i < dcb_info->nb_tcs; i++)
dcb_info->tc_bws[i] = dcb_cfg->etscfg.tcbwtable[i];
- j = 0;
- do {
+ /* get queue mapping if vmdq is disabled */
+ if (!pf->nb_cfg_vmdq_vsi) {
for (i = 0; i < I40E_MAX_TRAFFIC_CLASS; i++) {
if (!(vsi->enabled_tc & (1 << i)))
continue;
tc_mapping = rte_le_to_cpu_16(vsi->info.tc_mapping[i]);
- /* only main vsi support multi TCs */
dcb_info->tc_queue.tc_rxq[j][i].base =
(tc_mapping & I40E_AQ_VSI_TC_QUE_OFFSET_MASK) >>
I40E_AQ_VSI_TC_QUE_OFFSET_SHIFT;
@@ -8921,7 +8920,27 @@ i40e_dev_get_dcb_info(struct rte_eth_dev *dev,
dcb_info->tc_queue.tc_txq[j][i].nb_queue =
dcb_info->tc_queue.tc_rxq[j][i].nb_queue;
}
+ return 0;
+ }
+
+ /* get queue mapping if vmdq is enabled */
+ do {
vsi = pf->vmdq[j].vsi;
+ for (i = 0; i < I40E_MAX_TRAFFIC_CLASS; i++) {
+ if (!(vsi->enabled_tc & (1 << i)))
+ continue;
+ tc_mapping = rte_le_to_cpu_16(vsi->info.tc_mapping[i]);
+ dcb_info->tc_queue.tc_rxq[j][i].base =
+ (tc_mapping & I40E_AQ_VSI_TC_QUE_OFFSET_MASK) >>
+ I40E_AQ_VSI_TC_QUE_OFFSET_SHIFT;
+ dcb_info->tc_queue.tc_txq[j][i].base =
+ dcb_info->tc_queue.tc_rxq[j][i].base;
+ bsf = (tc_mapping & I40E_AQ_VSI_TC_QUE_NUMBER_MASK) >>
+ I40E_AQ_VSI_TC_QUE_NUMBER_SHIFT;
+ dcb_info->tc_queue.tc_rxq[j][i].nb_queue = 1 << bsf;
+ dcb_info->tc_queue.tc_txq[j][i].nb_queue =
+ dcb_info->tc_queue.tc_rxq[j][i].nb_queue;
+ }
j++;
} while (j < RTE_MIN(pf->nb_cfg_vmdq_vsi, ETH_MAX_VMDQ_POOL));
return 0;
--
2.4.0
[dpdk-dev] [PATCH] vmxnet3: fix txq flags check
Now that vmxnet3 supports TCP/UDP checksum offload, let's update
the default txq flags to allow such offloads. Also fixed the tx
queue setup check to allow TCP/UDP checksum and only error out
if SCTP checksum is requested.
Fixes: f598fd063bb1 ("vmxnet3: add Tx L4 checksum offload")
Reported-by: Heng Ding
Signed-off-by: Yong Wang
---
drivers/net/vmxnet3/vmxnet3_ethdev.c | 3 +--
drivers/net/vmxnet3/vmxnet3_rxtx.c | 2 +-
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_ethdev.c
b/drivers/net/vmxnet3/vmxnet3_ethdev.c
index f2b6b92..b0588ef 100644
--- a/drivers/net/vmxnet3/vmxnet3_ethdev.c
+++ b/drivers/net/vmxnet3/vmxnet3_ethdev.c
@@ -709,8 +709,7 @@ vmxnet3_dev_info_get(__attribute__((unused))struct
rte_eth_dev *dev,
dev_info->max_rx_pktlen = 16384; /* includes CRC, cf MAXFRS register */
dev_info->max_mac_addrs = VMXNET3_MAX_MAC_ADDRS;
- dev_info->default_txconf.txq_flags = ETH_TXQ_FLAGS_NOMULTSEGS |
- ETH_TXQ_FLAGS_NOOFFLOADS;
+ dev_info->default_txconf.txq_flags = ETH_TXQ_FLAGS_NOXSUMSCTP;
dev_info->flow_type_rss_offloads = VMXNET3_RSS_OFFLOAD_ALL;
dev_info->rx_desc_lim = (struct rte_eth_desc_lim) {
diff --git a/drivers/net/vmxnet3/vmxnet3_rxtx.c
b/drivers/net/vmxnet3/vmxnet3_rxtx.c
index 66b0eed..ebf883f 100644
--- a/drivers/net/vmxnet3/vmxnet3_rxtx.c
+++ b/drivers/net/vmxnet3/vmxnet3_rxtx.c
@@ -811,7 +811,7 @@ vmxnet3_dev_tx_queue_setup(struct rte_eth_dev *dev,
PMD_INIT_FUNC_TRACE();
- if ((tx_conf->txq_flags & ETH_TXQ_FLAGS_NOXSUMS) !=
+ if ((tx_conf->txq_flags & ETH_TXQ_FLAGS_NOXSUMSCTP) !=
ETH_TXQ_FLAGS_NOXSUMSCTP) {
PMD_INIT_LOG(ERR, "SCTP checksum offload not supported");
return -EINVAL;
--
1.9.1
[dpdk-dev] Bug in i40e PMD for flexible payload
I will have one of my team members follow the instructions and we'll have a patch out this week hopefully. On Thu, Mar 24, 2016 at 7:04 AM, Bruce Richardson < bruce.richardson at intel.com> wrote: > On Wed, Mar 23, 2016 at 01:44:46PM -0500, Michael Habibi wrote: > > We are using the i40 implementation to configure flow director with > > flexible payload rules. When setting up rules, it allows you to set a > value > > to 63 to disable the rule (NONUSE_FLX_PIT_DEST_OFF). However, the macro > in > > question is always adding an offset value 50 > > (I40E_FLX_OFFSET_IN_FIELD_VECTOR). This doesn't work when you use it in > > conjunction with NONUSE_FLX_PIT_DEST_OFF to disable it, because instead > of > > taking 63 as is, it does 63 + 50 and breaks the functionality. > > > > We used the following fix and it appears to work. Just sharing with the > > DPDK team in case they want to bring it in. > > > Thanks for this. Can you perhaps resubmit this fix in the form of an > official > patch to DPDK, including a proper sign-off on it. The details for > contributing > patches to DPDK is documented here: > http://dpdk.org/doc/guides/contributing/patches.html > > Without a signoff, we can't take in your code and use it. > > Regards, > /Bruce >
[dpdk-dev] is ixgbe supporting multi-segment mbuf?
ixgbe_recv_scattered_pkts was set to be the rx function. Receiving packets smaller than mbuf size works perfectly. However, if an incoming packet is greater than the maximum acceptable length of one ?mbuf? data size, receiving does not work. In this case, isn't it supposed to use mbuf chaining to receive? The port has both jumbo_frame and enable_scatter being on. are these two flags good enough to make mbuf chaining going?
[dpdk-dev] e1000: randomly loosing link change events triggered by the peer
On 28 March 2016 at 03:54, Lu, Wenzhuo wrote: > Hi Marc > > > > *From:* Marc Sune [mailto:marcdevel at gmail.com] > *Sent:* Saturday, March 26, 2016 9:43 AM > *To:* dev at dpdk.org; Lu, Wenzhuo > *Subject:* e1000: randomly loosing link change events triggered by the > peer > > > > I found that in the current HEAD in master testing it with an I218-LM in > autoneg mode, when link is forced to be renegociated by the peer (e.g. via > ethtool on a peer Linux box) _some_ change events are lost. > > > > It is quite random, but it seems to happen more while changing the speed > than when changing the duplex mode. > > > > However, when one or more link change events have been lost and the phy > medium is disconnected and reconnected, the link speed and duplex mode are > then correctly updated. > > > > Marc > > > > [Wenzhuo] Thanks for let us know this issue. May I ask some questions? Do > you mean this NIC 0x155A? > 0x15A2, I218-LM (rev 03) EAL: PCI device :00:19.0 on NUMA socket -1 EAL: probe driver: 8086:15a2 rte_em_pmd EAL: PCI memory mapped at 0x7f85cf40 EAL: PCI memory mapped at 0x7f85cf42 PMD: eth_em_dev_init(): port_id 0 vendorID=0x8086 deviceID=0x15a2 I think this is not a NIC issue, but a general problem of the driver (or em code). > About how to reproduce this problem, you mean use these CLIs, ethtool ?s > xxx advertise xxx, ethtool ?s xxx duplex half/full, to change the peer > port?s configuration? > Correct. I modified l2fwd to check link status and print it on each port stats print iteration. Then from the peer I modified the link properties via ethtool. The result is that transitions from autoneg speeds and/or duplex mode settings are randomly not detected (rte_eth_link in rte_eth_dev_data is not updated), and it prints not-up-to-date state. Marc
[dpdk-dev] [RFC 0/6] Flattened Device Tree access from DPDK
On 26 March 2016 at 09:12, Jan Viktorin wrote: > Hello, > > while extending the DPDK by a kind of platform devices (for the 16.07), an > access to the FDT might be necessary (or at least very helpful). This patch > series for 16.07 introduces an approach to solve this topic. > > The API is designed from scratch and there is only the Linux backend for it. > The Linux backend can read and traverse the /proc/device-tree structure. The > API, however, stays as independent as possible. It is possible to: > > * open the FDT in a platform independent way (rte_fdt_open/close) > * define a path in the FDT in an abstract way (rte_fdt_path) > * read strings, 32 and 64 bit values, a binary content (rte_fdt_path_readX) > * walk the FDT structure from a selected point (rte_fdt_path_walk) > > I've included unit tests of the API and of the Linux implemention. Some basic > API tests are introduced in the patch 3. Then a simplified device-tree file > structure is added together with more tests testing the Linux backend (4,5). > I've left those 3 patches separated for now but I think they can be aggregated > into a single patch later. > > Here, I've encounter an issue. The testing FDT files (app/test/linux-fdt) need > to be copied (or linked) to the working directory of the _test_ executable. I > have no idea, how to integrate such logic into the build system. > Why not store FDT files in the code, for example, as a group of binary arrays? When test is executed, it firstly creates the files in the working directory from those arrays. Jianbo
[dpdk-dev] Unable to get multi-segment mbuf working for ixgbe
Any pointers to what the issue could be? thanks On Fri, Mar 25, 2016 at 4:13 PM, Clarylin L wrote: > Hello, > > I am trying to use multi-segment mbuf to receive large packet. I enabled > jumbo_frame and enable_scatter for the port and was expecting mbuf chaining > would be used to receive packets larger than the mbuf size (which was set > to 2048). > > When sending 3000-byte (without fragmentation) packet from another > non-dpdk host, I didn't see packet was received by the ixgbe PMD driver. > > After a quick debugging session I found that the following statement in > ixgbe_recv_scattered_pkts > (ixgbe_rxtx.c) is > always true and break the loop in case of large packet, while it's not the > case for small packet (smaller than mbuf size): > > if (! staterr & rte_cpu_to_le32(IXGBE_RXDADV_STAT_DD)) > break; > > Is enabling jumbo_frame and enable_scatter good enough to get started the > mbuf chaining? > > Appreciate any input! Thanks. >
[dpdk-dev] [PATCH] ixgbe: return err for too many interrupt queues
The lower 16 bits of EICR register are used for queue interrupts,
dpdk framework take over the first bit for other interrupts like
LSC, so there're only 15 bits left for queue interrupts mapping.
This patch adds a check for the num of interrupt queues at
dev_start.
Signed-off-by: Wang Xiao W
---
drivers/net/ixgbe/ixgbe_ethdev.c | 5 +
drivers/net/ixgbe/ixgbe_ethdev.h | 1 +
2 files changed, 6 insertions(+)
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 5812d10..8961454 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -2131,6 +2131,11 @@ ixgbe_dev_start(struct rte_eth_dev *dev)
!RTE_ETH_DEV_SRIOV(dev).active) &&
dev->data->dev_conf.intr_conf.rxq != 0) {
intr_vector = dev->data->nb_rx_queues;
+ if (intr_vector > IXGBE_MAX_INTR_QUEUE_NUM) {
+ PMD_INIT_LOG(ERR, "At most %d intr queues supported",
+ IXGBE_MAX_INTR_QUEUE_NUM);
+ return -ENOTSUP;
+ }
if (rte_intr_efd_enable(intr_handle, intr_vector))
return -1;
}
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.h b/drivers/net/ixgbe/ixgbe_ethdev.h
index a7b1eb5..4ff6338 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.h
+++ b/drivers/net/ixgbe/ixgbe_ethdev.h
@@ -59,6 +59,7 @@
#define IXGBE_VFTA_SIZE 128
#define IXGBE_VLAN_TAG_SIZE 4
#define IXGBE_MAX_RX_QUEUE_NUM 128
+#define IXGBE_MAX_INTR_QUEUE_NUM 15
#define IXGBE_VMDQ_DCB_NB_QUEUES IXGBE_MAX_RX_QUEUE_NUM
#define IXGBE_DCB_NB_QUEUES IXGBE_MAX_RX_QUEUE_NUM
#define IXGBE_NONE_MODE_TX_NB_QUEUES 64
--
1.9.3
[dpdk-dev] [PATCH] ixgbe: avoid unnessary break when checking at the tail of rx hwring
Jianbo Could you tell me the case that can reproduce the issue? We can help evaluate the impact of performance on ixgbe, but I'm not sure how to check if your patch really fix a problem because I don?t know how to reproduce the problem! Could you first teach me on how to reproduce your issue? Or you may not reproduce it by yourself? Thanks Qian -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Jianbo Liu Sent: Friday, March 25, 2016 4:53 PM To: Ananyev, Konstantin Cc: Richardson, Bruce; Lu, Wenzhuo; Zhang, Helin; dev at dpdk.org Subject: Re: [dpdk-dev] [PATCH] ixgbe: avoid unnessary break when checking at the tail of rx hwring On 22 March 2016 at 22:27, Ananyev, Konstantin wrote: > > >> -Original Message- >> From: Jianbo Liu [mailto:jianbo.liu at linaro.org] >> Sent: Monday, March 21, 2016 2:27 AM >> To: Richardson, Bruce >> Cc: Lu, Wenzhuo; Zhang, Helin; Ananyev, Konstantin; dev at dpdk.org >> Subject: Re: [dpdk-dev] [PATCH] ixgbe: avoid unnessary break when >> checking at the tail of rx hwring >> >> On 18 March 2016 at 18:03, Bruce Richardson >> wrote: >> > On Thu, Mar 17, 2016 at 10:20:01AM +0800, Jianbo Liu wrote: >> >> On 16 March 2016 at 19:14, Bruce Richardson > >> intel.com> wrote: >> >> > On Wed, Mar 16, 2016 at 03:51:53PM +0800, Jianbo Liu wrote: >> >> >> Hi Wenzhuo, >> >> >> >> >> >> On 16 March 2016 at 14:06, Lu, Wenzhuo wrote: >> >> >> > HI Jianbo, >> >> >> > >> >> >> > >> >> >> >> -Original Message- >> >> >> >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jianbo >> >> >> >> Liu >> >> >> >> Sent: Monday, March 14, 2016 10:26 PM >> >> >> >> To: Zhang, Helin; Ananyev, Konstantin; dev at dpdk.org >> >> >> >> Cc: Jianbo Liu >> >> >> >> Subject: [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. >> >> >> > Would you like to give more details about in what scenario this >> >> >> > issue will be hit? Thanks. >> >> >> > >> >> >> >> >> >> vPMD will place extra RTE_IXGBE_DESCS_PER_LOOP - 1 number of >> >> >> empty descriptiors at the end of hwring to avoid overflow when >> >> >> do checking on rx side. >> >> >> >> >> >> For the loop in _recv_raw_pkts_vec(), we check 4 descriptors >> >> >> each time. If all 4 DD are set, and all 4 packets are >> >> >> received.That's OK in the middle. >> >> >> But if come to the end of hwring, and less than 4 descriptors >> >> >> left, we still need to check 4 descriptors at the same time, so >> >> >> the extra empty descriptors are checked with them. >> >> >> This time, the number of received packets is apparently less >> >> >> than 4, and we break out of the loop because of the condition >> >> >> "var != RTE_IXGBE_DESCS_PER_LOOP". >> >> >> So the problem arises. It is possible that there could be more >> >> >> packets at the hwring beginning that still waiting for being received. >> >> >> I think this fix can avoid this situation, and at least reduce >> >> >> the latency for the packets in the header. >> >> >> >> >> > Packets are always received in order from the NIC, so no packets >> >> > ever get left behind or skipped on an RX burst call. >> >> > >> >> > /Bruce >> >> > >> >> >> >> I knew packets are received in order, and no packets will be >> >> skipped, but some will be left behind as I explained above. >> >> vPMD will not received nb_pkts required by one RX burst call, and >> >> those at the beginning of hwring are still waiting to be received >> >> till the next call. >> >> >> >> Thanks! >> >> Jianbo >> > HI Jianbo, >> > >> > ok, I understand now. I'm not sure that this is a significant >> > problem though, since we are working in polling mode. Is there a >> > performance impact to your change, because I don't think that we can >> > reduce performance just to fix this? >> > >> > Regards, >> > /Bruce >> It will be a problem because the possibility could be high. >> Considering rx hwring size is 128 and rx burst is 32, the possiblity >> can be 32/128. >> I know this change is critical, so I want you (and maintainers) to do >> full evaluations about throughput/latency..before making conclusion. > > I am still not sure what is a problem you are trying to solve here. > Yes recv_raw_pkts_vec() call wouldn't wrap around HW ring boundary, > and yes can return less packets that are actually available by the HW. > Though as Bruce pointed, they'll be returned to the user by next call. Have you thought of the interval between these two call, how long could it be? If application is a simple one like l2fwd/testpmd, that's fine. But if the interval is long because application has more work to do, they are different. > Actually recv_pkts_bulk_alloc() works in a similar way. > Why do you consider that as a problem? Driver should pull packets out of hardware and give them to
[dpdk-dev] [PATCH 1/3 v7] i40e: support floating VEB config
Tested-by: Qian Xu
- Test Commit: 8f6f24342281f59de0df7bd976a32f714d39b9a9
- OS/Kernel: Fedora 21/4.1.13
- GCC: gcc (GCC) 4.9.2 20141101 (Red Hat 4.9.2-1)
- CPU: Intel(R) Xeon(R) CPU E5-2695 v4 @ 2.10
- NIC: Intel(R) Ethernet Controller X710 for 10GbE SFP+
- Total 2 cases, 2 passed, 0 failed.
Test Case5: Floating VEB Inter-VM VF-VF
===
Summary: DPDK PF, then create 2VFs and 2VMs, assign one VF to one VM, say VF1
in VM1, VF2 in VM2, and make PF link down(the cable can be pluged out). VFs in
VMs are running dpdk testpmd, send traffic to VF1, and set the packet's DEST
MAC to VF2, check if VF2 can receive the packets. Check Inter-VM VF-VF MAC
switch when PF is link down as well as up.
Details:
1. Start VM1 with VF1, VM2 with VF2, see the prerequisite part.
2. In the host, run testpmd with floating parameters and make the link down::
./testpmd -c 0x3 -n 4 -w 8c:00.0,enable_floating=1 -- -i
testpmd> port stop all
testpmd> show port info all
3. In VM1, run testpmd::
./testpmd -c 0x3 -n 4 -- -i
testpmd>set mac fwd
testpmd>set promisc off all
testpmd>start
In VM2, run testpmd::
./testpmd -c 0x3 -n 4 -- -i --eth-peer=0, VF1's MAC
testpmd>set mac fwd
testpmd>set promisc off all
testpmd>start
4. Send 100 packets to VF1's MAC address, check if VF2 can get 100 packets.
Also check the PF's port stats, and there should be no packets RX/TX at PF
port.
5. In the host, run testpmd with floating parameters and keep the link up, then
do step3 and step4, PF should have no RX/TX packets even when link is up::
./testpmc -c 0xc -n 4 --floating -- -i
testpmd> port start all
testpmd> show port info all
Test Case6: Floating VEB Inter-VM VF traffic can't be out of NIC
DPDK PF, then create 1VF, assign VF1 to VM1, send traffic from VF1 to outside
world, then check outside world will not see any traffic.
Details:
1. Start VM1 with VF1, see the prerequisite part.
2. In the host, run testpmd with floating parameters.
./testpmd -c 0x3 -n 4 -w 8c:00.0,enable_floating=1 -- -i
3. In VM1, run testpmd, ::
./testpmd -c 0x3 -n 4 -- -i --eth-peer=0,pf_mac_addr
testpmd>set fwd txonly
testpmd>start
4. At PF side, check the port stats to see if there is any RX/TX packets, and
also check the traffic generator side(e.g: IXIA ports or another port connected
to the DUT port) to ensure no packets.
Thanks
Qian
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Zhe Tao
Sent: Friday, March 25, 2016 4:42 PM
To: dev at dpdk.org
Cc: Tao, Zhe; Wu, Jingjing
Subject: [dpdk-dev] [PATCH 1/3 v7] i40e: support floating VEB config
Add the new floating related argument option in the devarg.
Using this parameter, all the samples can decide whether to use legacy VEB/VEPA
or floating VEB.
To enable this feature, the user should pass a devargs parameter to the EAL
like "-w 84:00.0,enable_floating=1", and the application will make sure the PMD
will use the floating VEB feature for all the VFs created by this PF device.
Signed-off-by: Zhe Tao
---
drivers/net/i40e/i40e_ethdev.c | 44 ++
drivers/net/i40e/i40e_ethdev.h | 6 ++
2 files changed, 50 insertions(+)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 6fdae57..01f1d3d 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -739,6 +739,44 @@ i40e_add_tx_flow_control_drop_filter(struct i40e_pf *pf)
" frames from VSIs.");
}
+static int i40e_check_floating_handler(__rte_unused const char *key,
+ const char *value,
+ __rte_unused void *opaque)
+{
+ if (strcmp(value, "1"))
+ return -1;
+
+ return 0;
+}
+
+static int
+i40e_check_floating(struct rte_devargs *devargs) {
+ struct rte_kvargs *kvlist;
+ const char *floating_key = "enable_floating";
+
+ if (devargs == NULL)
+ return 0;
+
+ kvlist = rte_kvargs_parse(devargs->args, NULL);
+ if (kvlist == NULL)
+ return 0;
+
+ if (!rte_kvargs_count(kvlist, floating_key)) {
+ rte_kvargs_free(kvlist);
+ return 0;
+ }
+ /* Floating is enabled when there's key-value pair: enable_floating=1 */
+ if (rte_kvargs_process(kvlist, floating_key,
+ i40e_check_floating_handler, NULL) < 0) {
+ rte_kvargs_free(kvlist);
+ return 0;
+ }
+ rte_kvargs_free(kvlist);
+
+ return 1;
+}
+
static int
eth_i40e_dev_init(struct rte_eth_dev *dev) { @@ -829,6 +867,12 @@
eth_i40e_dev_init(struct rte_eth_dev *dev)
((hw->nvm.version >> 4) & 0xff),
(hw->nvm.version & 0xf), hw->nvm.eetrack);
+
[dpdk-dev] e1000: randomly loosing link change events triggered by the peer
Hi Marc From: Marc Sune [mailto:marcde...@gmail.com] Sent: Saturday, March 26, 2016 9:43 AM To: dev at dpdk.org; Lu, Wenzhuo Subject: e1000: randomly loosing link change events triggered by the peer I found that in the current HEAD in master testing it with an I218-LM in autoneg mode, when link is forced to be renegociated by the peer (e.g. via ethtool on a peer Linux box) _some_ change events are lost. It is quite random, but it seems to happen more while changing the speed than when changing the duplex mode. However, when one or more link change events have been lost and the phy medium is disconnected and reconnected, the link speed and duplex mode are then correctly updated. Marc [Wenzhuo] Thanks for let us know this issue. May I ask some questions? Do you mean this NIC 0x155A? About how to reproduce this problem, you mean use these CLIs, ethtool ?s xxx advertise xxx, ethtool ?s xxx duplex half/full, to change the peer port?s configuration?
[dpdk-dev] [PATCH] ixgbe: return err for too many interrupt queues
Hi, > -Original Message- > From: Wang, Xiao W > Sent: Monday, March 28, 2016 8:40 AM > To: Lu, Wenzhuo > Cc: dev at dpdk.org; Wang, Xiao W > Subject: [PATCH] ixgbe: return err for too many interrupt queues > > The lower 16 bits of EICR register are used for queue interrupts, dpdk > framework > take over the first bit for other interrupts like LSC, so there're only 15 > bits left for > queue interrupts mapping. > This patch adds a check for the num of interrupt queues at dev_start. > > Signed-off-by: Wang Xiao W Acked-by: Wenzhuo Lu
