[dpdk-dev] [PATCH] gcc compiler option -Og warnings fix
On Mon, Apr 04, 2016 at 04:10:54PM +0200, Thomas Monjalon wrote:
> --- a/lib/librte_vhost/vhost_rxtx.c
> +++ b/lib/librte_vhost/vhost_rxtx.c
> @@ -147,8 +147,10 @@ copy_mbuf_to_desc(struct virtio_net *dev, struct
> vhost_virtqueue *vq,
> struct virtio_net_hdr_mrg_rxbuf virtio_hdr = {{0, 0, 0, 0, 0, 0}, 0};
>
> desc = &vq->desc[desc_idx];
> - if (unlikely(desc->len < vq->vhost_hlen))
> + if (unlikely(desc->len < vq->vhost_hlen)) {
> + *copied = 0;
> return -1;
> + }
>
> > err = copy_mbuf_to_desc(dev, vq, pkts[i], desc_idx, &copied);
> > @@ -531,7 +531,7 @@ virtio_dev_merge_rx(struct virtio_net *dev, uint16_t
> > queue_id,
> > {
> > struct vhost_virtqueue *vq;
> > uint32_t pkt_idx = 0, nr_used = 0;
> > - uint16_t start, end;
> > + uint16_t start = 0, end = 0;
>
> I don't understand this one because the variables are not used if
> reserve_avail_buf_mergeable fails.
> I don't see any smart workaround.
> Huawei, Yuanhan, can we expect a little slowdown with this change?
I agree with you that the compiler seems buggy here, I'm okay with
the fix though: it should not introduce slowdown, IMO. However, I'd
ask the opinion from Huawei: he knows this better than me.
--yliu
[dpdk-dev] [PATCH] virtio: use zeroed memory for simple TX header
On Mon, Apr 04, 2016 at 03:13:37PM +0200, Thomas Monjalon wrote: > Huawei, Yuanhan, any comment? > > 2016-03-31 13:01, Rich Lane: > > vq->vq_ring.desc[i + mid_idx].next = i; > > vq->vq_ring.desc[i + mid_idx].addr = > > - vq->virtio_net_hdr_mem + > > - i * vq->hw->vtnet_hdr_size; > > + vq->virtio_net_hdr_mem; I could be wrong, but this looks like a special case when i == 0, which is by no way that zeroed memory is guaranteed? Huawei, do you have time to check this patch? Thanks.
[dpdk-dev] [PATCH] virtio: use zeroed memory for simple TX header
On Mon, Apr 04, 2016 at 03:57:11PM -0700, Rich Lane wrote: > On Mon, Apr 4, 2016 at 1:05 PM, Yuanhan Liu > wrote: > > On Mon, Apr 04, 2016 at 03:13:37PM +0200, Thomas Monjalon wrote: > > Huawei, Yuanhan, any comment? > > > > 2016-03-31 13:01, Rich Lane: > > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?vq->vq_ring.desc[i + mid_idx].next = i; > > >? ? ? ? ? ? ? ? ? ? ? ? ? ? ?vq->vq_ring.desc[i + mid_idx].addr = > > > -? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?vq->virtio_net_hdr_mem + > > > -? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?i * > vq->hw->vtnet_hdr_size; > > > +? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?vq->virtio_net_hdr_mem; > > I could be wrong, but this looks like a special case when i == 0, > which is by no way that zeroed memory is guaranteed? Huawei, do > you have time to check this patch?? > > > This bug exists because the type of the objects pointed to by > virtio_net_hdr_mem changed in 6dc5de3a (virtio: use indirect ring elements), > but because it isn't a C pointer the compiler didn't?catch the type mismatch. > We could also fix it with: > > ? ? vq->virtio_net_hdr_mem + i * sizeof(struct virtio_tx_region) + offsetof > (struct virtio_tx_region, tx_hdr) > > Given that tx_hdr is the first member in struct virtio_tx_region, and using a > single header optimizes cache use, that simplifies to the code in my patch. It does. However, it hurts readability. > The > virtio-net header is never written to by simple TX so it remains zeroed. > > I can respin the patch using offsetof if that's preferred. Yes, please. In such way, we could also align with the setting up code at virtio_dev_queue_setup(). BTW, I have one question: will simple Tx work with indirect buf enabled? > Note that right now virtio simple TX is broken with DPDK vhost due to the > flood > of error messages. Yes, we need the fix, and thanks for the catching. BTW, it's a regression fix, you'd better add a Fixline into your commit log. --yliu
[dpdk-dev] [PATCH] igb: fix i350 VF RX issue
Hi Thomas, > > Missing Signed-off-by Sorry for this mistake, will correct it with a V2.
[dpdk-dev] [PATCH] doc: update overview
Hi Thomas, > -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Saturday, April 2, 2016 5:33 AM > To: Lu, Wenzhuo > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH] doc: update overview > > 2016-04-01 16:18, Wenzhuo Lu: > > Update the overview.rst for e1000, igb, ixgbe. > > > > Signed-off-by: Wenzhuo Lu > > Please double check the patch. > You are filling some features for ena and enic. Sorry, I'll check it and send a V2.
[dpdk-dev] [PATCH] ixgbe: cleanup whitespace and formatting issues
Hi Stephen, > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Stephen Hemminger > Sent: Tuesday, April 5, 2016 12:14 AM > To: Zhang, Helin; Ananyev, Konstantin > Cc: dev at dpdk.org; Stephen Hemminger > Subject: [dpdk-dev] [PATCH] ixgbe: cleanup whitespace and formatting issues > > This driver was one of the originals and has lots of little whitespace issues. > > PS: I know Intel doesn't like whitespace changes, there is never a good time > to do this, but no resuliting binary changes and it is unlikely that more > changes to this driver will occur this late in release cycle. > > Signed-off-by: Stephen Hemminger Thanks for this patch. I think it's good to make the format better :) But there's some checkpatch error and warnings, like this, ERROR: "foo* bar" should be "foo *bar" #508: FILE: drivers/net/ixgbe/ixgbe_ethdev.c:4256: +ixgbe_uc_hash_table_set(struct rte_eth_dev *dev, struct ether_addr* mac_addr,
[dpdk-dev] [PATCH v2] igb: fix i350 VF RX issue
A problem is found on i350 VF. We found TX will happen once per 4 packets. If only 1~3 packets are received, they will not be forwarded. But the real problem is on RX side. The reason is the default RX write-back threshold is changed to 4, so every first 3 packets may be hung there. This patch checks the RX wthresh when setting up the RX queue, and forces it to be 1, so every packet can be handled immediately. v2: - Add missed signoff. Fixes: 4a41c17dba18 (igb: set default thresholds based on MAC type) Signed-off-by: Wenzhuo Lu Acked-by: Konstantin Ananyev --- drivers/net/e1000/igb_rxtx.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/e1000/igb_rxtx.c b/drivers/net/e1000/igb_rxtx.c index 529dba4..4a987e3 100644 --- a/drivers/net/e1000/igb_rxtx.c +++ b/drivers/net/e1000/igb_rxtx.c @@ -1466,7 +1466,8 @@ eth_igb_rx_queue_setup(struct rte_eth_dev *dev, rxq->pthresh = rx_conf->rx_thresh.pthresh; rxq->hthresh = rx_conf->rx_thresh.hthresh; rxq->wthresh = rx_conf->rx_thresh.wthresh; - if (rxq->wthresh > 0 && hw->mac.type == e1000_82576) + if (rxq->wthresh > 0 && + (hw->mac.type == e1000_82576 || hw->mac.type == e1000_vfadapt_i350)) rxq->wthresh = 1; rxq->drop_en = rx_conf->rx_drop_en; rxq->rx_free_thresh = rx_conf->rx_free_thresh; -- 1.9.3
[dpdk-dev] [PATCH v2] i40evf: fix link info update
The issue is the VF's link speed kept as 10G and status always was up.
It did not change even the physical link's status changed.
This patch fixes this issue to make VF's link info consistent with
physical link.
Fixes: 4861cde46116 (i40e: new poll mode driver)
Signed-off-by: Jingjing Wu
---
v2 change:
rebase on latest code.
doc/guides/rel_notes/release_16_04.rst | 6 ++
drivers/net/i40e/i40e_ethdev.h | 1 +
drivers/net/i40e/i40e_ethdev_vf.c | 37 --
3 files changed, 38 insertions(+), 6 deletions(-)
diff --git a/doc/guides/rel_notes/release_16_04.rst
b/doc/guides/rel_notes/release_16_04.rst
index d6e358f..4804109 100644
--- a/doc/guides/rel_notes/release_16_04.rst
+++ b/doc/guides/rel_notes/release_16_04.rst
@@ -382,6 +382,12 @@ Drivers
info for l3fwd to work well. Now there is an option for l3fwd to analysis
packet type softly, so enable vector driver by default.
+* **i40e: Fixed link info of VF
+
+ Previously, the VF's link speed kept as 10G and status always was up. It did
not
+ change even the physical link's status changed. Now this issue is fixed to
make
+ VF's link info consistent with physical link.
+
* **mlx5: Fixed possible crash during initialization.**
A crash could occur when failing to allocate private device context.
diff --git a/drivers/net/i40e/i40e_ethdev.h b/drivers/net/i40e/i40e_ethdev.h
index ce945fe..cfd2399 100644
--- a/drivers/net/i40e/i40e_ethdev.h
+++ b/drivers/net/i40e/i40e_ethdev.h
@@ -502,6 +502,7 @@ struct i40e_vf {
/* Event from pf */
bool dev_closed;
bool link_up;
+ enum i40e_aq_link_speed link_speed;
bool vf_reset;
volatile uint32_t pend_cmd; /* pending command not finished yet */
uint32_t cmd_retval; /* return value of the cmd response from PF */
diff --git a/drivers/net/i40e/i40e_ethdev_vf.c
b/drivers/net/i40e/i40e_ethdev_vf.c
index 8cf22ee..2bce69b 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -258,6 +258,8 @@ i40evf_read_pfmsg(struct rte_eth_dev *dev, struct
i40evf_arq_msg_info *data)
case I40E_VIRTCHNL_EVENT_LINK_CHANGE:
vf->link_up =
vpe->event_data.link_event.link_status;
+ vf->link_speed =
+ vpe->event_data.link_event.link_speed;
vf->pend_msg |= PFMSG_LINK_CHANGE;
PMD_DRV_LOG(INFO, "Link status update:%s",
vf->link_up ? "up" : "down");
@@ -1310,6 +1312,7 @@ i40evf_handle_pf_event(__rte_unused struct rte_eth_dev
*dev,
{
struct i40e_virtchnl_pf_event *pf_msg =
(struct i40e_virtchnl_pf_event *)msg;
+ struct i40e_vf *vf = I40EVF_DEV_PRIVATE_TO_VF(dev->data->dev_private);
switch (pf_msg->event) {
case I40E_VIRTCHNL_EVENT_RESET_IMPENDING:
@@ -1318,6 +1321,8 @@ i40evf_handle_pf_event(__rte_unused struct rte_eth_dev
*dev,
break;
case I40E_VIRTCHNL_EVENT_LINK_CHANGE:
PMD_DRV_LOG(DEBUG, "VIRTCHNL_EVENT_LINK_CHANGE event\n");
+ vf->link_up = pf_msg->event_data.link_event.link_status;
+ vf->link_speed = pf_msg->event_data.link_event.link_speed;
break;
case I40E_VIRTCHNL_EVENT_PF_DRIVER_CLOSE:
PMD_DRV_LOG(DEBUG, "VIRTCHNL_EVENT_PF_DRIVER_CLOSE event\n");
@@ -2121,14 +2126,34 @@ i40evf_dev_link_update(struct rte_eth_dev *dev,
* DPDK pf host provide interfacet to acquire link status
* while Linux driver does not
*/
- if (vf->version_major == I40E_DPDK_VERSION_MAJOR) {
+ if (vf->version_major == I40E_DPDK_VERSION_MAJOR)
i40evf_get_link_status(dev, &new_link);
- } else {
- /* Always assume it's up, for Linux driver PF host */
- new_link.link_speed = ETH_SPEED_NUM_10G;
+ else {
+ /* Linux driver PF host */
+ switch (vf->link_speed) {
+ case I40E_LINK_SPEED_100MB:
+ new_link.link_speed = ETH_SPEED_NUM_100M;
+ break;
+ case I40E_LINK_SPEED_1GB:
+ new_link.link_speed = ETH_SPEED_NUM_1G;
+ break;
+ case I40E_LINK_SPEED_10GB:
+ new_link.link_speed = ETH_SPEED_NUM_10G;
+ break;
+ case I40E_LINK_SPEED_20GB:
+ new_link.link_speed = ETH_SPEED_NUM_20G;
+ break;
+ case I40E_LINK_SPEED_40GB:
+ new_link.link_speed = ETH_SPEED_NUM_40G;
+ break;
+ default:
+ new_link.link_speed = ETH_SPEED_NUM_100M;
+ break;
+ }
+ /* full duplex only */
new_link.link_dupl
[dpdk-dev] [PATCH v2] doc: update overview
Update the overview.rst for e1000, igb, ixgbe. v2: - Some "X"s are put in the wrong place, correct it. Signed-off-by: Wenzhuo Lu --- doc/guides/nics/overview.rst | 94 ++-- 1 file changed, 47 insertions(+), 47 deletions(-) diff --git a/doc/guides/nics/overview.rst b/doc/guides/nics/overview.rst index 542479a..6c53826 100644 --- a/doc/guides/nics/overview.rst +++ b/doc/guides/nics/overview.rst @@ -86,62 +86,62 @@ Most of these differences are summarized below. e e e e e e c c c c c c = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = - link status X X X X X - link status eventX X X + link status X X X X X X X X X X X + link status event X X X X X X X queue status event X - Rx interrupt X X X X - queue start/stop X X X X X X X - MTU update X X - jumbo frame X X X X X X - scattered Rx X X X X X X X - LRO - TSO X X X X X X - promiscuous mode X X X X X X - allmulticast modeX X X X X X - unicast MAC filter X X X X + Rx interrupt X X X X X X X X X X X + queue start/stop X X X X X X X X X + MTU update X X X X X X X X + jumbo frame X X X X X X X X X X X X + scattered Rx X X X X X X X X X X X X X X + LRO X X X X + TSO X X X X X X X X X X X X + promiscuous mode X X X X X X X X X X X + allmulticast modeX X X X X X X X X X X X X + unicast MAC filter X X X X X X X X X X X multicast MAC filter X X X X - RSS hash X X X X X X - RSS key update X X X X X - RSS reta update X X X X X - VMDq X X - SR-IOV X X X - DCB X X - VLAN filter X X X X - ethertype filter X X - n-tuple filter - SYN filter - tunnel filterX X - flexible filter + RSS hash X X X X X X X X X X X + RSS key update X X X X X X X X X X + RSS reta update X X X X X X X X X X + VMDq X X X X X + SR-IOV X X X X X X + DCB X X X X X + VLAN filterX X X X X X X X X X X + ethertype filter X X X X X + n-tuple filter X X X + SYN filter X X X + tunnel filterX X X X + flexible filter X hash filter X X X X - flow directorX X - flow control X X X - rate limitation - traffic mirroringX X - CRC offload X X X X - VLAN offload X X X X - QinQ offload X X - L3 checksum offload X X X X - L4 checksum offload X X X X - inner L3 checksumX X X - inner L4 checksumX X X - packet type parsing X X X - timesync X X - basic stats X X X X X X X X - extended stats X X X X X + flow directorX X X X + flow control X X X X X X X + rate limitation X X + traffic mirroringX X X X + CRC offload X X X X X X X X X + VLAN offload X X X X X X X X X + QinQ offload X X X X X X X + L3 checksum offload X X X X X X X X X + L4 checksum offload X X X X X X X X X + inner L3 checksumX X X
[dpdk-dev] [PATCH] doc: update supported features of virtio
Update the overview.rst for virtio. Signed-off-by: Jianfeng Tan --- doc/guides/nics/overview.rst | 40 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/doc/guides/nics/overview.rst b/doc/guides/nics/overview.rst index ec1af46..bbe1394 100644 --- a/doc/guides/nics/overview.rst +++ b/doc/guides/nics/overview.rst @@ -87,18 +87,18 @@ Most of these differences are summarized below. c c c c c c = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = speed capabilities - link status X X X X X X X + link status X X X X X X X X X link status eventX X X X X queue status event X Rx interrupt X X X X - queue start/stop X X X X X X X X X + queue start/stop X X X X X X X X X X X MTU update X X X X jumbo frame X X X X X X X X - scattered Rx X X X X X X X X X + scattered Rx X X X X X X X X X X LRO TSO X X X X X X - promiscuous mode X X X X X X X X - allmulticast modeX X X X X X X X + promiscuous mode X X X X X X X X X X + allmulticast modeX X X X X X X X X X unicast MAC filter X X X X multicast MAC filter X X X X RSS hash X X X X X X X X @@ -107,8 +107,8 @@ Most of these differences are summarized below. VMDq X X SR-IOV X X X X X DCB X X - VLAN filter X X X X X X - ethertype filter X X + VLAN filter X X X X X X X X + ethertype filter X X X X n-tuple filter SYN filter tunnel filterX X @@ -127,23 +127,23 @@ Most of these differences are summarized below. inner L4 checksumX X X X packet type parsing X X X X X timesync X X - basic stats X X X X X X X X X X - extended stats X X X X X - stats per queue X X X X + basic stats X X X X X X X X X X X X + extended stats X X X X X X X + stats per queue X X X X X X EEPROM dump registers dump multiprocess aware X X X X X X - BSD nic_uio X X X X X - Linux UIOX X X X X X - Linux VFIO X X X X X + BSD nic_uio X X X X X X X + Linux UIOX X X X X X X X + Linux VFIO X X X X X X X other kdrv X - ARMv7 - ARMv8 - Power8 X X - TILE-Gx - x86-32 X X X X X X X X X - x86-64 X X X X X X X X X X - usage docX X X X + ARMv7 X X + ARMv8 X X + Power8 X X X X + TILE-Gx X X + x86-32 X X X X X X X X X X X + x86-64 X X X X X X X X X X X X + usage docX X X X X design doc perf doc ===
[dpdk-dev] [PATCH v2] virtio: use zeroed memory for simple TX header
Hi, On 4/5/2016 10:11 AM, Rich Lane wrote: > For simple TX the virtio-net header must be zeroed, but it was using memory > that had been initialized with indirect descriptor tables. This resulted in > "unsupported gso type" errors from librte_vhost. > > We can use the same memory for every descriptor to save cachelines in the > vswitch. Pointing all virtio_net_hdr into the same memory may brings performance, but how much? It also introduces difficulty to adding tso in future? Thanks, Jianfeng > > Fixes: 6dc5de3a (virtio: use indirect ring elements) > Signed-off-by: Rich Lane > --- > v1-v2: > - Use offsetof to get address of tx_hdr > > drivers/net/virtio/virtio_rxtx.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/virtio/virtio_rxtx.c > b/drivers/net/virtio/virtio_rxtx.c > index 2b88efd..ef21d8e 100644 > --- a/drivers/net/virtio/virtio_rxtx.c > +++ b/drivers/net/virtio/virtio_rxtx.c > @@ -377,7 +377,7 @@ virtio_dev_vring_start(struct virtqueue *vq, int > queue_type) > vq->vq_ring.desc[i + mid_idx].next = i; > vq->vq_ring.desc[i + mid_idx].addr = > vq->virtio_net_hdr_mem + > - i * vq->hw->vtnet_hdr_size; > + offsetof(struct virtio_tx_region, > tx_hdr); > vq->vq_ring.desc[i + mid_idx].len = > vq->hw->vtnet_hdr_size; > vq->vq_ring.desc[i + mid_idx].flags =
[dpdk-dev] [PATCH v2] virtio: use zeroed memory for simple TX header
On Mon, Apr 04, 2016 at 07:11:01PM -0700, Rich Lane wrote: > For simple TX the virtio-net header must be zeroed, but it was using memory > that had been initialized with indirect descriptor tables. This resulted in > "unsupported gso type" errors from librte_vhost. > > We can use the same memory for every descriptor to save cachelines in the > vswitch. > > Fixes: 6dc5de3a (virtio: use indirect ring elements) > Signed-off-by: Rich Lane Acked-by: Yuanhan Liu Thanks. --yliu
[dpdk-dev] [PATCH v2] virtio: use zeroed memory for simple TX header
On Tue, Apr 05, 2016 at 11:20:05AM +0800, Tan, Jianfeng wrote: > Hi, > > On 4/5/2016 10:11 AM, Rich Lane wrote: > >For simple TX the virtio-net header must be zeroed, but it was using memory > >that had been initialized with indirect descriptor tables. This resulted in > >"unsupported gso type" errors from librte_vhost. > > > >We can use the same memory for every descriptor to save cachelines in the > >vswitch. > > Pointing all virtio_net_hdr into the same memory may brings performance, but > how much? It also introduces difficulty to adding tso in future? simple rxtx will not be enabled when TSO is enabled. --yliu
[dpdk-dev] [PATCH v2] virtio: use zeroed memory for simple TX header
Hi, On 4/5/2016 12:26 PM, Yuanhan Liu wrote: > On Tue, Apr 05, 2016 at 11:20:05AM +0800, Tan, Jianfeng wrote: >> Hi, >> >> On 4/5/2016 10:11 AM, Rich Lane wrote: >>> For simple TX the virtio-net header must be zeroed, but it was using memory >>> that had been initialized with indirect descriptor tables. This resulted in >>> "unsupported gso type" errors from librte_vhost. >>> >>> We can use the same memory for every descriptor to save cachelines in the >>> vswitch. >> Pointing all virtio_net_hdr into the same memory may brings performance, but >> how much? It also introduces difficulty to adding tso in future? > simple rxtx will not be enabled when TSO is enabled. Yes, I was missing simple rxtx is conflicting with ETH_TXQ_FLAGS_NOOFFLOADS, which indicates that simple rxtx does not want to fill any fields in the hdr. Acked-by: Jianfeng Tan Thanks, Jianfeng > > --yliu
[dpdk-dev] [RFC] vhost-user public struct refactor (was Re: [PATCH RFC 2/4] vhost: make buf vector for scatter RX) local.
On Fri, Feb 19, 2016 at 03:06:50PM +0800, Yuanhan Liu wrote:
> On Fri, Feb 19, 2016 at 09:32:41AM +0300, Ilya Maximets wrote:
> > Array of buf_vector's is just an array for temporary storing information
> > about available descriptors. It used only locally in virtio_dev_merge_rx()
> > and there is no reason for that array to be shared.
> >
> > Fix that by allocating local buf_vec inside virtio_dev_merge_rx().
> >
> > Signed-off-by: Ilya Maximets
> > ---
> > lib/librte_vhost/rte_virtio_net.h | 1 -
> > lib/librte_vhost/vhost_rxtx.c | 45
> > ---
> > 2 files changed, 23 insertions(+), 23 deletions(-)
> >
> > diff --git a/lib/librte_vhost/rte_virtio_net.h
> > b/lib/librte_vhost/rte_virtio_net.h
> > index 10dcb90..ae1e4fb 100644
> > --- a/lib/librte_vhost/rte_virtio_net.h
> > +++ b/lib/librte_vhost/rte_virtio_net.h
> > @@ -91,7 +91,6 @@ struct vhost_virtqueue {
> > int kickfd; /**< Currently unused
> > as polling mode is enabled. */
> > int enabled;
> > uint64_treserved[16]; /**< Reserve some
> > spaces for future extension. */
> > - struct buf_vector buf_vec[BUF_VECTOR_MAX];/**< for
> > scatter RX. */
> > } __rte_cache_aligned;
>
> I like this kind of cleanup, however, it breaks ABI.
So, I was considering to add vhost-user Tx delayed-copy (or zero copy)
support recently, which comes to yet another ABI violation, as we need
add a new field to virtio_memory_regions struct to do guest phys addr
to host phys addr translation. You may ask, however, that why do we need
expose virtio_memory_regions struct to users at all?
You are right, we don't have to. And here is the thing: we exposed way
too many fields (or even structures) than necessary. Say, vhost_virtqueue
struct should NOT be exposed to user at all: application just need to
tell the right queue id to locate a specific queue, and that's all.
The structure should be defined in an internal header file. With that,
we could do any changes to it we want, without worrying about that we
may offense the painful ABI rules.
Similar changes could be done to virtio_net struct as well, just exposing
very few fields that are necessary and moving all others to an internal
structure.
Huawei then suggested a more radical yet much cleaner one: just exposing
a virtio_net handle to application, just like the way kernel exposes an
fd to user for locating a specific file. However, it's more than an ABI
change; it's also an API change: some fields are referenced by applications,
such as flags, virt_qp_nb. We could expose some new functions to access
them though.
I'd vote for this one, as it sounds very clean to me. This would also
solve the block issue of this patch. Though it would break OVS, I'm thinking
that'd be okay, as OVS has dependence on DPDK version: what we need to
do is just to send few patches to OVS, and let it points to next release,
say DPDK v16.07. Flavio, please correct me if I'm wrong.
Thoughts/comments?
--yliu
[dpdk-dev] [PATCH] vhost: fix coverity defect
Fix following coverity defect:
291 void
292 vhost_destroy_device(struct vhost_device_ctx ctx)
293 {
294 struct virtio_net *dev = get_device(ctx);
295
>>> CID 124565: Null pointer dereferences (NULL_RETURNS)
>>> Dereferencing a null pointer "dev".
Fixes: 45ca9c6f7bc6 ("vhost: get rid of linked list for devices")
Reported-by: John McNamara
Signed-off-by: Yuanhan Liu
---
lib/librte_vhost/virtio-net.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/lib/librte_vhost/virtio-net.c b/lib/librte_vhost/virtio-net.c
index 90da9ba..d870ad9 100644
--- a/lib/librte_vhost/virtio-net.c
+++ b/lib/librte_vhost/virtio-net.c
@@ -293,6 +293,9 @@ vhost_destroy_device(struct vhost_device_ctx ctx)
{
struct virtio_net *dev = get_device(ctx);
+ if (dev == NULL)
+ return;
+
if (dev->flags & VIRTIO_DEV_RUNNING)
notify_ops->destroy_device(dev);
--
1.9.0
[dpdk-dev] ACL trie build incrementally
Hi All, Can we build ACL trie in following way [lets say 4000 rules]: [I'm using DPDK 2.1.0] 1. Create context 2. Add 1000 rules, to the context [rte_acl_add_rules] 3. Then build the trie [rte_acl_build]for 1000 rules. 4. Then repeat the steps 2-3 for the remaining 3000 rules Is the above approach is ok? Or is there any other way to build the trie in incremental fashion? Regards, Varun
[dpdk-dev] [PATCH v1 1/1] cmdline: add any multi string mode to token string
Hi Olivier, > -Original Message- > From: Olivier Matz [mailto:olivier.matz at 6wind.com] > Sent: Monday, April 4, 2016 5:58 PM > >> Using token_len + 1 as the buffer size in the snprintf looks a bit > >> dangerous, as it won't protect from overflows. > >> > >> See the following example: > > > > > That's why snprintf() should still use STR_TOKEN_SIZE. > >> > > Okay, I see it. > > But this is a problem that we may need longer string than STR_TOKEN_SIZE > in multi token case. > > So what you think about adding new typedef cmdline_multi_string_t for > this case? > > For example: > > #define STR_MULTI_TOKEN_SIZE 1024 > > typedef char cmdline_multi_string_t[STR_MULTI_TOKEN_SIZE]; > > It should do the job, indeed. That's great. We want to set the value of the buffer to 4096, to not to regret in the future. > By the way, it would be nice to have an example of use. Based on this we plan a lot of changes in ip_pipeline example next release. Regards, Piotr
[dpdk-dev] [PATCH v2 0/4] fix creation of duplicate lpm and hash
Seen while trying to fix the func_reentrancy autotest. The series addresses several issues: 1/ Hash and lpm return a pointer to an existing object if the user requests the creation with an already existing name. This look dangerous: when an object is returned, the user does not know if it should be freed or not. 2/ There is a race condition in cuckoo_hash as the lock is not held in rte_hash_create(). We could find some cases where NULL is returned when the object already exists (ex: when rte_ring_create() fails). 3/ There is a race condition func_reentrancy that can fail even if the tested API behaves correctly. RFC -> v1: - split the patch in 4 patches - on error, set rte_errno to EEXIST when relevant - fix locking in cuckoo_hash creation v1 -> v2: - fix compilation issue in cuckoo hash - update the hash test to conform to the new behavior - rework locking modification in cuckoo_hash - passed autotests: hash, lpm, lpm6, func_reentrancy Olivier Matz (4): lpm: allocation of an existing object should fail hash: allocation of an existing object should fail hash: keep the list locked at creation autotest: fix func reentrancy app/test/test_func_reentrancy.c | 31 +++-- app/test/test_hash.c | 65 +--- app/test/test_lpm6.c | 2 +- lib/librte_hash/rte_cuckoo_hash.c | 70 ++- lib/librte_hash/rte_fbk_hash.c| 5 ++- lib/librte_lpm/rte_lpm.c | 10 -- lib/librte_lpm/rte_lpm6.c | 5 ++- 7 files changed, 101 insertions(+), 87 deletions(-) -- 2.1.4
[dpdk-dev] [PATCH v2 1/4] lpm: allocation of an existing object should fail
Change rte_lpm*_create() functions to return NULL and set rte_errno to
EEXIST when the object name already exists. This is the behavior
described in the API documentation in the header file.
These functions were returning a pointer to the existing object in that
case, but it is a problem as the caller did not know if the object had
to be freed or not.
Doing this change also makes the lpm API more consistent with the other
APIs (mempool, rings, ...).
Signed-off-by: Olivier Matz
---
app/test/test_lpm6.c | 2 +-
lib/librte_lpm/rte_lpm.c | 10 --
lib/librte_lpm/rte_lpm6.c | 5 -
3 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/app/test/test_lpm6.c b/app/test/test_lpm6.c
index 1f88d7a..b464342 100644
--- a/app/test/test_lpm6.c
+++ b/app/test/test_lpm6.c
@@ -222,7 +222,7 @@ test1(void)
/* rte_lpm6_create: lpm name == LPM2 */
lpm3 = rte_lpm6_create("LPM1", SOCKET_ID_ANY, &config);
- TEST_LPM_ASSERT(lpm3 == lpm1);
+ TEST_LPM_ASSERT(lpm3 == NULL);
rte_lpm6_free(lpm1);
rte_lpm6_free(lpm2);
diff --git a/lib/librte_lpm/rte_lpm.c b/lib/librte_lpm/rte_lpm.c
index bd3563f..73c9ec3 100644
--- a/lib/librte_lpm/rte_lpm.c
+++ b/lib/librte_lpm/rte_lpm.c
@@ -209,8 +209,11 @@ rte_lpm_create_v20(const char *name, int socket_id, int
max_rules,
if (strncmp(name, lpm->name, RTE_LPM_NAMESIZE) == 0)
break;
}
- if (te != NULL)
+ if (te != NULL) {
+ lpm = NULL;
+ rte_errno = EEXIST;
goto exit;
+ }
/* allocate tailq entry */
te = rte_zmalloc("LPM_TAILQ_ENTRY", sizeof(*te), 0);
@@ -280,8 +283,11 @@ rte_lpm_create_v1604(const char *name, int socket_id,
if (strncmp(name, lpm->name, RTE_LPM_NAMESIZE) == 0)
break;
}
- if (te != NULL)
+ if (te != NULL) {
+ lpm = NULL;
+ rte_errno = EEXIST;
goto exit;
+ }
/* allocate tailq entry */
te = rte_zmalloc("LPM_TAILQ_ENTRY", sizeof(*te), 0);
diff --git a/lib/librte_lpm/rte_lpm6.c b/lib/librte_lpm/rte_lpm6.c
index 4c44cd7..9877a30 100644
--- a/lib/librte_lpm/rte_lpm6.c
+++ b/lib/librte_lpm/rte_lpm6.c
@@ -182,8 +182,11 @@ rte_lpm6_create(const char *name, int socket_id,
if (strncmp(name, lpm->name, RTE_LPM6_NAMESIZE) == 0)
break;
}
- if (te != NULL)
+ if (te != NULL) {
+ lpm = NULL;
+ rte_errno = EEXIST;
goto exit;
+ }
/* allocate tailq entry */
te = rte_zmalloc("LPM6_TAILQ_ENTRY", sizeof(*te), 0);
--
2.1.4
[dpdk-dev] [PATCH v2 2/4] hash: allocation of an existing object should fail
Change rte_hash*_create() functions to return NULL and set rte_errno to
EEXIST when the object name already exists. This is the behavior
described in the API documentation in the header file.
These functions were returning a pointer to the existing object in that
case, but it is a problem as the caller did not know if the object had
to be freed or not.
Doing this change also makes the hash API more consistent with the other
APIs (mempool, rings, ...).
Signed-off-by: Olivier Matz
---
app/test/test_hash.c | 65 ++-
lib/librte_hash/rte_cuckoo_hash.c | 6 ++--
lib/librte_hash/rte_fbk_hash.c| 5 ++-
3 files changed, 31 insertions(+), 45 deletions(-)
diff --git a/app/test/test_hash.c b/app/test/test_hash.c
index 2f3d884..adbdb4a 100644
--- a/app/test/test_hash.c
+++ b/app/test/test_hash.c
@@ -805,15 +805,11 @@ fbk_hash_unit_test(void)
RETURN_IF_ERROR_FBK(handle == NULL, "fbk hash creation should have
succeeded");
tmp = rte_fbk_hash_create(&invalid_params_same_name_2);
- RETURN_IF_ERROR_FBK(tmp == NULL, "fbk hash creation should have
succeeded");
- if (tmp != handle) {
- printf("ERROR line %d: hashes should have been the
same\n", __LINE__);
- rte_fbk_hash_free(handle);
- rte_fbk_hash_free(tmp);
- return -1;
- }
+ if (tmp != NULL)
+ rte_fbk_hash_free(tmp);
+ RETURN_IF_ERROR_FBK(tmp != NULL, "fbk hash creation should have
failed");
- /* we are not freeing tmp or handle here because we need a hash list
+ /* we are not freeing handle here because we need a hash list
* to be not empty for the next test */
/* create a hash in non-empty list - good for coverage */
@@ -988,7 +984,7 @@ static int test_fbk_hash_find_existing(void)
*/
static int test_hash_creation_with_bad_parameters(void)
{
- struct rte_hash *handle;
+ struct rte_hash *handle, *tmp;
struct rte_hash_parameters params;
handle = rte_hash_create(NULL);
@@ -1038,7 +1034,23 @@ static int test_hash_creation_with_bad_parameters(void)
return -1;
}
+ /* test with same name should fail */
+ memcpy(¶ms, &ut_params, sizeof(params));
+ params.name = "same_name";
+ handle = rte_hash_create(¶ms);
+ if (handle == NULL) {
+ printf("Cannot create first hash table with 'same_name'\n");
+ return -1;
+ }
+ tmp = rte_hash_create(¶ms);
+ if (tmp != NULL) {
+ printf("Creation of hash table with same name should fail\n");
+ rte_hash_free(handle);
+ rte_hash_free(tmp);
+ return -1;
+ }
rte_hash_free(handle);
+
printf("# Test successful. No more errors expected\n");
return 0;
@@ -1051,12 +1063,12 @@ static int test_hash_creation_with_bad_parameters(void)
static int
test_hash_creation_with_good_parameters(void)
{
- struct rte_hash *handle, *tmp;
+ struct rte_hash *handle;
struct rte_hash_parameters params;
/* create with null hash function - should choose DEFAULT_HASH_FUNC */
memcpy(¶ms, &ut_params, sizeof(params));
- params.name = "same_name";
+ params.name = "name";
params.hash_func = NULL;
handle = rte_hash_create(¶ms);
if (handle == NULL) {
@@ -1064,37 +1076,6 @@ test_hash_creation_with_good_parameters(void)
return -1;
}
- /* this test is trying to create a hash with the same name as previous
one.
-* this should return a pointer to the hash we previously created.
-* the previous hash isn't freed exactly for the purpose of it being in
-* the hash list.
-*/
- memcpy(¶ms, &ut_params, sizeof(params));
- params.name = "same_name";
- tmp = rte_hash_create(¶ms);
-
- /* check if the returned handle is actually equal to the previous hash
*/
- if (handle != tmp) {
- rte_hash_free(handle);
- rte_hash_free(tmp);
- printf("Creating hash with existing name was successful\n");
- return -1;
- }
-
- /* try creating hash when there already are hashes in the list.
-* the previous hash is not freed to have a non-empty hash list.
-* the other hash that's in the list is still pointed to by "handle"
var.
-*/
- memcpy(¶ms, &ut_params, sizeof(params));
- params.name = "different_name";
- tmp = rte_hash_create(¶ms);
- if (tmp == NULL) {
- rte_hash_free(handle);
- printf("Creating hash with valid parameters failed\n");
- return -1;
- }
-
- rte_hash_free(tmp);
rte_hash_free(handle);
return 0;
diff --git a/lib/librte_hash/rte_cuckoo_hash.c
b/lib/librte_hash/rte_cuckoo_hash.c
index 71b5b76..ccec2db
[dpdk-dev] [PATCH v2 3/4] hash: keep the list locked at creation
To avoid a race condition while creating a new hash object, the
list has to be locked before the lookup, and released only once the
new object is added in the list.
As the lock is held by the rte_ring_create(), move its creation at the
beginning of the function and only take the lock after the ring is
created to avoid a deadlock.
Signed-off-by: Olivier Matz
---
lib/librte_hash/rte_cuckoo_hash.c | 68 ++-
1 file changed, 38 insertions(+), 30 deletions(-)
diff --git a/lib/librte_hash/rte_cuckoo_hash.c
b/lib/librte_hash/rte_cuckoo_hash.c
index ccec2db..63a74fd 100644
--- a/lib/librte_hash/rte_cuckoo_hash.c
+++ b/lib/librte_hash/rte_cuckoo_hash.c
@@ -226,19 +226,46 @@ rte_hash_create(const struct rte_hash_parameters *params)
if (params->extra_flag & RTE_HASH_EXTRA_FLAGS_TRANS_MEM_SUPPORT)
hw_trans_mem_support = 1;
+ /* Store all keys and leave the first entry as a dummy entry for
lookup_bulk */
+ if (hw_trans_mem_support)
+ /*
+* Increase number of slots by total number of indices
+* that can be stored in the lcore caches
+* except for the first cache
+*/
+ num_key_slots = params->entries + (RTE_MAX_LCORE - 1) *
+ LCORE_CACHE_SIZE + 1;
+ else
+ num_key_slots = params->entries + 1;
+
+ snprintf(ring_name, sizeof(ring_name), "HT_%s", params->name);
+ r = rte_ring_create(ring_name, rte_align32pow2(num_key_slots),
+ params->socket_id, 0);
+ if (r == NULL) {
+ RTE_LOG(ERR, HASH, "memory allocation failed\n");
+ goto err;
+ }
+
snprintf(hash_name, sizeof(hash_name), "HT_%s", params->name);
- /* Guarantee there's no existing */
- h = rte_hash_find_existing(params->name);
- if (h != NULL) {
+ rte_rwlock_write_lock(RTE_EAL_TAILQ_RWLOCK);
+
+ /* guarantee there's no existing: this is normally already checked
+* by ring creation above */
+ TAILQ_FOREACH(te, hash_list, next) {
+ h = (struct rte_hash *) te->data;
+ if (strncmp(params->name, h->name, RTE_HASH_NAMESIZE) == 0)
+ break;
+ }
+ if (te != NULL) {
rte_errno = EEXIST;
- return NULL;
+ goto err_unlock;
}
te = rte_zmalloc("HASH_TAILQ_ENTRY", sizeof(*te), 0);
if (te == NULL) {
RTE_LOG(ERR, HASH, "tailq entry allocation failed\n");
- goto err;
+ goto err_unlock;
}
h = (struct rte_hash *)rte_zmalloc_socket(hash_name, sizeof(struct
rte_hash),
@@ -246,7 +273,7 @@ rte_hash_create(const struct rte_hash_parameters *params)
if (h == NULL) {
RTE_LOG(ERR, HASH, "memory allocation failed\n");
- goto err;
+ goto err_unlock;
}
const uint32_t num_buckets = rte_align32pow2(params->entries)
@@ -258,23 +285,10 @@ rte_hash_create(const struct rte_hash_parameters *params)
if (buckets == NULL) {
RTE_LOG(ERR, HASH, "memory allocation failed\n");
- goto err;
+ goto err_unlock;
}
const uint32_t key_entry_size = sizeof(struct rte_hash_key) +
params->key_len;
-
- /* Store all keys and leave the first entry as a dummy entry for
lookup_bulk */
- if (hw_trans_mem_support)
- /*
-* Increase number of slots by total number of indices
-* that can be stored in the lcore caches
-* except for the first cache
-*/
- num_key_slots = params->entries + (RTE_MAX_LCORE - 1) *
- LCORE_CACHE_SIZE + 1;
- else
- num_key_slots = params->entries + 1;
-
const uint64_t key_tbl_size = (uint64_t) key_entry_size * num_key_slots;
k = rte_zmalloc_socket(NULL, key_tbl_size,
@@ -282,7 +296,7 @@ rte_hash_create(const struct rte_hash_parameters *params)
if (k == NULL) {
RTE_LOG(ERR, HASH, "memory allocation failed\n");
- goto err;
+ goto err_unlock;
}
/*
@@ -325,14 +339,6 @@ rte_hash_create(const struct rte_hash_parameters *params)
h->rte_hash_cmp_eq = memcmp;
#endif
- snprintf(ring_name, sizeof(ring_name), "HT_%s", params->name);
- r = rte_ring_create(ring_name, rte_align32pow2(num_key_slots),
- params->socket_id, 0);
- if (r == NULL) {
- RTE_LOG(ERR, HASH, "memory allocation failed\n");
- goto err;
- }
-
if (hw_trans_mem_support) {
h->local_free_slots = rte_zmalloc_socket(NULL,
sizeof(struct lcore_cache) * RTE_MAX_LCORE,
@@ -359,13 +365,15 @@ rte_hash_create(const struct
[dpdk-dev] [PATCH v2 4/4] autotest: fix func reentrancy
The previous code in func_reentrancy autotest was doing in parallel
something close to:
name = "common_name";
do several times {
obj = allocate_an_object(name) // obj = ring, mempool, hash, lpm, ...
if (obj == NULL && lookup(name) == NULL)
return TEST_FAIL;
}
This code is not safe. For instance:
mempool_create() is called on core 0, it creates a ring. At the same
time on core 1, mempool_create() is called too and the creation of the
ring fails (EEXIST). But the mempool lookup can fail on core 1 if
the mempool is not added in the list by core 0.
This commit fixes the func_reentrancy autotest that now works with all
tested class of objects.
Signed-off-by: Olivier Matz
---
app/test/test_func_reentrancy.c | 31 +--
1 file changed, 21 insertions(+), 10 deletions(-)
diff --git a/app/test/test_func_reentrancy.c b/app/test/test_func_reentrancy.c
index 5d09296..300a3bc 100644
--- a/app/test/test_func_reentrancy.c
+++ b/app/test/test_func_reentrancy.c
@@ -83,6 +83,7 @@ typedef void (*case_clean_t)(unsigned lcore_id);
#define MAX_LCORES RTE_MAX_MEMZONE / (MAX_ITER_TIMES * 4U)
+static rte_atomic32_t obj_count = RTE_ATOMIC32_INIT(0);
static rte_atomic32_t synchro = RTE_ATOMIC32_INIT(0);
#define WAIT_SYNCHRO_FOR_SLAVES() do{ \
@@ -100,6 +101,7 @@ test_eal_init_once(__attribute__((unused)) void *arg)
WAIT_SYNCHRO_FOR_SLAVES();
+ rte_atomic32_set(&obj_count, 1); /* silent the check in the caller */
if (rte_eal_init(0, NULL) != -1)
return -1;
@@ -122,8 +124,8 @@ ring_create_lookup(__attribute__((unused)) void *arg)
/* create the same ring simultaneously on all threads */
for (i = 0; i < MAX_ITER_TIMES; i++) {
rp = rte_ring_create("fr_test_once", 4096, SOCKET_ID_ANY, 0);
- if ((NULL == rp) && (rte_ring_lookup("fr_test_once") == NULL))
- return -1;
+ if (rp != NULL)
+ rte_atomic32_inc(&obj_count);
}
/* create/lookup new ring several times */
@@ -172,8 +174,8 @@ mempool_create_lookup(__attribute__((unused)) void *arg)
NULL, NULL,
my_obj_init, NULL,
SOCKET_ID_ANY, 0);
- if ((NULL == mp) && (rte_mempool_lookup("fr_test_once") ==
NULL))
- return -1;
+ if (mp != NULL)
+ rte_atomic32_inc(&obj_count);
}
/* create/lookup new ring several times */
@@ -238,8 +240,8 @@ hash_create_free(__attribute__((unused)) void *arg)
hash_params.name = "fr_test_once";
for (i = 0; i < MAX_ITER_TIMES; i++) {
handle = rte_hash_create(&hash_params);
- if ((NULL == handle) && (rte_hash_find_existing("fr_test_once")
== NULL))
- return -1;
+ if (handle != NULL)
+ rte_atomic32_inc(&obj_count);
}
/* create mutiple times simultaneously */
@@ -306,8 +308,8 @@ fbk_create_free(__attribute__((unused)) void *arg)
fbk_params.name = "fr_test_once";
for (i = 0; i < MAX_ITER_TIMES; i++) {
handle = rte_fbk_hash_create(&fbk_params);
- if ((NULL == handle) &&
(rte_fbk_hash_find_existing("fr_test_once") == NULL))
- return -1;
+ if (handle != NULL)
+ rte_atomic32_inc(&obj_count);
}
/* create mutiple fbk tables simultaneously */
@@ -372,8 +374,8 @@ lpm_create_free(__attribute__((unused)) void *arg)
/* create the same lpm simultaneously on all threads */
for (i = 0; i < MAX_ITER_TIMES; i++) {
lpm = rte_lpm_create("fr_test_once", SOCKET_ID_ANY, &config);
- if ((NULL == lpm) && (rte_lpm_find_existing("fr_test_once") ==
NULL))
- return -1;
+ if (lpm != NULL)
+ rte_atomic32_inc(&obj_count);
}
/* create mutiple fbk tables simultaneously */
@@ -432,10 +434,12 @@ launch_test(struct test_case *pt_case)
unsigned lcore_id;
unsigned cores_save = rte_lcore_count();
unsigned cores = RTE_MIN(cores_save, MAX_LCORES);
+ unsigned count;
if (pt_case->func == NULL)
return -1;
+ rte_atomic32_set(&obj_count, 0);
rte_atomic32_set(&synchro, 0);
RTE_LCORE_FOREACH_SLAVE(lcore_id) {
@@ -462,6 +466,13 @@ launch_test(struct test_case *pt_case)
pt_case->clean(lcore_id);
}
+ count = rte_atomic32_read(&obj_count);
+ if (count != 1) {
+ printf("%s: common object allocated %d times (should be 1)\n",
+ pt_case->name, count);
+ ret = -1;
+ }
+
return ret;
}
--
2.1.4
[dpdk-dev] [PATCH] autotests: increase memory for group_2
The hash test (located in group_2) may require more than 64MB of memory,
especially if the memory is physically fragmented, making the test to
fail. So increase the memory to 128MB to avoid this issue.
Signed-off-by: Olivier Matz
---
app/test/autotest_data.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/app/test/autotest_data.py b/app/test/autotest_data.py
index 6f34d6b..dde4511 100644
--- a/app/test/autotest_data.py
+++ b/app/test/autotest_data.py
@@ -109,7 +109,7 @@ parallel_test_group_list = [
},
{
"Prefix": "group_2",
- "Memory" : "64",
+ "Memory" : "128",
"Tests" :
[
{
--
2.1.4
[dpdk-dev] [PATCH] cryptodev: Remove EXPERIMENTAL label
The cryptodev API was introduced in the DPDK 2.2 release. Since then it has - been reviewed and iterated for the DPDK 16.04 release - had extensive use by the l2fwd-crypto app, the ipsec-secgw example app, the test app. We believe it is now stable and the EXPERIMENTAL label should be removed. Signed-off-by: Fiona Trahe --- MAINTAINERS | 2 +- config/common_base | 1 - lib/librte_cryptodev/rte_cryptodev.h | 2 -- 3 files changed, 1 insertion(+), 4 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 85d72ca..a7570cd 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -231,7 +231,7 @@ M: Thomas Monjalon F: lib/librte_ether/ F: scripts/test-null.sh -Crypto API - EXPERIMENTAL +Crypto API M: Declan Doherty F: lib/librte_cryptodev/ F: app/test/test_cryptodev* diff --git a/config/common_base b/config/common_base index abd6a64..0124e86 100644 --- a/config/common_base +++ b/config/common_base @@ -327,7 +327,6 @@ CONFIG_RTE_PMD_PACKET_PREFETCH=y # # Compile generic crypto device library -# EXPERIMENTAL: API may change without prior notice # CONFIG_RTE_LIBRTE_CRYPTODEV=y CONFIG_RTE_LIBRTE_CRYPTODEV_DEBUG=n diff --git a/lib/librte_cryptodev/rte_cryptodev.h b/lib/librte_cryptodev/rte_cryptodev.h index b599c95..1427dcf 100644 --- a/lib/librte_cryptodev/rte_cryptodev.h +++ b/lib/librte_cryptodev/rte_cryptodev.h @@ -40,8 +40,6 @@ * Defines RTE Crypto Device APIs for the provisioning of cipher and * authentication operations. * - * @b EXPERIMENTAL: this API may change without prior notice - * */ #ifdef __cplusplus -- 2.1.0
[dpdk-dev] [PATCH] doc: update supported features of virtio
2016-04-05 03:58, Jianfeng Tan: > - ethertype filter X X > + ethertype filter X X > X X Are you sure about ethertype filter in virtio? I do not see it. > - Power8 X X > - TILE-Gx > + Power8 X X > X X > + TILE-Gx > X X I don't think DPDK virtio is currently supported on these architectures.
[dpdk-dev] [PATCH] gcc compiler option -Og warnings fix
2016-04-04 23:03, Wiles, Keith:
> >2016-04-01 14:20, Keith Wiles:
> >> The new compiler option -Og causes a few warning on variables
> >> being used before being set warnings.
> >
> >Sometimes the compiler is wrong. It seems this option makes it
> >even wronger. Why not use -Wno-error with -Og?
>
> Did you want me to make these changes or just request everyone to use
> -Wno-error with -Og?
I was suggesting that everyone can use -Wno-error when using -Og.
> If you want a new patch from me on these changes it will be
> toward the weekend after I get back home from traveling.
If some driver maintainers think there are some things to fix,
they are free to send a patch by themselves before the end of the week.
> >More details below:
> >
> >> lib/librte_eal/linuxapp/eal/eal_pci_uio.c | 2 +-
> >> lib/librte_lpm/rte_lpm6.c | 1 +
> >> lib/librte_vhost/vhost_rxtx.c | 4 ++--
> >
> >There are also some warnings in mlx drivers, solved with patch below:
> >
> >--- a/drivers/net/mlx4/mlx4.c
> >+++ b/drivers/net/mlx4/mlx4.c
> >@@ -5415,7 +5415,7 @@ mlx4_pci_devinit(struct rte_pci_driver *pci_drv,
> >struct rte_pci_device *pci_dev)
> >int err = 0;
> >struct ibv_context *attr_ctx = NULL;
> >struct ibv_device_attr device_attr;
> >- unsigned int vf;
> >+ unsigned int vf = 0;
> >int idx;
> >int i;
> >
> >--- a/drivers/net/mlx5/mlx5.c
> >+++ b/drivers/net/mlx5/mlx5.c
> >@@ -260,8 +260,8 @@ mlx5_pci_devinit(struct rte_pci_driver *pci_drv, struct
> >rte_pci_device *pci_dev)
> >int err = 0;
> >struct ibv_context *attr_ctx = NULL;
> >struct ibv_device_attr device_attr;
> >- unsigned int vf;
> >- unsigned int mps;
> >+ unsigned int vf = 0;
> >+ unsigned int mps = 0;
> >int idx;
> >int i;
> >
> >> --- a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
> >> +++ b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
> >> @@ -152,7 +152,7 @@ pci_get_uio_dev(struct rte_pci_device *dev, char
> >> *dstbuf,
> >> unsigned int buflen, int create)
> >> {
> >>struct rte_pci_addr *loc = &dev->addr;
> >> - unsigned int uio_num;
> >> + unsigned int uio_num = 0;
> >
> >This one is OK to fix.
> >
> >> --- a/lib/librte_lpm/rte_lpm6.c
> >> +++ b/lib/librte_lpm/rte_lpm6.c
> >> @@ -381,6 +381,7 @@ add_step(struct rte_lpm6 *lpm, struct
> >> rte_lpm6_tbl_entry *tbl,
> >>int8_t bitshift;
> >>uint8_t bits_covered;
> >>
> >> + *tbl_next = NULL;
> >>/*
> >> * Calculate index to the table based on the number and position
> >> * of the bytes being inspected in this step.
> >
> >It would be more logical to set this variable in the right condition branch:
> >--- a/lib/librte_lpm/rte_lpm6.c
> >+++ b/lib/librte_lpm/rte_lpm6.c
> >@@ -429,6 +429,7 @@ add_step(struct rte_lpm6 *lpm, struct rte_lpm6_tbl_entry
> >*tbl,
> >}
> >}
> >
> >+ *tbl_next = NULL;
> >return 0;
> >}
> >
> >> --- a/lib/librte_vhost/vhost_rxtx.c
> >> +++ b/lib/librte_vhost/vhost_rxtx.c
> >> @@ -295,7 +295,7 @@ virtio_dev_rx(struct virtio_net *dev, uint16_t
> >> queue_id,
> >>for (i = 0; i < count; i++) {
> >>uint16_t desc_idx = desc_indexes[i];
> >>uint16_t used_idx = (res_start_idx + i) & (vq->size - 1);
> >> - uint32_t copied;
> >> + uint32_t copied = 0;
> >
> >This variable is not used if copy_mbuf_to_desc fails, so it is always
> >initialised before being used.
> >We can workaround the silly compiler while avoiding a performance hit
> >by resetting the variable only in the error case of copy_mbuf_to_desc:
> >
> >--- a/lib/librte_vhost/vhost_rxtx.c
> >+++ b/lib/librte_vhost/vhost_rxtx.c
> >@@ -147,8 +147,10 @@ copy_mbuf_to_desc(struct virtio_net *dev, struct
> >vhost_virtqueue *vq,
> >struct virtio_net_hdr_mrg_rxbuf virtio_hdr = {{0, 0, 0, 0, 0, 0}, 0};
> >
> >desc = &vq->desc[desc_idx];
> >- if (unlikely(desc->len < vq->vhost_hlen))
> >+ if (unlikely(desc->len < vq->vhost_hlen)) {
> >+ *copied = 0;
> >return -1;
> >+ }
> >
> >>err = copy_mbuf_to_desc(dev, vq, pkts[i], desc_idx, &copied);
> >> @@ -531,7 +531,7 @@ virtio_dev_merge_rx(struct virtio_net *dev, uint16_t
> >> queue_id,
> >> {
> >>struct vhost_virtqueue *vq;
> >>uint32_t pkt_idx = 0, nr_used = 0;
> >> - uint16_t start, end;
> >> + uint16_t start = 0, end = 0;
> >
> >I don't understand this one because the variables are not used if
> >reserve_avail_buf_mergeable fails.
> >I don't see any smart workaround.
> >Huawei, Yuanhan, can we expect a little slowdown with this change?
> >
> >
>
>
> Regards,
> Keith
>
>
>
>
[dpdk-dev] [PATCH] doc: update supported features of virtio
Hi, On 4/5/2016 4:20 PM, Thomas Monjalon wrote: > 2016-04-05 03:58, Jianfeng Tan: >> - ethertype filter X X >> + ethertype filter X X >> X X > Are you sure about ethertype filter in virtio? I do not see it. Sorry, I mistake it for mac filter. ethertype filter is not supported in virtio. > >> - Power8 X X >> - TILE-Gx >> + Power8 X X >> X X >> + TILE-Gx >> X X > I don't think DPDK virtio is currently supported on these architectures. Sorry, I forget to exclude these two. config/common_base:CONFIG_RTE_LIBRTE_VIRTIO_PMD=y config/defconfig_ppc_64-power8-linuxapp-gcc:CONFIG_RTE_LIBRTE_VIRTIO_PMD=n config/defconfig_tile-tilegx-linuxapp-gcc:CONFIG_RTE_LIBRTE_VIRTIO_PMD=n
[dpdk-dev] [PATCH] doc: update supported features of virtio
2016-04-05 16:30, Tan, Jianfeng: > Hi, > > On 4/5/2016 4:20 PM, Thomas Monjalon wrote: > > 2016-04-05 03:58, Jianfeng Tan: > >> - ethertype filter X X > >> + ethertype filter X X > >> X X > > Are you sure about ethertype filter in virtio? I do not see it. > > Sorry, I mistake it for mac filter. ethertype filter is not supported in > virtio. > > > > >> - Power8 X X > >> - TILE-Gx > >> + Power8 X X > >> X X > >> + TILE-Gx > >> X X > > I don't think DPDK virtio is currently supported on these architectures. > > Sorry, I forget to exclude these two. > > config/common_base:CONFIG_RTE_LIBRTE_VIRTIO_PMD=y > config/defconfig_ppc_64-power8-linuxapp-gcc:CONFIG_RTE_LIBRTE_VIRTIO_PMD=n > config/defconfig_tile-tilegx-linuxapp-gcc:CONFIG_RTE_LIBRTE_VIRTIO_PMD=n OK Please send a v2 and get a review from a virtio maintainer. Thanks
[dpdk-dev] [RFC] vhost-user public struct refactor (was Re: [PATCH RFC 2/4] vhost: make buf vector for scatter RX) local.
2016-04-05 13:47, Yuanhan Liu: > So, I was considering to add vhost-user Tx delayed-copy (or zero copy) > support recently, which comes to yet another ABI violation, as we need > add a new field to virtio_memory_regions struct to do guest phys addr > to host phys addr translation. You may ask, however, that why do we need > expose virtio_memory_regions struct to users at all? > > You are right, we don't have to. And here is the thing: we exposed way > too many fields (or even structures) than necessary. Say, vhost_virtqueue > struct should NOT be exposed to user at all: application just need to > tell the right queue id to locate a specific queue, and that's all. > The structure should be defined in an internal header file. With that, > we could do any changes to it we want, without worrying about that we > may offense the painful ABI rules. > > Similar changes could be done to virtio_net struct as well, just exposing > very few fields that are necessary and moving all others to an internal > structure. > > Huawei then suggested a more radical yet much cleaner one: just exposing > a virtio_net handle to application, just like the way kernel exposes an > fd to user for locating a specific file. However, it's more than an ABI > change; it's also an API change: some fields are referenced by applications, > such as flags, virt_qp_nb. We could expose some new functions to access > them though. > > I'd vote for this one, as it sounds very clean to me. This would also > solve the block issue of this patch. Though it would break OVS, I'm thinking > that'd be okay, as OVS has dependence on DPDK version: what we need to > do is just to send few patches to OVS, and let it points to next release, > say DPDK v16.07. Flavio, please correct me if I'm wrong. > > Thoughts/comments? Do you plan to send a deprecation notice to change API in 16.07?
[dpdk-dev] [RFC] vhost user: add error handling for fd > 1023
Hi,
thank you for the response on this.
The described fault situation arises due to the fact that there is a bug
in an OpenStack component, Neutron or Nova, that fails to release ports
on VM deletion. This typically leads to an accumulation of 1-2 file
descriptors per unreleased port. It could also arise when allocating a large
number (~500?) of vhost user ports and connecting them all to VMs.
Unfortunately I don't have a DPDK design test environment, thus I have
not tried to reproduce the issue with DPDK only. But, I assume that by
creating enough vhost user devices it can be triggered. File descriptors
would be "consumed" by calls to rte_vhost_driver_register() and
user_set_mem_table() both, presumably.
The key point, I think, is that more than one file descriptor is used per
vhost user device. This means that there is no real relation between the
number of devices and the number of file descriptors in use.
As for using select() or epoll(), I don't know the strength of the
portability
argument. It is possible that epoll() would exhibit some better properties,
like simpler code in the polling loop, but I have yet seen too little of the
total picture to venture an opinion.
On 03/30/2016 11:05 AM, Xie, Huawei wrote:
> On 3/18/2016 5:15 PM, Patrik Andersson wrote:
>> Protect against DPDK crash when allocation of listen fd >= 1023.
>> For events on fd:s >1023, the current implementation will trigger
>> an abort due to access outside of allocated bit mask.
>>
>> Corrections would include:
>>
>>* Match fdset_add() signature in fd_man.c to fd_man.h
>>* Handling of return codes from fdset_add()
>>* Addition of check of fd number in fdset_add_fd()
>>
>> ---
>>
>> The rationale behind the suggested code change is that,
>> fdset_event_dispatch() could attempt access outside of the FD_SET
>> bitmask if there is an event on a file descriptor that in turn
>> looks up a virtio file descriptor with a value > 1023.
>> Such an attempt will lead to an abort() and a restart of any
>> vswitch using DPDK.
>>
>> A discussion topic exist in the ovs-discuss mailing list that can
>> provide a little more background:
>>
>> http://openvswitch.org/pipermail/discuss/2016-February/020243.html
> Thanks for catching this. Could you give more details on how to
> accumulating fds?
> The buggy code is based on the fact that FD_SETSIZE limits the number of
> file descriptors, which might be true on Windows. However from the
> manual, it says clearly it limits the value of file descriptors.
> The use of select is for portability. I have been wondering if it is
> truly that important. Use poll could simplify the code a bit, for
> example we need add timeout to select so that another thread could
> insert/remove a fd into/from the monitored list.
>
> Any comments on using poll/epoll?
>
>> Signed-off-by: Patrik Andersson
>> ---
>> lib/librte_vhost/vhost_user/fd_man.c | 11 ++-
>> lib/librte_vhost/vhost_user/vhost-net-user.c | 22 --
>> 2 files changed, 26 insertions(+), 7 deletions(-)
>>
>> diff --git a/lib/librte_vhost/vhost_user/fd_man.c
>> b/lib/librte_vhost/vhost_user/fd_man.c
>> index 087aaed..c691339 100644
>> --- a/lib/librte_vhost/vhost_user/fd_man.c
>> +++ b/lib/librte_vhost/vhost_user/fd_man.c
>> @@ -71,20 +71,22 @@ fdset_find_free_slot(struct fdset *pfdset)
>> return fdset_find_fd(pfdset, -1);
>> }
>>
>> -static void
>> +static int
>> fdset_add_fd(struct fdset *pfdset, int idx, int fd,
>> fd_cb rcb, fd_cb wcb, void *dat)
>> {
>> struct fdentry *pfdentry;
>>
>> -if (pfdset == NULL || idx >= MAX_FDS)
> seems we had better change the definition of MAX_FDS and
> MAX_VHOST_SERVER to FD_SETSIZE or add some build time check.
I'm not sure how build time checks would help, in my build the
MAX_FDS == FD_SETSIZE == 1024. Here it is not actually possible to
support 1024 vhost user devices, because of the file descriptor limitation.
In my opinion the problem is that the assumption: number of vhost
user device == number of file descriptors does not hold. What the actual
relation might be hard to determine with any certainty.
Use of epoll() instead of select() might relax checking to the number
of vhost user devices only.
In addition the return value of the fdset_add_fd() should be checked
(note: in the corresponding include file the function signature is "static
int", not "static void" as in the code).
>
>> -return;
>> +if (pfdset == NULL || idx >= MAX_FDS || fd >= FD_SETSIZE)
>> +return -1;
>>
>> pfdentry = &pfdset->fd[idx];
>> pfdentry->fd = fd;
>> pfdentry->rcb = rcb;
>> pfdentry->wcb = wcb;
>> pfdentry->dat = dat;
>> +
>> +return 0;
>> }
>>
>> /**
>> @@ -150,12 +152,11 @@ fdset_add(struct fdset *pfdset, int fd, fd_cb rcb,
>> fd_cb wcb, void *dat)
>>
>> /* Find a free slot in the list. */
>> i = fdset_find_free_slot(pfdset);
>> -if (i == -1) {
>> +if (i == -1 |
[dpdk-dev] [PATCH v2 1/1] cmdline: add any multi string mode to token string
While parsing token string there may be several modes:
- fixed single string
- multi-choice single string
- any single string
This patch add one more mode - any multi string.
Signed-off-by: Piotr Azarewicz
---
v2 changes:
- add cmdline_multi_string_t type for the new mode
app/test/test_cmdline_string.c| 15 ++
lib/librte_cmdline/cmdline_parse.c|8 ++
lib/librte_cmdline/cmdline_parse.h|3 ++
lib/librte_cmdline/cmdline_parse_string.c | 43 +
lib/librte_cmdline/cmdline_parse_string.h |7 +
5 files changed, 60 insertions(+), 16 deletions(-)
diff --git a/app/test/test_cmdline_string.c b/app/test/test_cmdline_string.c
index 915a7d7..c5bb9c0 100644
--- a/app/test/test_cmdline_string.c
+++ b/app/test/test_cmdline_string.c
@@ -35,6 +35,7 @@
#include
#include
+#include
#include
#include
@@ -65,9 +66,10 @@ struct string_elt_str string_elt_strs[] = {
{"one#two\nwith\nnewlines#three", "two\nwith\nnewlines", 1},
};
-#if CMDLINE_TEST_BUFSIZE < STR_TOKEN_SIZE
+#if (CMDLINE_TEST_BUFSIZE < STR_TOKEN_SIZE) \
+|| (CMDLINE_TEST_BUFSIZE < STR_MULTI_TOKEN_SIZE)
#undef CMDLINE_TEST_BUFSIZE
-#define CMDLINE_TEST_BUFSIZE STR_TOKEN_SIZE
+#define CMDLINE_TEST_BUFSIZE RTE_MAX(STR_TOKEN_SIZE, STR_MULTI_TOKEN_SIZE)
#endif
struct string_nb_str {
@@ -97,6 +99,11 @@ struct string_parse_str string_parse_strs[] = {
{"two with\rgarbage\tcharacters\n",
"one#two with\rgarbage\tcharacters\n#three",
"two with\rgarbage\tcharacters\n"},
+ {"one two", "one", "one"}, /* fixed string */
+ {"one two", TOKEN_STRING_MULTI, "one two"}, /* multi string */
+ {"one two", NULL, "one"}, /* any string */
+ {"one two #three", TOKEN_STRING_MULTI, "one two "},
+ /* multi string with comment */
};
@@ -124,7 +131,6 @@ struct string_invalid_str string_invalid_strs[] = {
"toolong!!!toolong!!!toolong!!!toolong!!!toolong!!!toolong!!!"
"toolong!!!toolong!!!toolong!!!toolong!!!toolong!!!toolong!!!"
"toolong!!!" },
-{"invalid", ""},
{"", "invalid"}
};
@@ -350,8 +356,7 @@ test_parse_string_valid(void)
string_parse_strs[i].str, help_str);
return -1;
}
- if (strncmp(buf, string_parse_strs[i].result,
- sizeof(string_parse_strs[i].result) - 1) != 0) {
+ if (strcmp(buf, string_parse_strs[i].result) != 0) {
printf("Error: result mismatch!\n");
return -1;
}
diff --git a/lib/librte_cmdline/cmdline_parse.c
b/lib/librte_cmdline/cmdline_parse.c
index 24a6ed6..b496067 100644
--- a/lib/librte_cmdline/cmdline_parse.c
+++ b/lib/librte_cmdline/cmdline_parse.c
@@ -118,6 +118,14 @@ cmdline_isendoftoken(char c)
return 0;
}
+int
+cmdline_isendofcommand(char c)
+{
+ if (!c || iscomment(c) || isendofline(c))
+ return 1;
+ return 0;
+}
+
static unsigned int
nb_common_chars(const char * s1, const char * s2)
{
diff --git a/lib/librte_cmdline/cmdline_parse.h
b/lib/librte_cmdline/cmdline_parse.h
index 4b25c45..4ac05d6 100644
--- a/lib/librte_cmdline/cmdline_parse.h
+++ b/lib/librte_cmdline/cmdline_parse.h
@@ -184,6 +184,9 @@ int cmdline_complete(struct cmdline *cl, const char *buf,
int *state,
* isendofline(c)) */
int cmdline_isendoftoken(char c);
+/* return true if(!c || iscomment(c) || isendofline(c)) */
+int cmdline_isendofcommand(char c);
+
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_cmdline/cmdline_parse_string.c
b/lib/librte_cmdline/cmdline_parse_string.c
index 45883b3..35917a7 100644
--- a/lib/librte_cmdline/cmdline_parse_string.c
+++ b/lib/librte_cmdline/cmdline_parse_string.c
@@ -76,9 +76,10 @@ struct cmdline_token_ops cmdline_token_string_ops = {
.get_help = cmdline_get_help_string,
};
-#define MULTISTRING_HELP "Mul-choice STRING"
-#define ANYSTRING_HELP "Any STRING"
-#define FIXEDSTRING_HELP "Fixed STRING"
+#define CHOICESTRING_HELP "Mul-choice STRING"
+#define ANYSTRING_HELP"Any STRING"
+#define ANYSTRINGS_HELP "Any STRINGS"
+#define FIXEDSTRING_HELP "Fixed STRING"
static unsigned int
get_token_len(const char *s)
@@ -123,8 +124,8 @@ cmdline_parse_string(cmdline_parse_token_hdr_t *tk, const
char *buf, void *res,
sd = &tk2->string_data;
- /* fixed string */
- if (sd->str) {
+ /* fixed string (known single token) */
+ if ((sd->str != NULL) && (strcmp(sd->str, TOKEN_STRING_MULTI) != 0)) {
str = sd->str;
do {
token_len = get_token_len(str);
@@ -148,7 +149,21 @@ cmdline_parse_string(cmdline_parse_token_hdr_t *tk, const
char *buf, void *res,
if (!str)
[dpdk-dev] [PATCH] cryptodev: Remove EXPERIMENTAL label
2016-04-05 08:53, Fiona Trahe: > The cryptodev API was introduced in the DPDK 2.2 release. > Since then it has > - been reviewed and iterated for the DPDK 16.04 release > - had extensive use by the l2fwd-crypto app, > the ipsec-secgw example app, > the test app. > We believe it is now stable and the EXPERIMENTAL label should be removed. Are you sure sure? :) It means you will try hard to not change the API anymore or you'll need a deprecation notice strongly agreed (outside of your team). > * Defines RTE Crypto Device APIs for the provisioning of cipher and > * authentication operations. > * This empty line can be removed. > - * @b EXPERIMENTAL: this API may change without prior notice > - * > */
[dpdk-dev] [PATCH v2] doc: update nic overview
Thomas,
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Saturday, April 02, 2016 5:40 AM
> To: Chen, Jing D
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2] doc: update nic overview
>
> 2016-04-01 16:55, Chen Jing D:
> > Add feature support list for fm10k, fm10k-vec, fm10kvf and
> > fm10kvf-vec.
>
> Please help me to understand what is fm10kvf.
> I see only one fm10k driver:
> % git grep 'struct eth_driver' drivers/net/fm10k/
> drivers/net/fm10k/fm10k_ethdev.c:static struct eth_driver rte_pmd_fm10k
> = {
You can refer to below definition:
static const struct rte_pci_id pci_id_fm10k_map[] = {
#define RTE_PCI_DEV_ID_DECL_FM10K(vend, dev) { RTE_PCI_DEVICE(vend, dev) },
#define RTE_PCI_DEV_ID_DECL_FM10KVF(vend, dev) { RTE_PCI_DEVICE(vend, dev) },
#include "rte_pci_dev_ids.h"
{ .vendor_id = 0, /* sentinel */ },
};
As you can see that fm10k driver will manage 2 different types of devices, PF
and VF.
We can say that there are 2 drivers under fm10k directory. The aspects that not
applicable
to PF/VF will use condition check to control execution path. This makes driver
can work with
PF and VF devices and reduce redundant code.
[dpdk-dev] [PATCH] doc: announce ABI changes for user-owned mempool caches
Deprecation notice for 16.04 for changes targeting release 16.07. The changes affect struct rte_mempool, rte_mempool_cache and the mempool API. Signed-off-by: Lazaros Koromilas --- doc/guides/rel_notes/deprecation.rst | 7 +++ 1 file changed, 7 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index ad31355..6ccabcb 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -40,3 +40,10 @@ Deprecation Notices The existing API will be backward compatible, but there will be new API functions added to facilitate the creation of mempools using an external handler. The 16.07 release will contain these changes. + +* ABI change for rte_mempool struct to move the cache-related fields + to the more appropriate rte_mempool_cache struct. The mempool API is + also changed to enable external cache management that is not tied to EAL + threads. Some mempool get and put calls are removed in favor of a more + compact API. The ones that remain are backwards compatible and use the + per-lcore default cache if available. This change targets release 16.07. -- 1.9.1
[dpdk-dev] [PATCH v2 1/2] mempool: allow for user-owned mempool caches
Hi all,
I forgot to mention that this series applies on top of:
http://www.dpdk.org/dev/patchwork/patch/10492/
Thanks,
Lazaros.
On Mon, Apr 4, 2016 at 6:43 PM, Lazaros Koromilas
wrote:
> The mempool cache is only available to EAL threads as a per-lcore
> resource. Change this so that the user can create and provide their own
> cache on mempool get and put operations. This works with non-EAL threads
> too. This commit introduces the new API calls:
>
> rte_mempool_cache_create(size, socket_id)
> rte_mempool_cache_flush(cache, mp)
> rte_mempool_cache_free(cache)
> rte_mempool_default_cache(mp, lcore_id)
> rte_mempool_generic_put(mp, obj_table, n, cache, is_mp)
> rte_mempool_generic_get(mp, obj_table, n, cache, is_mc)
>
> Removes the API calls:
>
> rte_mempool_sp_put_bulk(mp, obj_table, n)
> rte_mempool_sc_get_bulk(mp, obj_table, n)
> rte_mempool_sp_put(mp, obj)
> rte_mempool_sc_get(mp, obj)
>
> And the remaining API calls use the per-lcore default local cache:
>
> rte_mempool_put_bulk(mp, obj_table, n)
> rte_mempool_get_bulk(mp, obj_table, n)
> rte_mempool_put(mp, obj)
> rte_mempool_get(mp, obj)
>
> Signed-off-by: Lazaros Koromilas
> ---
> app/test/test_mempool.c| 58 +--
> app/test/test_mempool_perf.c | 46 +-
> lib/librte_eal/common/eal_common_log.c | 8 +-
> lib/librte_mempool/rte_mempool.c | 76 -
> lib/librte_mempool/rte_mempool.h | 291
> +
> 5 files changed, 275 insertions(+), 204 deletions(-)
>
> diff --git a/app/test/test_mempool.c b/app/test/test_mempool.c
> index 10e1fa4..2dc0cf2 100644
> --- a/app/test/test_mempool.c
> +++ b/app/test/test_mempool.c
> @@ -79,6 +79,7 @@
>
> static struct rte_mempool *mp;
> static struct rte_mempool *mp_cache, *mp_nocache;
> +static int use_external_cache;
>
> static rte_atomic32_t synchro;
>
> @@ -107,19 +108,33 @@ test_mempool_basic(void)
> char *obj_data;
> int ret = 0;
> unsigned i, j;
> + struct rte_mempool_cache *cache;
> +
> + if (use_external_cache)
> + /* Create a user-owned mempool cache. */
> + cache = rte_mempool_cache_create(RTE_MEMPOOL_CACHE_MAX_SIZE,
> +SOCKET_ID_ANY);
> + else
> + cache = rte_mempool_default_cache(mp, rte_lcore_id());
>
> /* dump the mempool status */
> rte_mempool_dump(stdout, mp);
>
> printf("get an object\n");
> - if (rte_mempool_get(mp, &obj) < 0)
> + if (rte_mempool_generic_get(mp, &obj, 1, cache, 1) < 0)
> return -1;
> rte_mempool_dump(stdout, mp);
>
> /* tests that improve coverage */
> printf("get object count\n");
> - if (rte_mempool_count(mp) != MEMPOOL_SIZE - 1)
> - return -1;
> + if (use_external_cache) {
> + /* We have to count the extra caches, one in this case. */
> + if (rte_mempool_count(mp) + cache->len != MEMPOOL_SIZE - 1)
> + return -1;
> + } else {
> + if (rte_mempool_count(mp) != MEMPOOL_SIZE - 1)
> + return -1;
> + }
>
> printf("get private data\n");
> if (rte_mempool_get_priv(mp) != (char *)mp +
> @@ -134,21 +149,21 @@ test_mempool_basic(void)
> return -1;
>
> printf("put the object back\n");
> - rte_mempool_put(mp, obj);
> + rte_mempool_generic_put(mp, &obj, 1, cache, 1);
> rte_mempool_dump(stdout, mp);
>
> printf("get 2 objects\n");
> - if (rte_mempool_get(mp, &obj) < 0)
> + if (rte_mempool_generic_get(mp, &obj, 1, cache, 1) < 0)
> return -1;
> - if (rte_mempool_get(mp, &obj2) < 0) {
> - rte_mempool_put(mp, obj);
> + if (rte_mempool_generic_get(mp, &obj2, 1, cache, 1) < 0) {
> + rte_mempool_generic_put(mp, &obj, 1, cache, 1);
> return -1;
> }
> rte_mempool_dump(stdout, mp);
>
> printf("put the objects back\n");
> - rte_mempool_put(mp, obj);
> - rte_mempool_put(mp, obj2);
> + rte_mempool_generic_put(mp, &obj, 1, cache, 1);
> + rte_mempool_generic_put(mp, &obj2, 1, cache, 1);
> rte_mempool_dump(stdout, mp);
>
> /*
> @@ -161,7 +176,7 @@ test_mempool_basic(void)
> }
>
> for (i=0; i - if (rte_mempool_get(mp, &objtable[i]) < 0)
> + if (rte_mempool_generic_get(mp, &objtable[i], 1, cache, 1) <
> 0)
> break;
> }
>
> @@ -183,13 +198,18 @@ test_mempool_basic(void)
> ret = -1;
> }
>
> - rte_mempool_put(mp, objtable[i]);
> + rte_mempool_generic_put(mp, &objtable[i], 1, cache, 1);
> }
>
> free(objtable);
> if (ret == -1)
> printf("objects w
[dpdk-dev] [PATCH] doc: mempool ABI deprecation notice for 16.07
On 4/4/2016 3:38 PM, Thomas Monjalon wrote: > 2016-03-17 10:05, Olivier Matz: >> Add a deprecation notice for coming changes in mempool for 16.07. > [...] >> +* librte_mempool: new fixes and features will be added in 16.07: >> + allocation of large mempool in several virtual memory chunks, new API >> + to populate a mempool, new API to free a mempool, allocation in >> + anonymous mapping, drop of specific dom0 code. These changes will >> + induce a modification of the rte_mempool structure, plus a >> + modification of the API of rte_mempool_obj_iter(), implying a breakage >> + of the ABI. > Acked-by: Thomas Monjalon > > Other people involved in the discussion wanting to bring their support? Acked-by: David Hunt Regards, David.
[dpdk-dev] [PATCH] cryptodev: Remove EXPERIMENTAL label
> -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Tuesday, April 05, 2016 9:48 AM > To: Trahe, Fiona > Cc: dev at dpdk.org; Doherty, Declan > Subject: Re: [dpdk-dev] [PATCH] cryptodev: Remove EXPERIMENTAL label > > 2016-04-05 08:53, Fiona Trahe: > > The cryptodev API was introduced in the DPDK 2.2 release. > > Since then it has > > - been reviewed and iterated for the DPDK 16.04 release > > - had extensive use by the l2fwd-crypto app, > > the ipsec-secgw example app, > > the test app. > > We believe it is now stable and the EXPERIMENTAL label should be removed. > > Are you sure sure? :) > It means you will try hard to not change the API anymore or you'll need a > deprecation notice strongly agreed (outside of your team). We're sure sure :) > > > * Defines RTE Crypto Device APIs for the provisioning of cipher and > > * authentication operations. > > * > > This empty line can be removed. > > > - * @b EXPERIMENTAL: this API may change without prior notice > > - * > > */ A v2 without the empty line will follow shortly.
[dpdk-dev] [PATCH] autotests: fix eal flags test
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Olivier Matz
> Sent: Monday, April 04, 2016 5:20 PM
> To: dev at dpdk.org
> Cc: chaozhu at linux.vnet.ibm.com
> Subject: [dpdk-dev] [PATCH] autotests: fix eal flags test
>
> Since commit a88ba49e51, values larger than 4 are allowed,
> the autotests need to be updated accordingly.
>
> Fixes: a88ba49e51 ("config: fix CPU and memory parameters on IBM
> POWER8")
> Signed-off-by: Olivier Matz
Acked-by: Pablo de Lara
[dpdk-dev] [PATCH] cryptodev: Remove EXPERIMENTAL label
2016-04-05 09:48, Trahe, Fiona: > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > 2016-04-05 08:53, Fiona Trahe: > > > The cryptodev API was introduced in the DPDK 2.2 release. > > > Since then it has > > > - been reviewed and iterated for the DPDK 16.04 release > > > - had extensive use by the l2fwd-crypto app, > > > the ipsec-secgw example app, > > > the test app. > > > We believe it is now stable and the EXPERIMENTAL label should be removed. > > > > Are you sure sure? :) > > It means you will try hard to not change the API anymore or you'll need a > > deprecation notice strongly agreed (outside of your team). > > We're sure sure :) I think we could change the namespace before making this API stable. What about using a dpdk_ prefix instead of rte_ ? (and some macros have CRYPTODEV or CDEV prefixes)
[dpdk-dev] [PATCH] autotests: increase memory for group_2
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Olivier Matz
> Sent: Tuesday, April 05, 2016 8:37 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] autotests: increase memory for group_2
>
> The hash test (located in group_2) may require more than 64MB of memory,
> especially if the memory is physically fragmented, making the test to
> fail. So increase the memory to 128MB to avoid this issue.
>
> Signed-off-by: Olivier Matz
> ---
> app/test/autotest_data.py | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/app/test/autotest_data.py b/app/test/autotest_data.py
> index 6f34d6b..dde4511 100644
> --- a/app/test/autotest_data.py
> +++ b/app/test/autotest_data.py
> @@ -109,7 +109,7 @@ parallel_test_group_list = [
> },
> {
> "Prefix": "group_2",
> - "Memory" : "64",
> + "Memory" : "128",
> "Tests" :
> [
> {
> --
> 2.1.4
Acked-by: Pablo de Lara
[dpdk-dev] [PATCH v2] [PATCH] doc: update supported features of virtio
Update the overview.rst for virtio. Note: virtio is a para-virtualization device, which indicates that its features depend on not only front end but also back end. Here by X, we just mean the feature is supported in front end. Signed-off-by: Jianfeng Tan --- v2: - unicast MAC filter (yes) - multicast MAC filter (yes) - ethertype filter (no) - Power8 (no) - TILE-Gx (no) doc/guides/nics/overview.rst | 38 +++--- 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/doc/guides/nics/overview.rst b/doc/guides/nics/overview.rst index ec1af46..358a551 100644 --- a/doc/guides/nics/overview.rst +++ b/doc/guides/nics/overview.rst @@ -87,27 +87,27 @@ Most of these differences are summarized below. c c c c c c = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = speed capabilities - link status X X X X X X X + link status X X X X X X X X X link status eventX X X X X queue status event X Rx interrupt X X X X - queue start/stop X X X X X X X X X + queue start/stop X X X X X X X X X X X MTU update X X X X jumbo frame X X X X X X X X - scattered Rx X X X X X X X X X + scattered Rx X X X X X X X X X X LRO TSO X X X X X X - promiscuous mode X X X X X X X X - allmulticast modeX X X X X X X X - unicast MAC filter X X X X - multicast MAC filter X X X X + promiscuous mode X X X X X X X X X X + allmulticast modeX X X X X X X X X X + unicast MAC filter X X X X X X + multicast MAC filter X X X X X X RSS hash X X X X X X X X RSS key update X X X X X X RSS reta update X X X X X X VMDq X X SR-IOV X X X X X DCB X X - VLAN filter X X X X X X + VLAN filter X X X X X X X X ethertype filter X X n-tuple filter SYN filter @@ -127,23 +127,23 @@ Most of these differences are summarized below. inner L4 checksumX X X X packet type parsing X X X X X timesync X X - basic stats X X X X X X X X X X - extended stats X X X X X - stats per queue X X X X + basic stats X X X X X X X X X X X X + extended stats X X X X X X X + stats per queue X X X X X X EEPROM dump registers dump multiprocess aware X X X X X X - BSD nic_uio X X X X X - Linux UIOX X X X X X - Linux VFIO X X X X X + BSD nic_uio X X X X X X X + Linux UIOX X X X X X X X + Linux VFIO X X X X X X X other kdrv X - ARMv7 - ARMv8 + ARMv7 X X + ARMv8 X X Power8 X X TILE-Gx - x86-32 X X X X X X X X X - x86-64 X X X X X X X X X X - usage docX X X X + x86-32 X X X X X X
[dpdk-dev] [PATCH] ixgbe: fix occasional timeouts when starting VF
Increase the polling wait time from 10 milleseconds to 15.
Signed-off-by: Bernard Iremonger
---
drivers/net/ixgbe/ixgbe_rxtx.c | 6 +++---
drivers/net/ixgbe/ixgbe_rxtx.h | 3 ++-
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
index b018ba7..4ad947f 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx.c
+++ b/drivers/net/ixgbe/ixgbe_rxtx.c
@@ -1,7 +1,7 @@
/*-
* BSD LICENSE
*
- * Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
+ * Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
* Copyright 2014 6WIND S.A.
* All rights reserved.
*
@@ -4961,7 +4961,7 @@ ixgbevf_dev_rxtx_start(struct rte_eth_dev *dev)
txdctl |= IXGBE_TXDCTL_ENABLE;
IXGBE_WRITE_REG(hw, IXGBE_VFTXDCTL(i), txdctl);
- poll_ms = 10;
+ poll_ms = RTE_IXGBE_REGISTER_POLL_WAIT_15_MS;
/* Wait until TX Enable ready */
do {
rte_delay_ms(1);
@@ -4979,7 +4979,7 @@ ixgbevf_dev_rxtx_start(struct rte_eth_dev *dev)
IXGBE_WRITE_REG(hw, IXGBE_VFRXDCTL(i), rxdctl);
/* Wait until RX Enable ready */
- poll_ms = 10;
+ poll_ms = RTE_IXGBE_REGISTER_POLL_WAIT_15_MS;
do {
rte_delay_ms(1);
rxdctl = IXGBE_READ_REG(hw, IXGBE_VFRXDCTL(i));
diff --git a/drivers/net/ixgbe/ixgbe_rxtx.h b/drivers/net/ixgbe/ixgbe_rxtx.h
index f9e708f..8085cf4 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx.h
+++ b/drivers/net/ixgbe/ixgbe_rxtx.h
@@ -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
@@ -77,6 +77,7 @@
#endif
#define RTE_IXGBE_REGISTER_POLL_WAIT_10_MS 10
+#define RTE_IXGBE_REGISTER_POLL_WAIT_15_MS 15
#define RTE_IXGBE_WAIT_100_US 100
#define RTE_IXGBE_VMTXSW_REGISTER_COUNT 2
--
2.6.3
[dpdk-dev] [PATCH v2 4/4] autotest: fix func reentrancy
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Olivier Matz
> Sent: Tuesday, April 05, 2016 8:36 AM
> To: dev at dpdk.org
> Cc: Richardson, Bruce
> Subject: [dpdk-dev] [PATCH v2 4/4] autotest: fix func reentrancy
>
> The previous code in func_reentrancy autotest was doing in parallel
> something close to:
>
> name = "common_name";
> do several times {
> obj = allocate_an_object(name) // obj = ring, mempool, hash, lpm, ...
> if (obj == NULL && lookup(name) == NULL)
> return TEST_FAIL;
> }
>
> This code is not safe. For instance:
>
>mempool_create() is called on core 0, it creates a ring. At the same
>time on core 1, mempool_create() is called too and the creation of the
>ring fails (EEXIST). But the mempool lookup can fail on core 1 if
>the mempool is not added in the list by core 0.
>
> This commit fixes the func_reentrancy autotest that now works with all
> tested class of objects.
>
> Signed-off-by: Olivier Matz
Hi Olivier,
Could you include a "Fixes" line here?
Thanks,
Pablo
[dpdk-dev] [PATCH v2 3/4] hash: keep the list locked at creation
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Olivier Matz
> Sent: Tuesday, April 05, 2016 8:36 AM
> To: dev at dpdk.org
> Cc: Richardson, Bruce
> Subject: [dpdk-dev] [PATCH v2 3/4] hash: keep the list locked at creation
>
> To avoid a race condition while creating a new hash object, the
> list has to be locked before the lookup, and released only once the
> new object is added in the list.
>
> As the lock is held by the rte_ring_create(), move its creation at the
> beginning of the function and only take the lock after the ring is
> created to avoid a deadlock.
>
> Signed-off-by: Olivier Matz
> ---
> lib/librte_hash/rte_cuckoo_hash.c | 68 ++-
>
> 1 file changed, 38 insertions(+), 30 deletions(-)
>
> diff --git a/lib/librte_hash/rte_cuckoo_hash.c
> b/lib/librte_hash/rte_cuckoo_hash.c
> index ccec2db..63a74fd 100644
> --- a/lib/librte_hash/rte_cuckoo_hash.c
> +++ b/lib/librte_hash/rte_cuckoo_hash.c
> @@ -226,19 +226,46 @@ rte_hash_create(const struct rte_hash_parameters
> *params)
> if (params->extra_flag &
> RTE_HASH_EXTRA_FLAGS_TRANS_MEM_SUPPORT)
> hw_trans_mem_support = 1;
>
> + /* Store all keys and leave the first entry as a dummy entry for
> lookup_bulk */
> + if (hw_trans_mem_support)
> + /*
> + * Increase number of slots by total number of indices
> + * that can be stored in the lcore caches
> + * except for the first cache
> + */
> + num_key_slots = params->entries + (RTE_MAX_LCORE - 1) *
> + LCORE_CACHE_SIZE + 1;
> + else
> + num_key_slots = params->entries + 1;
> +
> + snprintf(ring_name, sizeof(ring_name), "HT_%s", params->name);
> + r = rte_ring_create(ring_name, rte_align32pow2(num_key_slots),
> + params->socket_id, 0);
> + if (r == NULL) {
> + RTE_LOG(ERR, HASH, "memory allocation failed\n");
> + goto err;
> + }
> +
> snprintf(hash_name, sizeof(hash_name), "HT_%s", params->name);
>
> - /* Guarantee there's no existing */
> - h = rte_hash_find_existing(params->name);
> - if (h != NULL) {
> + rte_rwlock_write_lock(RTE_EAL_TAILQ_RWLOCK);
> +
> + /* guarantee there's no existing: this is normally already checked
> + * by ring creation above */
> + TAILQ_FOREACH(te, hash_list, next) {
> + h = (struct rte_hash *) te->data;
> + if (strncmp(params->name, h->name, RTE_HASH_NAMESIZE)
> == 0)
> + break;
> + }
> + if (te != NULL) {
> rte_errno = EEXIST;
> - return NULL;
> + goto err_unlock;
> }
>
> te = rte_zmalloc("HASH_TAILQ_ENTRY", sizeof(*te), 0);
> if (te == NULL) {
> RTE_LOG(ERR, HASH, "tailq entry allocation failed\n");
> - goto err;
> + goto err_unlock;
> }
>
> h = (struct rte_hash *)rte_zmalloc_socket(hash_name, sizeof(struct
> rte_hash),
> @@ -246,7 +273,7 @@ rte_hash_create(const struct rte_hash_parameters
> *params)
>
> if (h == NULL) {
> RTE_LOG(ERR, HASH, "memory allocation failed\n");
> - goto err;
> + goto err_unlock;
> }
>
> const uint32_t num_buckets = rte_align32pow2(params->entries)
> @@ -258,23 +285,10 @@ rte_hash_create(const struct rte_hash_parameters
> *params)
>
> if (buckets == NULL) {
> RTE_LOG(ERR, HASH, "memory allocation failed\n");
> - goto err;
> + goto err_unlock;
> }
>
> const uint32_t key_entry_size = sizeof(struct rte_hash_key) +
> params->key_len;
> -
> - /* Store all keys and leave the first entry as a dummy entry for
> lookup_bulk */
> - if (hw_trans_mem_support)
> - /*
> - * Increase number of slots by total number of indices
> - * that can be stored in the lcore caches
> - * except for the first cache
> - */
> - num_key_slots = params->entries + (RTE_MAX_LCORE - 1) *
> - LCORE_CACHE_SIZE + 1;
> - else
> - num_key_slots = params->entries + 1;
> -
> const uint64_t key_tbl_size = (uint64_t) key_entry_size *
> num_key_slots;
>
> k = rte_zmalloc_socket(NULL, key_tbl_size,
> @@ -282,7 +296,7 @@ rte_hash_create(const struct rte_hash_parameters
> *params)
>
> if (k == NULL) {
> RTE_LOG(ERR, HASH, "memory allocation failed\n");
> - goto err;
> + goto err_unlock;
> }
>
> /*
> @@ -325,14 +339,6 @@ rte_hash_create(const struct rte_hash_parameters
> *params)
> h->rte_hash_cmp_eq = memcmp;
> #endif
>
> - snprintf(ring_name, sizeof(ring_name), "HT_%s", params->name);
> - r = rte_ring_create(ring_name, rte_align32pow2(num_key_slots),
> - para
[dpdk-dev] [PATCH] xstats: fix behavior when a null array is provided
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Olivier Matz
> Subject: [dpdk-dev] [PATCH] xstats: fix behavior when a null array is provided
>
> Coverity reports an issue in ethdev:
>
> *** CID 124562: Null pointer dereferences (FORWARD_NULL)
> /lib/librte_ether/rte_ethdev.c: 1518 in rte_eth_xstats_get()
> 1512
> 1513/* global stats */
> 1514for (i = 0; i < RTE_NB_STATS; i++) {
> 1515stats_ptr = RTE_PTR_ADD(ð_stats,
> 1516
> rte_stats_strings[i].offset);
> 1517val = *stats_ptr;
> >>> CID 124562: Null pointer dereferences (FORWARD_NULL)
> >>> Dereferencing null pointer "xstats".
> 1518 snprintf(xstats[count].name,
> sizeof(xstats[count].name),
> 1519"%s", rte_stats_strings[i].name);
> 1520 xstats[count++].value = val;
> 1521 }
> 1522
> 1523/* per-rxq stats */
>
> If a user calls rte_eth_xstats_get(portid, NULL, n) with n != 0,
> it may result in a crash. Although the API documentation says that
> n is the size of the table and xstats can be NULL if n == 0, we
> can add an additional check here to make Coverity happy.
>
> In that case, the return value is the same than when n == 0 is
> passed, it returns the number of statistics.
>
> Fixes: ce757f5c9a ("ethdev: new method to retrieve extended statistics")
> Signed-off-by: Olivier Matz
I'm unsure on how verbose commit messages are ideal,
but there's certainly enough description here :)
Acked-by: Harry van Haaren
[dpdk-dev] [PATCH v2 1/1] cmdline: add any multi string mode to token string
On 04/05/2016 10:47 AM, Piotr Azarewicz wrote: > While parsing token string there may be several modes: > - fixed single string > - multi-choice single string > - any single string > > This patch add one more mode - any multi string. > > Signed-off-by: Piotr Azarewicz Acked-by: Olivier Matz
[dpdk-dev] [PATCH v3 0/4] fix creation of duplicate lpm and hash
Seen while trying to fix the func_reentrancy autotest. The series addresses several issues: 1/ Hash and lpm return a pointer to an existing object if the user requests the creation with an already existing name. This look dangerous: when an object is returned, the user does not know if it should be freed or not. 2/ There is a race condition in cuckoo_hash as the lock is not held in rte_hash_create(). We could find some cases where NULL is returned when the object already exists (ex: when rte_ring_create() fails). 3/ There is a race condition func_reentrancy that can fail even if the tested API behaves correctly. RFC -> v1: - split the patch in 4 patches - on error, set rte_errno to EEXIST when relevant - fix locking in cuckoo_hash creation v1 -> v2: - fix compilation issue in cuckoo hash - update the hash test to conform to the new behavior - rework locking modification in cuckoo_hash - passed autotests: hash, lpm, lpm6, func_reentrancy v2 -> v3: - rebase against head - add "Fixes:" in commit messages - properly set lpm or hash pointers to NULL on error before returning Olivier Matz (4): lpm: allocation of an existing object should fail hash: allocation of an existing object should fail hash: keep the list locked at creation autotest: fix func reentrancy app/test/test_func_reentrancy.c | 31 +++-- app/test/test_hash.c | 65 +-- app/test/test_lpm6.c | 2 +- lib/librte_hash/rte_cuckoo_hash.c | 72 +++ lib/librte_hash/rte_fbk_hash.c| 5 ++- lib/librte_lpm/rte_lpm.c | 10 -- lib/librte_lpm/rte_lpm6.c | 5 ++- 7 files changed, 103 insertions(+), 87 deletions(-) -- 2.1.4
[dpdk-dev] [PATCH v3 2/4] hash: allocation of an existing object should fail
Change rte_hash*_create() functions to return NULL and set rte_errno to
EEXIST when the object name already exists. This is the behavior
described in the API documentation in the header file.
These functions were returning a pointer to the existing object in that
case, but it is a problem as the caller did not know if the object had
to be freed or not.
Doing this change also makes the hash API more consistent with the other
APIs (mempool, rings, ...).
Fixes: 4542f89397 ("hash: make tailq fully local")
Signed-off-by: Olivier Matz
---
app/test/test_hash.c | 65 ++-
lib/librte_hash/rte_cuckoo_hash.c | 6 ++--
lib/librte_hash/rte_fbk_hash.c| 5 ++-
3 files changed, 31 insertions(+), 45 deletions(-)
diff --git a/app/test/test_hash.c b/app/test/test_hash.c
index 2f3d884..adbdb4a 100644
--- a/app/test/test_hash.c
+++ b/app/test/test_hash.c
@@ -805,15 +805,11 @@ fbk_hash_unit_test(void)
RETURN_IF_ERROR_FBK(handle == NULL, "fbk hash creation should have
succeeded");
tmp = rte_fbk_hash_create(&invalid_params_same_name_2);
- RETURN_IF_ERROR_FBK(tmp == NULL, "fbk hash creation should have
succeeded");
- if (tmp != handle) {
- printf("ERROR line %d: hashes should have been the
same\n", __LINE__);
- rte_fbk_hash_free(handle);
- rte_fbk_hash_free(tmp);
- return -1;
- }
+ if (tmp != NULL)
+ rte_fbk_hash_free(tmp);
+ RETURN_IF_ERROR_FBK(tmp != NULL, "fbk hash creation should have
failed");
- /* we are not freeing tmp or handle here because we need a hash list
+ /* we are not freeing handle here because we need a hash list
* to be not empty for the next test */
/* create a hash in non-empty list - good for coverage */
@@ -988,7 +984,7 @@ static int test_fbk_hash_find_existing(void)
*/
static int test_hash_creation_with_bad_parameters(void)
{
- struct rte_hash *handle;
+ struct rte_hash *handle, *tmp;
struct rte_hash_parameters params;
handle = rte_hash_create(NULL);
@@ -1038,7 +1034,23 @@ static int test_hash_creation_with_bad_parameters(void)
return -1;
}
+ /* test with same name should fail */
+ memcpy(¶ms, &ut_params, sizeof(params));
+ params.name = "same_name";
+ handle = rte_hash_create(¶ms);
+ if (handle == NULL) {
+ printf("Cannot create first hash table with 'same_name'\n");
+ return -1;
+ }
+ tmp = rte_hash_create(¶ms);
+ if (tmp != NULL) {
+ printf("Creation of hash table with same name should fail\n");
+ rte_hash_free(handle);
+ rte_hash_free(tmp);
+ return -1;
+ }
rte_hash_free(handle);
+
printf("# Test successful. No more errors expected\n");
return 0;
@@ -1051,12 +1063,12 @@ static int test_hash_creation_with_bad_parameters(void)
static int
test_hash_creation_with_good_parameters(void)
{
- struct rte_hash *handle, *tmp;
+ struct rte_hash *handle;
struct rte_hash_parameters params;
/* create with null hash function - should choose DEFAULT_HASH_FUNC */
memcpy(¶ms, &ut_params, sizeof(params));
- params.name = "same_name";
+ params.name = "name";
params.hash_func = NULL;
handle = rte_hash_create(¶ms);
if (handle == NULL) {
@@ -1064,37 +1076,6 @@ test_hash_creation_with_good_parameters(void)
return -1;
}
- /* this test is trying to create a hash with the same name as previous
one.
-* this should return a pointer to the hash we previously created.
-* the previous hash isn't freed exactly for the purpose of it being in
-* the hash list.
-*/
- memcpy(¶ms, &ut_params, sizeof(params));
- params.name = "same_name";
- tmp = rte_hash_create(¶ms);
-
- /* check if the returned handle is actually equal to the previous hash
*/
- if (handle != tmp) {
- rte_hash_free(handle);
- rte_hash_free(tmp);
- printf("Creating hash with existing name was successful\n");
- return -1;
- }
-
- /* try creating hash when there already are hashes in the list.
-* the previous hash is not freed to have a non-empty hash list.
-* the other hash that's in the list is still pointed to by "handle"
var.
-*/
- memcpy(¶ms, &ut_params, sizeof(params));
- params.name = "different_name";
- tmp = rte_hash_create(¶ms);
- if (tmp == NULL) {
- rte_hash_free(handle);
- printf("Creating hash with valid parameters failed\n");
- return -1;
- }
-
- rte_hash_free(tmp);
rte_hash_free(handle);
return 0;
diff --git a/lib/librte_hash/rte_cuckoo_hash.c
b/lib/li
[dpdk-dev] [PATCH v3 3/4] hash: keep the list locked at creation
To avoid a race condition while creating a new hash object, the
list has to be locked before the lookup, and released only once the
new object is added in the list.
As the lock is held by the rte_ring_create(), move its creation at the
beginning of the function and only take the lock after the ring is
created to avoid a deadlock.
Fixes: 48a3991196 ("hash: replace with cuckoo hash implementation")
Signed-off-by: Olivier Matz
---
lib/librte_hash/rte_cuckoo_hash.c | 70 ++-
1 file changed, 40 insertions(+), 30 deletions(-)
diff --git a/lib/librte_hash/rte_cuckoo_hash.c
b/lib/librte_hash/rte_cuckoo_hash.c
index b00cc12..7b7d1f8 100644
--- a/lib/librte_hash/rte_cuckoo_hash.c
+++ b/lib/librte_hash/rte_cuckoo_hash.c
@@ -295,19 +295,48 @@ rte_hash_create(const struct rte_hash_parameters *params)
if (params->extra_flag & RTE_HASH_EXTRA_FLAGS_TRANS_MEM_SUPPORT)
hw_trans_mem_support = 1;
+ /* Store all keys and leave the first entry as a dummy entry for
lookup_bulk */
+ if (hw_trans_mem_support)
+ /*
+* Increase number of slots by total number of indices
+* that can be stored in the lcore caches
+* except for the first cache
+*/
+ num_key_slots = params->entries + (RTE_MAX_LCORE - 1) *
+ LCORE_CACHE_SIZE + 1;
+ else
+ num_key_slots = params->entries + 1;
+
+ snprintf(ring_name, sizeof(ring_name), "HT_%s", params->name);
+ r = rte_ring_create(ring_name, rte_align32pow2(num_key_slots),
+ params->socket_id, 0);
+ if (r == NULL) {
+ RTE_LOG(ERR, HASH, "memory allocation failed\n");
+ goto err;
+ }
+
snprintf(hash_name, sizeof(hash_name), "HT_%s", params->name);
- /* Guarantee there's no existing */
- h = rte_hash_find_existing(params->name);
- if (h != NULL) {
+ rte_rwlock_write_lock(RTE_EAL_TAILQ_RWLOCK);
+
+ /* guarantee there's no existing: this is normally already checked
+* by ring creation above */
+ TAILQ_FOREACH(te, hash_list, next) {
+ h = (struct rte_hash *) te->data;
+ if (strncmp(params->name, h->name, RTE_HASH_NAMESIZE) == 0)
+ break;
+ }
+ h = NULL;
+ if (te != NULL) {
rte_errno = EEXIST;
- return NULL;
+ te = NULL;
+ goto err_unlock;
}
te = rte_zmalloc("HASH_TAILQ_ENTRY", sizeof(*te), 0);
if (te == NULL) {
RTE_LOG(ERR, HASH, "tailq entry allocation failed\n");
- goto err;
+ goto err_unlock;
}
h = (struct rte_hash *)rte_zmalloc_socket(hash_name, sizeof(struct
rte_hash),
@@ -315,7 +344,7 @@ rte_hash_create(const struct rte_hash_parameters *params)
if (h == NULL) {
RTE_LOG(ERR, HASH, "memory allocation failed\n");
- goto err;
+ goto err_unlock;
}
const uint32_t num_buckets = rte_align32pow2(params->entries)
@@ -327,23 +356,10 @@ rte_hash_create(const struct rte_hash_parameters *params)
if (buckets == NULL) {
RTE_LOG(ERR, HASH, "memory allocation failed\n");
- goto err;
+ goto err_unlock;
}
const uint32_t key_entry_size = sizeof(struct rte_hash_key) +
params->key_len;
-
- /* Store all keys and leave the first entry as a dummy entry for
lookup_bulk */
- if (hw_trans_mem_support)
- /*
-* Increase number of slots by total number of indices
-* that can be stored in the lcore caches
-* except for the first cache
-*/
- num_key_slots = params->entries + (RTE_MAX_LCORE - 1) *
- LCORE_CACHE_SIZE + 1;
- else
- num_key_slots = params->entries + 1;
-
const uint64_t key_tbl_size = (uint64_t) key_entry_size * num_key_slots;
k = rte_zmalloc_socket(NULL, key_tbl_size,
@@ -351,7 +367,7 @@ rte_hash_create(const struct rte_hash_parameters *params)
if (k == NULL) {
RTE_LOG(ERR, HASH, "memory allocation failed\n");
- goto err;
+ goto err_unlock;
}
/*
@@ -393,14 +409,6 @@ rte_hash_create(const struct rte_hash_parameters *params)
h->cmp_jump_table_idx = KEY_OTHER_BYTES;
#endif
- snprintf(ring_name, sizeof(ring_name), "HT_%s", params->name);
- r = rte_ring_create(ring_name, rte_align32pow2(num_key_slots),
- params->socket_id, 0);
- if (r == NULL) {
- RTE_LOG(ERR, HASH, "memory allocation failed\n");
- goto err;
- }
-
if (hw_trans_mem_support) {
h->local_free_slots = rte_zmalloc_socket(NULL,
[dpdk-dev] [PATCH v3 1/4] lpm: allocation of an existing object should fail
Change rte_lpm*_create() functions to return NULL and set rte_errno to
EEXIST when the object name already exists. This is the behavior
described in the API documentation in the header file.
These functions were returning a pointer to the existing object in that
case, but it is a problem as the caller did not know if the object had
to be freed or not.
Doing this change also makes the lpm API more consistent with the other
APIs (mempool, rings, ...).
Fixes: 899d8bc9b3 ("lpm: make tailq fully local")
Signed-off-by: Olivier Matz
---
app/test/test_lpm6.c | 2 +-
lib/librte_lpm/rte_lpm.c | 10 --
lib/librte_lpm/rte_lpm6.c | 5 -
3 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/app/test/test_lpm6.c b/app/test/test_lpm6.c
index 1f88d7a..b464342 100644
--- a/app/test/test_lpm6.c
+++ b/app/test/test_lpm6.c
@@ -222,7 +222,7 @@ test1(void)
/* rte_lpm6_create: lpm name == LPM2 */
lpm3 = rte_lpm6_create("LPM1", SOCKET_ID_ANY, &config);
- TEST_LPM_ASSERT(lpm3 == lpm1);
+ TEST_LPM_ASSERT(lpm3 == NULL);
rte_lpm6_free(lpm1);
rte_lpm6_free(lpm2);
diff --git a/lib/librte_lpm/rte_lpm.c b/lib/librte_lpm/rte_lpm.c
index bd3563f..8bdf606 100644
--- a/lib/librte_lpm/rte_lpm.c
+++ b/lib/librte_lpm/rte_lpm.c
@@ -209,8 +209,11 @@ rte_lpm_create_v20(const char *name, int socket_id, int
max_rules,
if (strncmp(name, lpm->name, RTE_LPM_NAMESIZE) == 0)
break;
}
- if (te != NULL)
+ lpm = NULL;
+ if (te != NULL) {
+ rte_errno = EEXIST;
goto exit;
+ }
/* allocate tailq entry */
te = rte_zmalloc("LPM_TAILQ_ENTRY", sizeof(*te), 0);
@@ -280,8 +283,11 @@ rte_lpm_create_v1604(const char *name, int socket_id,
if (strncmp(name, lpm->name, RTE_LPM_NAMESIZE) == 0)
break;
}
- if (te != NULL)
+ lpm = NULL;
+ if (te != NULL) {
+ rte_errno = EEXIST;
goto exit;
+ }
/* allocate tailq entry */
te = rte_zmalloc("LPM_TAILQ_ENTRY", sizeof(*te), 0);
diff --git a/lib/librte_lpm/rte_lpm6.c b/lib/librte_lpm/rte_lpm6.c
index 4c44cd7..ba4353c 100644
--- a/lib/librte_lpm/rte_lpm6.c
+++ b/lib/librte_lpm/rte_lpm6.c
@@ -182,8 +182,11 @@ rte_lpm6_create(const char *name, int socket_id,
if (strncmp(name, lpm->name, RTE_LPM6_NAMESIZE) == 0)
break;
}
- if (te != NULL)
+ lpm = NULL;
+ if (te != NULL) {
+ rte_errno = EEXIST;
goto exit;
+ }
/* allocate tailq entry */
te = rte_zmalloc("LPM6_TAILQ_ENTRY", sizeof(*te), 0);
--
2.1.4
[dpdk-dev] [PATCH v3 4/4] autotest: fix func reentrancy
The previous code in func_reentrancy autotest was doing in parallel
something close to:
name = "common_name";
do several times {
obj = allocate_an_object(name) // obj = ring, mempool, hash, lpm, ...
if (obj == NULL && lookup(name) == NULL)
return TEST_FAIL;
}
This code is not safe. For instance:
mempool_create() is called on core 0, it creates a ring. At the same
time on core 1, mempool_create() is called too and the creation of the
ring fails (EEXIST). But the mempool lookup can fail on core 1 if
the mempool is not added in the list by core 0.
This commit fixes the func_reentrancy autotest that now works with all
tested class of objects.
Fixes: 104a92bd02 ("app: add reentrancy tests")
Signed-off-by: Olivier Matz
---
app/test/test_func_reentrancy.c | 31 +--
1 file changed, 21 insertions(+), 10 deletions(-)
diff --git a/app/test/test_func_reentrancy.c b/app/test/test_func_reentrancy.c
index 5d09296..300a3bc 100644
--- a/app/test/test_func_reentrancy.c
+++ b/app/test/test_func_reentrancy.c
@@ -83,6 +83,7 @@ typedef void (*case_clean_t)(unsigned lcore_id);
#define MAX_LCORES RTE_MAX_MEMZONE / (MAX_ITER_TIMES * 4U)
+static rte_atomic32_t obj_count = RTE_ATOMIC32_INIT(0);
static rte_atomic32_t synchro = RTE_ATOMIC32_INIT(0);
#define WAIT_SYNCHRO_FOR_SLAVES() do{ \
@@ -100,6 +101,7 @@ test_eal_init_once(__attribute__((unused)) void *arg)
WAIT_SYNCHRO_FOR_SLAVES();
+ rte_atomic32_set(&obj_count, 1); /* silent the check in the caller */
if (rte_eal_init(0, NULL) != -1)
return -1;
@@ -122,8 +124,8 @@ ring_create_lookup(__attribute__((unused)) void *arg)
/* create the same ring simultaneously on all threads */
for (i = 0; i < MAX_ITER_TIMES; i++) {
rp = rte_ring_create("fr_test_once", 4096, SOCKET_ID_ANY, 0);
- if ((NULL == rp) && (rte_ring_lookup("fr_test_once") == NULL))
- return -1;
+ if (rp != NULL)
+ rte_atomic32_inc(&obj_count);
}
/* create/lookup new ring several times */
@@ -172,8 +174,8 @@ mempool_create_lookup(__attribute__((unused)) void *arg)
NULL, NULL,
my_obj_init, NULL,
SOCKET_ID_ANY, 0);
- if ((NULL == mp) && (rte_mempool_lookup("fr_test_once") ==
NULL))
- return -1;
+ if (mp != NULL)
+ rte_atomic32_inc(&obj_count);
}
/* create/lookup new ring several times */
@@ -238,8 +240,8 @@ hash_create_free(__attribute__((unused)) void *arg)
hash_params.name = "fr_test_once";
for (i = 0; i < MAX_ITER_TIMES; i++) {
handle = rte_hash_create(&hash_params);
- if ((NULL == handle) && (rte_hash_find_existing("fr_test_once")
== NULL))
- return -1;
+ if (handle != NULL)
+ rte_atomic32_inc(&obj_count);
}
/* create mutiple times simultaneously */
@@ -306,8 +308,8 @@ fbk_create_free(__attribute__((unused)) void *arg)
fbk_params.name = "fr_test_once";
for (i = 0; i < MAX_ITER_TIMES; i++) {
handle = rte_fbk_hash_create(&fbk_params);
- if ((NULL == handle) &&
(rte_fbk_hash_find_existing("fr_test_once") == NULL))
- return -1;
+ if (handle != NULL)
+ rte_atomic32_inc(&obj_count);
}
/* create mutiple fbk tables simultaneously */
@@ -372,8 +374,8 @@ lpm_create_free(__attribute__((unused)) void *arg)
/* create the same lpm simultaneously on all threads */
for (i = 0; i < MAX_ITER_TIMES; i++) {
lpm = rte_lpm_create("fr_test_once", SOCKET_ID_ANY, &config);
- if ((NULL == lpm) && (rte_lpm_find_existing("fr_test_once") ==
NULL))
- return -1;
+ if (lpm != NULL)
+ rte_atomic32_inc(&obj_count);
}
/* create mutiple fbk tables simultaneously */
@@ -432,10 +434,12 @@ launch_test(struct test_case *pt_case)
unsigned lcore_id;
unsigned cores_save = rte_lcore_count();
unsigned cores = RTE_MIN(cores_save, MAX_LCORES);
+ unsigned count;
if (pt_case->func == NULL)
return -1;
+ rte_atomic32_set(&obj_count, 0);
rte_atomic32_set(&synchro, 0);
RTE_LCORE_FOREACH_SLAVE(lcore_id) {
@@ -462,6 +466,13 @@ launch_test(struct test_case *pt_case)
pt_case->clean(lcore_id);
}
+ count = rte_atomic32_read(&obj_count);
+ if (count != 1) {
+ printf("%s: common object allocated %d times (should be 1)\n",
+ pt_case->name, count);
+ ret = -1;
+ }
+
return ret;
}
--
2
[dpdk-dev] [PATCH] examples/l3fwd: fix segfault with gcc 5.x
> -Original Message-
> From: Ananyev, Konstantin
> Sent: Monday, April 4, 2016 21:05
> To: Kulasek, TomaszX
> Cc: dev at dpdk.org
> Subject: RE: [dpdk-dev] [PATCH] examples/l3fwd: fix segfault with gcc 5.x
>
>
>
> > -Original Message-
> > From: Kulasek, TomaszX
> > Sent: Monday, April 04, 2016 5:20 PM
> > To: Ananyev, Konstantin
> > Cc: dev at dpdk.org
> > Subject: RE: [dpdk-dev] [PATCH] examples/l3fwd: fix segfault with gcc
> > 5.x
> >
> > Hi Konstantin,
> >
> > > -Original Message-
> > > From: Ananyev, Konstantin
> > > Sent: Monday, April 4, 2016 17:35
> > > To: Kulasek, TomaszX
> > > Cc: dev at dpdk.org
> > > Subject: RE: [dpdk-dev] [PATCH] examples/l3fwd: fix segfault with
> > > gcc 5.x
> > >
> > > Hi Tomasz,
> > >
> > > > -Original Message-
> > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Tomasz
> > > > Kulasek
> > > > Sent: Monday, April 04, 2016 3:45 PM
> > > > To: dev at dpdk.org
> > > > Subject: [dpdk-dev] [PATCH] examples/l3fwd: fix segfault with gcc
> > > > 5.x
> > > >
> > > > It seems that with gcc >5.x and -O2/-O3 optimization breaks packet
> > > > grouping algorithm.
> > > >
> > > > When last packet pointer "lp" and "pnum->u64" buffer points the
> > > > same memory buffer, high optimization can cause unpredictable
> > > > results. It seems that assignment of precalculated group sizes may
> > > > interfere with initialization of new group size when lp points
> > > > value inside current group and didn't should be changed.
> > > >
> > > > With gcc >5.x and optimization we cannot be sure which assignment
> > > > will be done first, so the group size can be counted incorrectly.
> > > >
> > > > This patch eliminates intersection of assignment of initial group
> > > > size (lp[0] = 1) and precalculated group sizes when gptbl[v].idx <
> 4.
> > > >
> > > > Fixes: 94c54b4158d5 ("examples/l3fwd: rework exact-match")
> > > >
> > > > Signed-off-by: Tomasz Kulasek
> > > > ---
> > > > examples/l3fwd/l3fwd_sse.h |4 ++--
> > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/examples/l3fwd/l3fwd_sse.h
> > > > b/examples/l3fwd/l3fwd_sse.h index f9cf50a..1afa1f0 100644
> > > > --- a/examples/l3fwd/l3fwd_sse.h
> > > > +++ b/examples/l3fwd/l3fwd_sse.h
> > > > @@ -283,9 +283,9 @@ port_groupx4(uint16_t pn[FWDSTEP + 1],
> > > > uint16_t *lp, __m128i dp1, __m128i dp2)
> > > >
> > > > /* if dest port value has changed. */
> > > > if (v != GRPMSK) {
> > > > - lp = pnum->u16 + gptbl[v].idx;
> > > > - lp[0] = 1;
> > > > pnum->u64 = gptbl[v].pnum;
> > > > + pnum->u16[FWDSTEP] = 1;
> > >
> > > Hmm, but FWDSTEP and gptbl[v].idx are not always equal.
> > > Actually could you explain a bit more - what exactly is reordered by
> > > gcc 5.x, and how to reproduce it?
> > > i.e what sequence of input packets will trigger an error?
> > > Konstantin
> > >
> > > > + lp = pnum->u16 + gptbl[v].idx;
> > > > }
> > > >
> > > > return lp;
> > > > --
> > > > 1.7.9.5
> >
> >
> > Eg. For this case, when group is changed:
> >
> > {
> > /* 0xb: a == b, b == c, c != d, d == e */
> > .pnum = UINT64_C(0x0002000100020003),
> > .idx = 3,
> > .lpv = 2,
> > },
> >
> > We expect:
> >
> > pnum->u16 = { 3, 2, 1, 2, x }
> > lp = pnum->u16 + 3;
> > // should be lp[0] == 2
> >
> > but for gcc 5.2
> >
> > lp = pnum->u16 + gptbl[v].idx;
> > lp[0] = 1;
> > pnum->u64 = gptbl[v].pnum;
> >
> > gives, for some reason lp[0] == 1, even if pnum->u16[3] == 2.
> >
> > It causes, that group is shorter and fails trying to send next group
> with messy length.
> >
> > We should set lp[0] = 1 only when needed (gptbl[v].idx == 4), so this
> > is why I set pnum->u16[4] = 1. I set it up always to prevent condition.
> For idx < 4 we don't need to set lp[0].
> >
> > The problem is that both pointers operates on the same memory buffer
> and, it seems like gcc optimization will produce (it is wrong):
> >
> > lp = pnum->u16 + gptbl[v].idx;
> > pnum->u64 = gptbl[v].pnum;
> > lp[0] = 1;
> >
> > except:
> >
> > lp = pnum->u16 + gptbl[v].idx;
> > lp[0] = 1;
> > pnum->u64 = gptbl[v].pnum;
> >
> > This issue is with gcc 5.x and application seems to fail for the
> patterns where gptbl[v].idx < 4.
>
>
> Thanks for explanation Tomasz.
> So it reordered:
> lp[0] = 1;
> pnum->u64 = gptbl[v].pnum;
> correct?
> My first thought was to insert a rte_complier_barrier() between these two
> lines, but actually your approach looks cleaner.
> Konstantin
Yes.
[dpdk-dev] Change new libraries to have dpdk_ prefix instead of rte_
I'd like people opinion of Thomas proposal to have all new libraries use a dpdk_ prefix instead of rte_*. Although I agree that dpdk_ would probably make sense, I don't like the ascetics of inconsistent prefixes on dpdk libraries. Any comments? 2016-04-05 09:48, Trahe, Fiona: > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > 2016-04-05 08:53, Fiona Trahe: > > > The cryptodev API was introduced in the DPDK 2.2 release. > > > Since then it has > > > - been reviewed and iterated for the DPDK 16.04 release > > > - had extensive use by the l2fwd-crypto app, > > > the ipsec-secgw example app, > > > the test app. > > > We believe it is now stable and the EXPERIMENTAL label should be removed. > > > > Are you sure sure? :) > > It means you will try hard to not change the API anymore or you'll need a > > deprecation notice strongly agreed (outside of your team). > > We're sure sure :) I think we could change the namespace before making this API stable. What about using a dpdk_ prefix instead of rte_ ? (and some macros have CRYPTODEV or CDEV prefixes)
[dpdk-dev] DPDK namespace
DPDK is going to be more popular in Linux distributions. It means people will have some DPDK files in their /usr/include and some DPDK libraries on their system. Let's imagine someone trying to compile an application which needs rte_ethdev.h. He has to figure out that this "rte header" is provided by the DPDK. Hopefully it will be explained on StackOverflow that RTE stands for DPDK. Then someone else will try to run a binary without having installed the DPDK libraries. The linker will require libethdev.so (no prefix here). StackOverflow will probably have another good answer (among wrong ones): "Hey Sherlock Holmes, have you tried to install the DPDK library?" Followed by an insight: "You know, the DPDK naming is weird..." And we could continue the story with developers having some naming clash because of some identifiers not prefixed at all. The goal of this email is to get some feedback on how important it is to fix the DPDK namespace. If there is enough agreement that we should do something, I suggest to introduce the "dpdk_" prefix slowly and live with both "rte_" and "dpdk_" during some time. We could start using the new prefix for the new APIs (example: crypto) or when there is a significant API break (example: mempool). Opinions welcome!
[dpdk-dev] Change new libraries to have dpdk_ prefix instead of rte_
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Declan Doherty > Sent: Tuesday, April 05, 2016 2:29 PM > To: dev at dpdk.org > Subject: [dpdk-dev] Change new libraries to have dpdk_ prefix instead of rte_ > > I'd like people opinion of Thomas proposal to have all new libraries use > a dpdk_ prefix instead of rte_*. Although I agree that dpdk_ would > probably make sense, I don't like the ascetics of inconsistent prefixes > on dpdk libraries. Any comments? I suppose it is a bit strange to have rte_ prefix for one set of libraries, and dpdk_ prefix for others. If we'd decide to change the prefix, then my vote would be to do that for all dpdk libraries at once. BTW, why do we need to change it at all? 'rte_' is probably not the best one, but at least it is well known/used. Konstantin > > > > > 2016-04-05 09:48, Trahe, Fiona: > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > > 2016-04-05 08:53, Fiona Trahe: > > > > The cryptodev API was introduced in the DPDK 2.2 release. > > > > Since then it has > > > > - been reviewed and iterated for the DPDK 16.04 release > > > > - had extensive use by the l2fwd-crypto app, > > > > the ipsec-secgw example app, > > > > the test app. > > > > We believe it is now stable and the EXPERIMENTAL label should be > > > > removed. > > > > > > Are you sure sure? :) > > > It means you will try hard to not change the API anymore or you'll need a > > > deprecation notice strongly agreed (outside of your team). > > > > We're sure sure :) > > I think we could change the namespace before making this API stable. > What about using a dpdk_ prefix instead of rte_ ? > (and some macros have CRYPTODEV or CDEV prefixes) >
[dpdk-dev] [RFC] vhost-user public struct refactor (was Re: [PATCH RFC 2/4] vhost: make buf vector for scatter RX) local.
On Tue, Apr 05, 2016 at 10:37:13AM +0200, Thomas Monjalon wrote: > 2016-04-05 13:47, Yuanhan Liu: > > So, I was considering to add vhost-user Tx delayed-copy (or zero copy) > > support recently, which comes to yet another ABI violation, as we need > > add a new field to virtio_memory_regions struct to do guest phys addr > > to host phys addr translation. You may ask, however, that why do we need > > expose virtio_memory_regions struct to users at all? > > > > You are right, we don't have to. And here is the thing: we exposed way > > too many fields (or even structures) than necessary. Say, vhost_virtqueue > > struct should NOT be exposed to user at all: application just need to > > tell the right queue id to locate a specific queue, and that's all. > > The structure should be defined in an internal header file. With that, > > we could do any changes to it we want, without worrying about that we > > may offense the painful ABI rules. > > > > Similar changes could be done to virtio_net struct as well, just exposing > > very few fields that are necessary and moving all others to an internal > > structure. > > > > Huawei then suggested a more radical yet much cleaner one: just exposing > > a virtio_net handle to application, just like the way kernel exposes an > > fd to user for locating a specific file. However, it's more than an ABI > > change; it's also an API change: some fields are referenced by applications, > > such as flags, virt_qp_nb. We could expose some new functions to access > > them though. > > > > I'd vote for this one, as it sounds very clean to me. This would also > > solve the block issue of this patch. Though it would break OVS, I'm thinking > > that'd be okay, as OVS has dependence on DPDK version: what we need to > > do is just to send few patches to OVS, and let it points to next release, > > say DPDK v16.07. Flavio, please correct me if I'm wrong. > > > > Thoughts/comments? > > Do you plan to send a deprecation notice to change API in 16.07? Yes, I planned to, shortly. Before that, I'd ask for comments first. --yliu
[dpdk-dev] [PATCH 00/10] Fix build errors related to exported headers
DPDK uses GNU C language extensions in most of its code base. This is fine for internal source files whose compilation flags are controlled by DPDK, however user applications that use exported "public" headers may experience compilation failures when enabling strict error/standard checks (-std and -pedantic for instance). Exported headers are installed system-wide and must be as clean as possible so applications do not have to use workarounds for compilation issues. This patchset affects exported headers only, compilation problems are addressed as follows: - adding the __extension__ keyword to nonstandard constructs (same method as existing libraries when there is no other choice) - adding the __extension__ keyword to C11 constructs to remain compatible with pure C99 - adding missing includes so exported files can be included out of order and on their own - fixing GNU printf-like variadic macros as there is no magic keyword for these Adrien Mazarguil (10): lib: add extension keyword to braced-groups within expressions lib: add extension keyword to large enum values lib: use C99 syntax for zero-size arrays lib: add extension keyword to nonstandard bit-fields lib: add extension keyword to structs with no members lib: add extension keyword to unnamed structs/unions lib: fix missing include dependencies lib: add extension keyword to forward reference to enum types lib: remove named variadic macros in exported headers lib: hide static functions that are never defined lib/librte_acl/rte_acl.h | 2 +- lib/librte_cfgfile/rte_cfgfile.h | 2 ++ lib/librte_cmdline/cmdline.h | 1 + lib/librte_cmdline/cmdline_parse_portlist.h| 1 + lib/librte_cmdline/cmdline_socket.h| 3 ++ lib/librte_cryptodev/rte_crypto.h | 3 ++ lib/librte_cryptodev/rte_crypto_sym.h | 4 +++ lib/librte_cryptodev/rte_cryptodev.h | 41 ++ lib/librte_cryptodev/rte_cryptodev_pmd.h | 6 ++-- .../common/include/arch/arm/rte_byteorder.h| 3 ++ .../common/include/arch/arm/rte_memcpy_32.h| 3 +- .../common/include/arch/arm/rte_prefetch_32.h | 2 ++ .../common/include/arch/arm/rte_prefetch_64.h | 2 ++ lib/librte_eal/common/include/arch/arm/rte_vect.h | 1 + .../common/include/arch/ppc_64/rte_atomic.h| 2 ++ .../common/include/arch/ppc_64/rte_byteorder.h | 2 ++ .../common/include/arch/ppc_64/rte_cycles.h| 3 ++ .../common/include/arch/ppc_64/rte_memcpy.h| 3 +- .../common/include/arch/ppc_64/rte_prefetch.h | 2 ++ .../common/include/arch/x86/rte_atomic.h | 3 ++ .../common/include/arch/x86/rte_atomic_32.h| 9 + .../common/include/arch/x86/rte_atomic_64.h| 8 + .../common/include/arch/x86/rte_byteorder.h| 3 ++ .../common/include/arch/x86/rte_byteorder_32.h | 7 .../common/include/arch/x86/rte_byteorder_64.h | 7 .../common/include/arch/x86/rte_cycles.h | 3 ++ .../common/include/arch/x86/rte_memcpy.h | 4 +-- .../common/include/arch/x86/rte_prefetch.h | 2 ++ lib/librte_eal/common/include/arch/x86/rte_rtm.h | 1 + lib/librte_eal/common/include/arch/x86/rte_vect.h | 8 +++-- lib/librte_eal/common/include/generic/rte_atomic.h | 1 + .../common/include/generic/rte_byteorder.h | 2 ++ .../common/include/generic/rte_cpuflags.h | 3 ++ lib/librte_eal/common/include/generic/rte_memcpy.h | 7 ++-- lib/librte_eal/common/include/rte_common.h | 22 ++-- lib/librte_eal/common/include/rte_devargs.h| 1 + lib/librte_eal/common/include/rte_eal.h| 1 + lib/librte_eal/common/include/rte_interrupts.h | 2 ++ lib/librte_eal/common/include/rte_memory.h | 4 +++ lib/librte_eal/common/include/rte_memzone.h| 2 ++ lib/librte_eal/common/include/rte_time.h | 8 + lib/librte_eal/common/include/rte_version.h| 1 + .../linuxapp/eal/include/exec-env/rte_interrupts.h | 1 + .../linuxapp/eal/include/exec-env/rte_kni_common.h | 2 +- lib/librte_ether/rte_dev_info.h| 2 ++ lib/librte_ether/rte_eth_ctrl.h| 4 +++ lib/librte_ether/rte_ethdev.h | 4 +++ lib/librte_hash/rte_fbk_hash.h | 2 +- lib/librte_hash/rte_thash.h| 4 +++ lib/librte_ip_frag/rte_ip_frag.h | 2 +- lib/librte_lpm/rte_lpm.h | 7 +++- lib/librte_lpm/rte_lpm6.h | 2 ++ lib/librte_lpm/rte_lpm_neon.h | 1 + lib/librte_lpm/rte_lpm_sse.h | 1 + lib/librte_mbuf/rte_mbuf.h | 9 + lib/librte_mempool/rte_mempool.h | 1 + lib/librte_pipeline/rte_pipeline.h | 5 ++- lib/libr
[dpdk-dev] [PATCH 01/10] lib: add extension keyword to braced-groups within expressions
Exported header files used by applications should allow the strictest
compiler flags. Language extensions used in many places must be explicitly
marked or removed to avoid warnings and compilation failures.
This commit prevents the following errors:
error: ISO C forbids braced-groups within expressions
Signed-off-by: Adrien Mazarguil
---
lib/librte_eal/common/include/arch/arm/rte_memcpy_32.h | 3 ++-
lib/librte_eal/common/include/arch/ppc_64/rte_memcpy.h | 3 ++-
lib/librte_eal/common/include/arch/x86/rte_memcpy.h| 4 ++--
lib/librte_eal/common/include/arch/x86/rte_vect.h | 6 --
lib/librte_eal/common/include/rte_common.h | 6 --
5 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/lib/librte_eal/common/include/arch/arm/rte_memcpy_32.h
b/lib/librte_eal/common/include/arch/arm/rte_memcpy_32.h
index 988125b..a4f954a 100644
--- a/lib/librte_eal/common/include/arch/arm/rte_memcpy_32.h
+++ b/lib/librte_eal/common/include/arch/arm/rte_memcpy_32.h
@@ -148,7 +148,8 @@ rte_mov256(uint8_t *dst, const uint8_t *src)
}
#define rte_memcpy(dst, src, n) \
- ({ (__builtin_constant_p(n)) ? \
+ __extension__ ({ \
+ __builtin_constant_p(n)) ? \
memcpy((dst), (src), (n)) : \
rte_memcpy_func((dst), (src), (n)); })
diff --git a/lib/librte_eal/common/include/arch/ppc_64/rte_memcpy.h
b/lib/librte_eal/common/include/arch/ppc_64/rte_memcpy.h
index acf7aac..a71fb13 100644
--- a/lib/librte_eal/common/include/arch/ppc_64/rte_memcpy.h
+++ b/lib/librte_eal/common/include/arch/ppc_64/rte_memcpy.h
@@ -95,7 +95,8 @@ rte_mov256(uint8_t *dst, const uint8_t *src)
}
#define rte_memcpy(dst, src, n) \
- ({ (__builtin_constant_p(n)) ? \
+ __extension__ ({ \
+ __builtin_constant_p(n)) ? \
memcpy((dst), (src), (n)) : \
rte_memcpy_func((dst), (src), (n)); })
diff --git a/lib/librte_eal/common/include/arch/x86/rte_memcpy.h
b/lib/librte_eal/common/include/arch/x86/rte_memcpy.h
index f463ab3..68b7818 100644
--- a/lib/librte_eal/common/include/arch/x86/rte_memcpy.h
+++ b/lib/librte_eal/common/include/arch/x86/rte_memcpy.h
@@ -650,7 +650,7 @@ rte_mov256(uint8_t *dst, const uint8_t *src)
* - __m128i ~ must be pre-defined
*/
#define MOVEUNALIGNED_LEFT47_IMM(dst, src, len, offset)
\
-({
\
+__extension__ ({
\
int tmp;
\
while (len >= 128 + 16 - offset) {
\
xmm0 = _mm_loadu_si128((const __m128i *)((const uint8_t *)src - offset
+ 0 * 16)); \
@@ -711,7 +711,7 @@ rte_mov256(uint8_t *dst, const uint8_t *src)
* - __m128i ~ used in MOVEUNALIGNED_LEFT47_IMM must be
pre-defined
*/
#define MOVEUNALIGNED_LEFT47(dst, src, len, offset) \
-({\
+__extension__ ({ \
switch (offset) { \
case 0x01: MOVEUNALIGNED_LEFT47_IMM(dst, src, n, 0x01); break;\
case 0x02: MOVEUNALIGNED_LEFT47_IMM(dst, src, n, 0x02); break;\
diff --git a/lib/librte_eal/common/include/arch/x86/rte_vect.h
b/lib/librte_eal/common/include/arch/x86/rte_vect.h
index b698797..2836f2c 100644
--- a/lib/librte_eal/common/include/arch/x86/rte_vect.h
+++ b/lib/librte_eal/common/include/arch/x86/rte_vect.h
@@ -106,7 +106,8 @@ typedef union rte_ymm {
#endif /* __AVX__ */
#ifdef RTE_ARCH_I686
-#define _mm_cvtsi128_si64(a) ({ \
+#define _mm_cvtsi128_si64(a)\
+__extension__ ({\
rte_xmm_t m;\
m.x = (a); \
(m.u64[0]); \
@@ -117,7 +118,8 @@ typedef union rte_ymm {
* Prior to version 12.1 icc doesn't support _mm_set_epi64x.
*/
#if (defined(__ICC) && __ICC < 1210)
-#define _mm_set_epi64x(a, b) ({ \
+#define _mm_set_epi64x(a, b) \
+__extension__ ({ \
rte_xmm_t m; \
m.u64[0] = b;\
m.u64[1] = a;\
diff --git a/lib/librte_eal/common/include/rte_common.h
b/lib/librte_eal/common/include/rte_common.h
index 332f2a4..477472b 100644
--- a/lib/librte_eal/common/include/rte_common.h
+++ b/lib/librte_eal/common/include/rte_common.h
@@ -268,7 +268,8 @@ rte_align64pow2(uint64_t v)
/**
* Macro to return the minimum of two numbers
*/
-#define RTE_MIN(a, b) ({ \
+#define RTE_MIN(a, b) \
+ __extension__ ({ \
typeof (a) _a = (a); \
typ
[dpdk-dev] [PATCH 02/10] lib: add extension keyword to large enum values
Exported header files used by applications should allow the strictest
compiler flags. Language extensions used in many places must be explicitly
marked or removed to avoid warnings and compilation failures.
This commit prevents the following errors:
error: ISO C restricts enumerator values to range of `int'
Signed-off-by: Adrien Mazarguil
---
lib/librte_eal/common/include/rte_memory.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/librte_eal/common/include/rte_memory.h
b/lib/librte_eal/common/include/rte_memory.h
index f8dbece..09b5b99 100644
--- a/lib/librte_eal/common/include/rte_memory.h
+++ b/lib/librte_eal/common/include/rte_memory.h
@@ -54,6 +54,7 @@ extern "C" {
#include
+__extension__
enum rte_page_sizes {
RTE_PGSIZE_4K= 1ULL << 12,
RTE_PGSIZE_64K = 1ULL << 16,
--
2.1.4
[dpdk-dev] [PATCH 03/10] lib: use C99 syntax for zero-size arrays
Exported header files used by applications should allow the strictest
compiler flags. Language extensions used in many places must be explicitly
marked or removed to avoid warnings and compilation failures.
The extension keyword is used whenever the C99 syntax cannot do it.
This commit prevents the following errors:
error: ISO C forbids zero-size array `[...]'
Signed-off-by: Adrien Mazarguil
---
lib/librte_acl/rte_acl.h | 2 +-
lib/librte_cryptodev/rte_cryptodev.h | 2 +-
lib/librte_cryptodev/rte_cryptodev_pmd.h | 2 +-
lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h | 2 +-
lib/librte_hash/rte_fbk_hash.h| 2 +-
lib/librte_ip_frag/rte_ip_frag.h | 2 +-
lib/librte_lpm/rte_lpm.h | 2 +-
lib/librte_mbuf/rte_mbuf.h| 3 +++
lib/librte_pipeline/rte_pipeline.h| 2 +-
lib/librte_ring/rte_ring.h| 2 +-
lib/librte_sched/rte_bitmap.h | 2 +-
lib/librte_vhost/rte_virtio_net.h | 2 +-
12 files changed, 14 insertions(+), 11 deletions(-)
diff --git a/lib/librte_acl/rte_acl.h b/lib/librte_acl/rte_acl.h
index 0979a09..c059dc3 100644
--- a/lib/librte_acl/rte_acl.h
+++ b/lib/librte_acl/rte_acl.h
@@ -144,7 +144,7 @@ struct rte_acl_rule_data {
struct rte_acl_field field[fld_num]; \
}
-RTE_ACL_RULE_DEF(rte_acl_rule, 0);
+RTE_ACL_RULE_DEF(rte_acl_rule,);
#defineRTE_ACL_RULE_SZ(fld_num)\
(sizeof(struct rte_acl_rule) + sizeof(struct rte_acl_field) * (fld_num))
diff --git a/lib/librte_cryptodev/rte_cryptodev.h
b/lib/librte_cryptodev/rte_cryptodev.h
index b599c95..ba6042d 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -846,7 +846,7 @@ struct rte_cryptodev_sym_session {
} __rte_aligned(8);
/**< Public symmetric session details */
- char _private[0];
+ char _private[];
/**< Private session material */
};
diff --git a/lib/librte_cryptodev/rte_cryptodev_pmd.h
b/lib/librte_cryptodev/rte_cryptodev_pmd.h
index 7d049ea..3a3845c 100644
--- a/lib/librte_cryptodev/rte_cryptodev_pmd.h
+++ b/lib/librte_cryptodev/rte_cryptodev_pmd.h
@@ -71,7 +71,7 @@ struct rte_cryptodev_session {
struct rte_mempool *mp;
} __rte_aligned(8);
- char _private[0];
+ char _private[];
};
struct rte_cryptodev_driver;
diff --git a/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h
b/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h
index 7e5e598..994ec47 100644
--- a/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h
+++ b/lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h
@@ -102,7 +102,7 @@ struct rte_kni_fifo {
volatile unsigned read; /**< Next position to be read */
unsigned len;/**< Circular buffer length */
unsigned elem_size; /**< Pointer size - for 32/64 bit OS */
- void * volatile buffer[0]; /**< The buffer contains mbuf pointers */
+ void *volatile buffer[]; /**< The buffer contains mbuf pointers */
};
/*
diff --git a/lib/librte_hash/rte_fbk_hash.h b/lib/librte_hash/rte_fbk_hash.h
index a430961..bd46048 100644
--- a/lib/librte_hash/rte_fbk_hash.h
+++ b/lib/librte_hash/rte_fbk_hash.h
@@ -115,7 +115,7 @@ struct rte_fbk_hash_table {
uint32_t init_val; /**< For initialising hash function. */
/** A flat table of all buckets. */
- union rte_fbk_hash_entry t[0];
+ union rte_fbk_hash_entry t[];
};
/**
diff --git a/lib/librte_ip_frag/rte_ip_frag.h b/lib/librte_ip_frag/rte_ip_frag.h
index 92cedf2..4c3faad 100644
--- a/lib/librte_ip_frag/rte_ip_frag.h
+++ b/lib/librte_ip_frag/rte_ip_frag.h
@@ -124,7 +124,7 @@ struct rte_ip_frag_tbl {
struct ip_frag_pkt *last; /**< last used entry. */
struct ip_pkt_list lru; /**< LRU list for table entries. */
struct ip_frag_tbl_stat stat; /**< statistics counters. */
- struct ip_frag_pkt pkt[0];/**< hash table. */
+ struct ip_frag_pkt pkt[]; /**< hash table. */
};
/** IPv6 fragment extension header */
diff --git a/lib/librte_lpm/rte_lpm.h b/lib/librte_lpm/rte_lpm.h
index 2df1d67..4397f5d 100644
--- a/lib/librte_lpm/rte_lpm.h
+++ b/lib/librte_lpm/rte_lpm.h
@@ -193,7 +193,7 @@ struct rte_lpm_v20 {
__rte_cache_aligned; /**< LPM tbl24 table. */
struct rte_lpm_tbl_entry_v20 tbl8[RTE_LPM_TBL8_NUM_ENTRIES]
__rte_cache_aligned; /**< LPM tbl8 table. */
- struct rte_lpm_rule_v20 rules_tbl[0] \
+ struct rte_lpm_rule_v20 rules_tbl[] \
__rte_cache_aligned; /**< LPM rules. */
};
diff --git a/lib
[dpdk-dev] [PATCH 04/10] lib: add extension keyword to nonstandard bit-fields
Exported header files used by applications should allow the strictest
compiler flags. Language extensions used in many places must be explicitly
marked or removed to avoid warnings and compilation failures.
This commit prevents the following errors:
error: type of bit-field `[...]' is a GCC extension
Note: the standard does not require implementations to issue a diagnostic
message with these, and such errors do not occur with recent GCC or clang
versions. However, GCC 4.7 is still common and using the extension keyword
is easier than checking compiler version.
Signed-off-by: Adrien Mazarguil
---
lib/librte_cryptodev/rte_cryptodev.h | 2 ++
lib/librte_ether/rte_ethdev.h| 4
lib/librte_lpm/rte_lpm.h | 4
lib/librte_mbuf/rte_mbuf.h | 1 +
4 files changed, 11 insertions(+)
diff --git a/lib/librte_cryptodev/rte_cryptodev.h
b/lib/librte_cryptodev/rte_cryptodev.h
index ba6042d..bea48bb 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -706,6 +706,7 @@ struct rte_cryptodev {
struct rte_cryptodev_cb_list link_intr_cbs;
/**< User application callback for interrupts if present */
+ __extension__
uint8_t attached : 1;
/**< Flag indicating the device is attached */
} __rte_cache_aligned;
@@ -729,6 +730,7 @@ struct rte_cryptodev_data {
char name[RTE_CRYPTODEV_NAME_MAX_LEN];
/**< Unique identifier name */
+ __extension__
uint8_t dev_started : 1;
/**< Device state: STARTED(1)/STOPPED(0) */
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 37ddd51..d002ba6 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -281,6 +281,7 @@ struct rte_eth_stats {
/**
* A structure used to retrieve link-level information of an Ethernet port.
*/
+__extension__
struct rte_eth_link {
uint32_t link_speed;/**< ETH_SPEED_NUM_ */
uint16_t link_duplex : 1; /**< ETH_LINK_[HALF/FULL]_DUPLEX */
@@ -372,6 +373,7 @@ struct rte_eth_rxmode {
enum rte_eth_rx_mq_mode mq_mode;
uint32_t max_rx_pkt_len; /**< Only used if jumbo_frame enabled. */
uint16_t split_hdr_size; /**< hdr buf size (header_split enabled).*/
+ __extension__
uint16_t header_split : 1, /**< Header Split enable. */
hw_ip_checksum : 1, /**< IP/UDP/TCP checksum offload enable.
*/
hw_vlan_filter : 1, /**< VLAN filter enable. */
@@ -656,6 +658,7 @@ struct rte_eth_txmode {
/* For i40e specifically */
uint16_t pvid;
+ __extension__
uint8_t hw_vlan_reject_tagged : 1,
/**< If set, reject sending out tagged pkts */
hw_vlan_reject_untagged : 1,
@@ -1688,6 +1691,7 @@ struct rte_eth_dev_data {
struct ether_addr* hash_mac_addrs;
/** Device Ethernet MAC addresses of hash filtering. */
uint8_t port_id; /**< Device [external] port identifier. */
+ __extension__
uint8_t promiscuous : 1, /**< RX promiscuous mode ON(1) / OFF(0). */
scattered_rx : 1, /**< RX of scattered packets is ON(1) /
OFF(0) */
all_multicast : 1, /**< RX all multicast mode ON(1) / OFF(0). */
diff --git a/lib/librte_lpm/rte_lpm.h b/lib/librte_lpm/rte_lpm.h
index 4397f5d..4ea6bf6 100644
--- a/lib/librte_lpm/rte_lpm.h
+++ b/lib/librte_lpm/rte_lpm.h
@@ -93,6 +93,7 @@ extern "C" {
#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
/** @internal Tbl24 entry structure. */
+__extension__
struct rte_lpm_tbl_entry_v20 {
/**
* Stores Next hop (tbl8 or tbl24 when valid_group is not set) or
@@ -116,6 +117,7 @@ struct rte_lpm_tbl_entry_v20 {
uint8_t depth :6; /**< Rule depth. */
};
+__extension__
struct rte_lpm_tbl_entry {
/**
* Stores Next hop (tbl8 or tbl24 when valid_group is not set) or
@@ -137,6 +139,7 @@ struct rte_lpm_tbl_entry {
};
#else
+__extension__
struct rte_lpm_tbl_entry_v20 {
uint8_t depth :6;
uint8_t valid_group :1;
@@ -147,6 +150,7 @@ struct rte_lpm_tbl_entry_v20 {
};
};
+__extension__
struct rte_lpm_tbl_entry {
uint32_t depth :6;
uint32_t valid_group :1;
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index bad349a..81eb3e4 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -827,6 +827,7 @@ struct rte_mbuf {
/* fields to support TX offloads */
union {
uint64_t tx_offload; /**< combined for easy fetch */
+ __extension__
struct {
uint64_t l2_len:7; /**< L2 (MAC) Header Length. */
uint64_t l3_len:9; /**< L3 (IP) Header Length. */
--
2.1.4
[dpdk-dev] [PATCH 05/10] lib: add extension keyword to structs with no members
Exported header files used by applications should allow the strictest
compiler flags. Language extensions used in many places must be explicitly
marked or removed to avoid warnings and compilation failures.
This commit prevents the following errors:
error: struct has no members
Signed-off-by: Adrien Mazarguil
---
lib/librte_mempool/rte_mempool.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/librte_mempool/rte_mempool.h b/lib/librte_mempool/rte_mempool.h
index 9745bf0..a46e661 100644
--- a/lib/librte_mempool/rte_mempool.h
+++ b/lib/librte_mempool/rte_mempool.h
@@ -169,6 +169,7 @@ struct rte_mempool_objhdr {
* In debug mode, each object stored in mempools are suffixed by this
* trailer structure containing a cookie preventing memory corruptions.
*/
+__extension__
struct rte_mempool_objtlr {
#ifdef RTE_LIBRTE_MEMPOOL_DEBUG
uint64_t cookie; /**< Debug cookie. */
--
2.1.4
[dpdk-dev] [PATCH 06/10] lib: add extension keyword to unnamed structs/unions
Exported header files used by applications should allow the strictest
compiler flags. Language extensions used in many places must be explicitly
marked to avoid warnings and compilation failures.
Unnamed structs/unions are allowed since C11, however many compiler versions
do not use this mode by default.
This commit prevents the following errors:
error: ISO C99 doesn't support unnamed structs/unions
error: struct has no named members
Signed-off-by: Adrien Mazarguil
---
lib/librte_cryptodev/rte_crypto.h | 3 +++
lib/librte_cryptodev/rte_crypto_sym.h | 4
lib/librte_cryptodev/rte_cryptodev.h | 5 +
lib/librte_cryptodev/rte_cryptodev_pmd.h | 2 ++
lib/librte_eal/common/include/arch/ppc_64/rte_cycles.h| 3 +++
lib/librte_eal/common/include/arch/x86/rte_atomic_32.h| 3 +++
lib/librte_eal/common/include/arch/x86/rte_cycles.h | 3 +++
lib/librte_eal/common/include/rte_common.h| 7 +++
lib/librte_eal/common/include/rte_devargs.h | 1 +
lib/librte_eal/common/include/rte_interrupts.h| 2 ++
lib/librte_eal/common/include/rte_memory.h| 1 +
lib/librte_eal/common/include/rte_memzone.h | 2 ++
lib/librte_eal/linuxapp/eal/include/exec-env/rte_interrupts.h | 1 +
lib/librte_hash/rte_thash.h | 4
lib/librte_lpm/rte_lpm.h | 1 +
lib/librte_mbuf/rte_mbuf.h| 5 +
lib/librte_pipeline/rte_pipeline.h| 3 +++
lib/librte_timer/rte_timer.h | 2 ++
18 files changed, 52 insertions(+)
diff --git a/lib/librte_cryptodev/rte_crypto.h
b/lib/librte_cryptodev/rte_crypto.h
index 5bc3eaa..11a7759 100644
--- a/lib/librte_cryptodev/rte_crypto.h
+++ b/lib/librte_cryptodev/rte_crypto.h
@@ -40,6 +40,8 @@
*
*/
+#include
+
#ifdef __cplusplus
extern "C" {
#endif
@@ -111,6 +113,7 @@ struct rte_crypto_op {
void *opaque_data;
/**< Opaque pointer for user data */
+ RTE_STD_C11
union {
struct rte_crypto_sym_op *sym;
/**< Symmetric operation parameters */
diff --git a/lib/librte_cryptodev/rte_crypto_sym.h
b/lib/librte_cryptodev/rte_crypto_sym.h
index 913941a..493c95b 100644
--- a/lib/librte_cryptodev/rte_crypto_sym.h
+++ b/lib/librte_cryptodev/rte_crypto_sym.h
@@ -42,6 +42,8 @@
* as supported symmetric crypto operation combinations.
*/
+#include
+
#ifdef __cplusplus
extern "C" {
#endif
@@ -333,6 +335,7 @@ struct rte_crypto_sym_xform {
/**< next xform in chain */
enum rte_crypto_sym_xform_type type
; /**< xform type */
+ RTE_STD_C11
union {
struct rte_crypto_auth_xform auth;
/**< Authentication / hash xform */
@@ -371,6 +374,7 @@ struct rte_crypto_sym_op {
enum rte_crypto_sym_op_sess_type type;
+ RTE_STD_C11
union {
struct rte_cryptodev_sym_session *session;
/**< Handle for the initialised session context */
diff --git a/lib/librte_cryptodev/rte_cryptodev.h
b/lib/librte_cryptodev/rte_cryptodev.h
index bea48bb..62e616b 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -44,6 +44,8 @@
*
*/
+#include
+
#ifdef __cplusplus
extern "C" {
#endif
@@ -104,6 +106,7 @@ extern const char **rte_cyptodev_names;
struct rte_cryptodev_symmetric_capability {
enum rte_crypto_sym_xform_type xform_type;
/**< Transform type : Authentication / Cipher */
+ RTE_STD_C11
union {
struct {
enum rte_crypto_auth_algorithm algo;
@@ -177,6 +180,7 @@ struct rte_cryptodev_capabilities {
enum rte_crypto_op_type op;
/**< Operation type */
+ RTE_STD_C11
union {
struct rte_cryptodev_symmetric_capability sym;
/**< Symmetric operation capability parameters */
@@ -838,6 +842,7 @@ rte_cryptodev_enqueue_burst(uint8_t dev_id, uint16_t qp_id,
/** Cryptodev symmetric crypto session */
struct rte_cryptodev_sym_session {
+ RTE_STD_C11
struct {
uint8_t dev_id;
/**< Device Id */
diff --git a/lib/librte_cryptodev/rte_cryptodev_pmd.h
b/lib/librte_cryptodev/rte_cryptodev_pmd.h
index 3a3845c..cf08a50 100644
--- a/lib/librte_cryptodev/rte_cryptodev_pmd.h
+++ b/lib/librte_cryptodev/rte_cryptodev_pmd.h
@@ -52,6 +52,7 @@ extern "C" {
#include
#include
#include
+#include
#include "rte_crypto.h"
#include "rte_cryptodev.h"
@@ -65,6 +66,7 @@ extern "C" {
#endif
struct rte_cryptodev_session {
+ RTE_STD_C11
struct {
uint8_t dev_id;
enum rte_cryptodev_type type;
diff --git a/lib/librte_eal/common/include/arch/ppc_64/rt
[dpdk-dev] [PATCH 07/10] lib: fix missing include dependencies
Exported header files for use by applications should be self sufficient and
allow out of order inclusion. Moreover, they must include all the system
headers they need for types and macros.
This commit prevents the following errors:
error: `RTE_MAX_LCORE' undeclared here (not in a function)
error: `RTE_LPM_VALID_EXT_ENTRY_BITMASK' undeclared (first use in this
function)
error: #error "Unsupported cache line size"
error: `asm' undeclared (first use in this function)
error: implicit declaration of function `[...]'
error: unknown type name `[...]'
error: field `mac_addr' has incomplete type
error: `CHAR_BIT' undeclared here (not in a function)
error: `struct timespec' declared inside parameter list
Signed-off-by: Adrien Mazarguil
---
lib/librte_cfgfile/rte_cfgfile.h | 2 ++
lib/librte_cmdline/cmdline.h | 1 +
lib/librte_cmdline/cmdline_parse_portlist.h | 1 +
lib/librte_cmdline/cmdline_socket.h | 3 +++
lib/librte_eal/common/include/arch/arm/rte_byteorder.h| 3 +++
lib/librte_eal/common/include/arch/arm/rte_prefetch_32.h | 2 ++
lib/librte_eal/common/include/arch/arm/rte_prefetch_64.h | 2 ++
lib/librte_eal/common/include/arch/arm/rte_vect.h | 1 +
lib/librte_eal/common/include/arch/ppc_64/rte_atomic.h| 2 ++
lib/librte_eal/common/include/arch/ppc_64/rte_byteorder.h | 2 ++
lib/librte_eal/common/include/arch/ppc_64/rte_prefetch.h | 2 ++
lib/librte_eal/common/include/arch/x86/rte_atomic.h | 3 +++
lib/librte_eal/common/include/arch/x86/rte_atomic_32.h| 6 ++
lib/librte_eal/common/include/arch/x86/rte_atomic_64.h| 8
lib/librte_eal/common/include/arch/x86/rte_byteorder.h| 3 +++
lib/librte_eal/common/include/arch/x86/rte_byteorder_32.h | 7 +++
lib/librte_eal/common/include/arch/x86/rte_byteorder_64.h | 7 +++
lib/librte_eal/common/include/arch/x86/rte_prefetch.h | 2 ++
lib/librte_eal/common/include/arch/x86/rte_rtm.h | 1 +
lib/librte_eal/common/include/arch/x86/rte_vect.h | 2 ++
lib/librte_eal/common/include/generic/rte_atomic.h| 1 +
lib/librte_eal/common/include/generic/rte_byteorder.h | 2 ++
lib/librte_eal/common/include/rte_eal.h | 1 +
lib/librte_eal/common/include/rte_memory.h| 2 ++
lib/librte_eal/common/include/rte_time.h | 8
lib/librte_eal/common/include/rte_version.h | 1 +
lib/librte_ether/rte_dev_info.h | 2 ++
lib/librte_ether/rte_eth_ctrl.h | 4
lib/librte_lpm/rte_lpm6.h | 2 ++
lib/librte_lpm/rte_lpm_neon.h | 1 +
lib/librte_lpm/rte_lpm_sse.h | 1 +
lib/librte_reorder/rte_reorder.h | 2 ++
lib/librte_sched/rte_bitmap.h | 1 +
lib/librte_sched/rte_reciprocal.h | 2 ++
lib/librte_sched/rte_sched_common.h | 2 ++
35 files changed, 92 insertions(+)
diff --git a/lib/librte_cfgfile/rte_cfgfile.h b/lib/librte_cfgfile/rte_cfgfile.h
index 834f828..8dd50ba 100644
--- a/lib/librte_cfgfile/rte_cfgfile.h
+++ b/lib/librte_cfgfile/rte_cfgfile.h
@@ -34,6 +34,8 @@
#ifndef __INCLUDE_RTE_CFGFILE_H__
#define __INCLUDE_RTE_CFGFILE_H__
+#include
+
#ifdef __cplusplus
extern "C" {
#endif
diff --git a/lib/librte_cmdline/cmdline.h b/lib/librte_cmdline/cmdline.h
index 2578ca8..65d73b0 100644
--- a/lib/librte_cmdline/cmdline.h
+++ b/lib/librte_cmdline/cmdline.h
@@ -63,6 +63,7 @@
#include
#include
+#include
/**
* @file
diff --git a/lib/librte_cmdline/cmdline_parse_portlist.h
b/lib/librte_cmdline/cmdline_parse_portlist.h
index 73d70e0..058df3e 100644
--- a/lib/librte_cmdline/cmdline_parse_portlist.h
+++ b/lib/librte_cmdline/cmdline_parse_portlist.h
@@ -61,6 +61,7 @@
#ifndef _PARSE_PORTLIST_H_
#define _PARSE_PORTLIST_H_
+#include
#include
#ifdef __cplusplus
diff --git a/lib/librte_cmdline/cmdline_socket.h
b/lib/librte_cmdline/cmdline_socket.h
index 8cc2dfb..aa6068e 100644
--- a/lib/librte_cmdline/cmdline_socket.h
+++ b/lib/librte_cmdline/cmdline_socket.h
@@ -61,6 +61,9 @@
#ifndef _CMDLINE_SOCKET_H_
#define _CMDLINE_SOCKET_H_
+#include
+#include
+
#ifdef __cplusplus
extern "C" {
#endif
diff --git a/lib/librte_eal/common/include/arch/arm/rte_byteorder.h
b/lib/librte_eal/common/include/arch/arm/rte_byteorder.h
index 3f2dd1f..c2078e7 100644
--- a/lib/librte_eal/common/include/arch/arm/rte_byteorder.h
+++ b/lib/librte_eal/common/include/arch/arm/rte_byteorder.h
@@ -37,6 +37,9 @@
# error Platform must be built with CONFIG_RTE_FORCE_INTRINSICS
#endif
+#include
+#include
+
#ifdef __cplusplus
extern "C" {
#endif
diff --git a/lib/librte_eal/common/include/arch/arm/rte_prefetch_32.h
b/lib/librte_eal/common/include/arch/arm/rte_prefetch_32.h
index 5aeed22..29b831b 100644
--- a/lib/
[dpdk-dev] [PATCH 08/10] lib: add extension keyword to forward reference to enum types
Exported header files used by applications should allow the strictest compiler flags. Language extensions used in many places must be explicitly marked or removed to avoid warnings and compilation failures. This commit prevents the following errors: error: ISO C forbids forward references to `enum' types Signed-off-by: Adrien Mazarguil --- lib/librte_eal/common/include/generic/rte_cpuflags.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/lib/librte_eal/common/include/generic/rte_cpuflags.h b/lib/librte_eal/common/include/generic/rte_cpuflags.h index c1da357..71321f3 100644 --- a/lib/librte_eal/common/include/generic/rte_cpuflags.h +++ b/lib/librte_eal/common/include/generic/rte_cpuflags.h @@ -44,6 +44,7 @@ /** * Enumeration of all CPU features supported */ +__extension__ enum rte_cpu_flag_t; /** @@ -55,6 +56,7 @@ enum rte_cpu_flag_t; * flag name * NULL if flag ID is invalid */ +__extension__ const char * rte_cpu_get_flag_name(enum rte_cpu_flag_t feature); @@ -68,6 +70,7 @@ rte_cpu_get_flag_name(enum rte_cpu_flag_t feature); * 0 if flag is not available * -ENOENT if flag is invalid */ +__extension__ int rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature); -- 2.1.4
[dpdk-dev] [PATCH 09/10] lib: remove named variadic macros in exported headers
Exported header files used by applications should allow the strictest
compiler flags. Language extensions used in many places must be explicitly
marked or removed to avoid warnings and compilation failures.
Since there is no way to force named variadic macros as extensions, use a
a standard __VA_ARGS__ with an extra dummy argument to format strings.
This commit prevents the following errors:
error: ISO C does not permit named variadic macros
Signed-off-by: Adrien Mazarguil
---
lib/librte_cryptodev/rte_cryptodev.h | 32 +-
lib/librte_cryptodev/rte_cryptodev_pmd.h | 2 +-
lib/librte_eal/common/include/rte_common.h | 9 +
3 files changed, 28 insertions(+), 15 deletions(-)
diff --git a/lib/librte_cryptodev/rte_cryptodev.h
b/lib/librte_cryptodev/rte_cryptodev.h
index 62e616b..817d2c9 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -78,26 +78,30 @@ extern const char **rte_cyptodev_names;
/* Logging Macros */
-#define CDEV_LOG_ERR(fmt, args...) \
- RTE_LOG(ERR, CRYPTODEV, "%s() line %u: " fmt "\n", \
- __func__, __LINE__, ## args)
+#define CDEV_LOG_ERR(...) \
+ RTE_LOG(ERR, CRYPTODEV, \
+ RTE_FMT("%s() line %u: " RTE_FMT_HEAD(__VA_ARGS__,) "\n", \
+ __func__, __LINE__, RTE_FMT_TAIL(__VA_ARGS__,)))
-#define CDEV_PMD_LOG_ERR(dev, fmt, args...)\
- RTE_LOG(ERR, CRYPTODEV, "[%s] %s() line %u: " fmt "\n", \
- dev, __func__, __LINE__, ## args)
+#define CDEV_PMD_LOG_ERR(dev, ...) \
+ RTE_LOG(ERR, CRYPTODEV, \
+ RTE_FMT("[%s] %s() line %u: " RTE_FMT_HEAD(__VA_ARGS__,) "\n", \
+ dev, __func__, __LINE__, RTE_FMT_TAIL(__VA_ARGS__,)))
#ifdef RTE_LIBRTE_CRYPTODEV_DEBUG
-#define CDEV_LOG_DEBUG(fmt, args...) \
- RTE_LOG(DEBUG, CRYPTODEV, "%s() line %u: " fmt "\n",\
- __func__, __LINE__, ## args)\
+#define CDEV_LOG_DEBUG(...) \
+ RTE_LOG(DEBUG, CRYPTODEV, \
+ RTE_FMT("%s() line %u: " RTE_FMT_HEAD(__VA_ARGS__,) "\n", \
+ __func__, __LINE__, RTE_FMT_TAIL(__VA_ARGS__,)))
-#define CDEV_PMD_TRACE(fmt, args...) \
- RTE_LOG(DEBUG, CRYPTODEV, "[%s] %s: " fmt "\n", \
- dev, __func__, ## args)
+#define CDEV_PMD_TRACE(...) \
+ RTE_LOG(DEBUG, CRYPTODEV, \
+ RTE_FMT("[%s] %s: " RTE_FMT_HEAD(__VA_ARGS__,) "\n", \
+ dev, __func__, RTE_FMT_TAIL(__VA_ARGS__,)))
#else
-#define CDEV_LOG_DEBUG(fmt, args...)
-#define CDEV_PMD_TRACE(fmt, args...)
+#define CDEV_LOG_DEBUG(...) (void)0
+#define CDEV_PMD_TRACE(...) (void)0
#endif
/**
diff --git a/lib/librte_cryptodev/rte_cryptodev_pmd.h
b/lib/librte_cryptodev/rte_cryptodev_pmd.h
index cf08a50..4a07362 100644
--- a/lib/librte_cryptodev/rte_cryptodev_pmd.h
+++ b/lib/librte_cryptodev/rte_cryptodev_pmd.h
@@ -62,7 +62,7 @@ extern "C" {
#define RTE_PMD_DEBUG_TRACE(...) \
rte_pmd_debug_trace(__func__, __VA_ARGS__)
#else
-#define RTE_PMD_DEBUG_TRACE(fmt, args...)
+#define RTE_PMD_DEBUG_TRACE(...)
#endif
struct rte_cryptodev_session {
diff --git a/lib/librte_eal/common/include/rte_common.h
b/lib/librte_eal/common/include/rte_common.h
index 98ecc1c..db5ac91 100644
--- a/lib/librte_eal/common/include/rte_common.h
+++ b/lib/librte_eal/common/include/rte_common.h
@@ -335,6 +335,15 @@ rte_bsf32(uint32_t v)
/** Take a macro value and get a string version of it */
#define RTE_STR(x) _RTE_STR(x)
+/**
+ * ISO C helpers to modify format strings using variadic macros.
+ * This is a replacement for the ", ## __VA_ARGS__" GNU extension.
+ * An empty %s argument is appended to avoid a dangling comma.
+ */
+#define RTE_FMT(fmt, ...) fmt "%.0s", __VA_ARGS__ ""
+#define RTE_FMT_HEAD(fmt, ...) fmt
+#define RTE_FMT_TAIL(fmt, ...) __VA_ARGS__
+
/** Mask value of type "tp" for the first "ln" bit set. */
#defineRTE_LEN2MASK(ln, tp)\
((tp)((uint64_t)-1 >> (sizeof(uint64_t) * CHAR_BIT - (ln
--
2.1.4
[dpdk-dev] [PATCH 10/10] lib: hide static functions that are never defined
Arch-specific functions not defined for all architectures (missing on x86 in this case) and not used anywhere should not expose a prototype. This commit prevents the following errors: error: `rte_mov48' declared `static' but never defined error: `rte_memcpy_func' declared `static' but never defined Signed-off-by: Adrien Mazarguil --- lib/librte_eal/common/include/generic/rte_memcpy.h | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/lib/librte_eal/common/include/generic/rte_memcpy.h b/lib/librte_eal/common/include/generic/rte_memcpy.h index 03e8477..9f70d24 100644 --- a/lib/librte_eal/common/include/generic/rte_memcpy.h +++ b/lib/librte_eal/common/include/generic/rte_memcpy.h @@ -64,6 +64,8 @@ rte_mov16(uint8_t *dst, const uint8_t *src); static inline void rte_mov32(uint8_t *dst, const uint8_t *src); +#ifdef __DOXYGEN__ + /** * Copy 48 bytes from one location to another using optimised * instructions. The locations should not overlap. @@ -76,6 +78,8 @@ rte_mov32(uint8_t *dst, const uint8_t *src); static inline void rte_mov48(uint8_t *dst, const uint8_t *src); +#endif /* __DOXYGEN__ */ + /** * Copy 64 bytes from one location to another using optimised * instructions. The locations should not overlap. @@ -132,13 +136,12 @@ rte_mov256(uint8_t *dst, const uint8_t *src); static void * rte_memcpy(void *dst, const void *src, size_t n); -#endif /* __DOXYGEN__ */ - /* * memcpy() function used by rte_memcpy macro */ static inline void * rte_memcpy_func(void *dst, const void *src, size_t n) __attribute__((always_inline)); +#endif /* __DOXYGEN__ */ #endif /* _RTE_MEMCPY_H_ */ -- 2.1.4
[dpdk-dev] [PATCH] doc: add mempool mgr ABI deprication notice
>2016-03-10 13:56, Wiles, Keith: >> >On Thu, Mar 10, 2016 at 01:37:27PM +0100, Olivier MATZ wrote: >> >> Hi David, >> >> >> >> On 03/10/2016 12:55 PM, David Hunt wrote: >> >> > Announce the ABI breakage due to addition of external mempool >> >> > manager functionality which requires changes to rte_mempool >> >> > structure. >> >> > >> >> > Signed-off-by: David Hunt >> >> >> >> Acked-by: Olivier Matz >> >> >> >Acked-by: Bruce Richardson >> >> Asked-by: Keith Wiles > >Is it on purpose, Keith, or a typo? Do you have asked this notice? Sorry, autocorrect :-( Acked-by: Keith Wiles > > Regards, Keith
[dpdk-dev] [PATCH] doc: mempool ABI deprecation notice for 16.07
> >On 4/4/2016 3:38 PM, Thomas Monjalon wrote: >> 2016-03-17 10:05, Olivier Matz: >>> Add a deprecation notice for coming changes in mempool for 16.07. >> [...] >>> +* librte_mempool: new fixes and features will be added in 16.07: >>> + allocation of large mempool in several virtual memory chunks, new API >>> + to populate a mempool, new API to free a mempool, allocation in >>> + anonymous mapping, drop of specific dom0 code. These changes will >>> + induce a modification of the rte_mempool structure, plus a >>> + modification of the API of rte_mempool_obj_iter(), implying a breakage >>> + of the ABI. >> Acked-by: Thomas Monjalon >> >> Other people involved in the discussion wanting to bring their support? > >Acked-by: David Hunt Acked-by: Keith Wiles > > >Regards, >David. > Regards, Keith
[dpdk-dev] DPDK namespace
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon > Sent: Tuesday, April 05, 2016 2:57 PM > To: dev at dpdk.org > Subject: [dpdk-dev] DPDK namespace > > DPDK is going to be more popular in Linux distributions. > It means people will have some DPDK files in their /usr/include and some DPDK > libraries on their system. > > Let's imagine someone trying to compile an application which needs > rte_ethdev.h. He has to figure out that this "rte header" is provided by the > DPDK. > Hopefully it will be explained on StackOverflow that RTE stands for DPDK. > Then someone else will try to run a binary without having installed the DPDK > libraries. The linker will require libethdev.so (no prefix here). > StackOverflow will probably have another good answer (among wrong ones): > "Hey Sherlock Holmes, have you tried to install the DPDK library?" > Followed by an insight: "You know, the DPDK naming is weird..." > And we could continue the story with developers having some naming clash > because of some identifiers not prefixed at all. > > The goal of this email is to get some feedback on how important it is to fix > the > DPDK namespace. > > If there is enough agreement that we should do something, I suggest to > introduce the "dpdk_" prefix slowly and live with both "rte_" and "dpdk_" > during some time. > We could start using the new prefix for the new APIs (example: crypto) or when > there is a significant API break (example: mempool). > > Opinions welcome! I don't have an opinion on how important it is to fix the namespace, though it does seem like a good idea. However if it's to be done, in my opinion it should be completed quickly or will just cause more confusion. So if rte_cryptoxxx becomes dpdk_cryptoxxx all other libraries should follow in next release or two, with the resulting ABI compatibility handling. Maybe with dual naming handled for several releases, but a clear end date when all are converted. Else there will be many years with a mix of rte_ and dpdk_
[dpdk-dev] Change new libraries to have dpdk_ prefix instead of rte_
Thanks for commenting and making the debate alive :) 2016-04-05 14:03, Ananyev, Konstantin: > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Declan Doherty > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > > I think we could change the namespace before making this API stable. > > > What about using a dpdk_ prefix instead of rte_ ? > > > > I'd like people opinion of Thomas proposal to have all new libraries use > > a dpdk_ prefix instead of rte_*. Although I agree that dpdk_ would > > probably make sense, I don't like the ascetics of inconsistent prefixes > > on dpdk libraries. Any comments? > > I suppose it is a bit strange to have rte_ prefix for one set of libraries, > and dpdk_ prefix for others. Don't you think it is strange to have a prefix not related with the public project name? Is it strange to have some functions without any prefix at all? (examples in rte_ether.h) > If we'd decide to change the prefix, then my vote would be to do > that for all dpdk libraries at once. > BTW, why do we need to change it at all? > 'rte_' is probably not the best one, but at least it is well known/used. Well known, really? The question is how large is the audience we target. Please see my other email: http://dpdk.org/ml/archives/dev/2016-April/037048.html
[dpdk-dev] DPDK namespace
On Tue, Apr 5, 2016 at 5:13 PM, Trahe, Fiona wrote: > > > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon > > Sent: Tuesday, April 05, 2016 2:57 PM > > To: dev at dpdk.org > > Subject: [dpdk-dev] DPDK namespace > > > > DPDK is going to be more popular in Linux distributions. > > It means people will have some DPDK files in their /usr/include and some > DPDK > > libraries on their system. > > > > Let's imagine someone trying to compile an application which needs > > rte_ethdev.h. He has to figure out that this "rte header" is provided by > the DPDK. > > Hopefully it will be explained on StackOverflow that RTE stands for DPDK. > > Then someone else will try to run a binary without having installed the > DPDK > > libraries. The linker will require libethdev.so (no prefix here). > > StackOverflow will probably have another good answer (among wrong ones): > > "Hey Sherlock Holmes, have you tried to install the DPDK library?" > > Followed by an insight: "You know, the DPDK naming is weird..." > > And we could continue the story with developers having some naming clash > > because of some identifiers not prefixed at all. > > > > The goal of this email is to get some feedback on how important it is to > fix the > > DPDK namespace. > > > > If there is enough agreement that we should do something, I suggest to > > introduce the "dpdk_" prefix slowly and live with both "rte_" and "dpdk_" > > during some time. > > We could start using the new prefix for the new APIs (example: crypto) > or when > > there is a significant API break (example: mempool). > > > > Opinions welcome! > I don't have an opinion on how important it is to fix the namespace, > though it does seem like a good idea. > However if it's to be done, in my opinion it should be completed quickly > or will just cause more confusion. > So if rte_cryptoxxx becomes dpdk_cryptoxxx all other libraries should > follow in next release or two, with > the resulting ABI compatibility handling. Maybe with dual naming handled > for several releases, but a > clear end date when all are converted. > Else there will be many years with a mix of rte_ and dpdk_ > > Googling rte functions or error codes usually takes you to dpdk dev email archive so I don't think it is that much difficult to figure out where rte comes from. Other than that , except for my own refactoring pains when replacing a dpdk version, I do not see a major reason why not. If Going for dpdk_ prefix, I agree with the quick death approach. /Arnon
[dpdk-dev] DPDK namespace
> -Original Message- > From: Trahe, Fiona > Sent: Tuesday, April 05, 2016 3:13 PM > To: Thomas Monjalon; dev at dpdk.org > Cc: Trahe, Fiona > Subject: RE: [dpdk-dev] DPDK namespace > > > > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon > > Sent: Tuesday, April 05, 2016 2:57 PM > > To: dev at dpdk.org > > Subject: [dpdk-dev] DPDK namespace > > > > DPDK is going to be more popular in Linux distributions. > > It means people will have some DPDK files in their /usr/include and > > some DPDK libraries on their system. > > > > Let's imagine someone trying to compile an application which needs > > rte_ethdev.h. He has to figure out that this "rte header" is provided by the > DPDK. > > Hopefully it will be explained on StackOverflow that RTE stands for DPDK. > > Then someone else will try to run a binary without having installed > > the DPDK libraries. The linker will require libethdev.so (no prefix here). > > StackOverflow will probably have another good answer (among wrong ones): > > "Hey Sherlock Holmes, have you tried to install the DPDK library?" > > Followed by an insight: "You know, the DPDK naming is weird..." > > And we could continue the story with developers having some naming > > clash because of some identifiers not prefixed at all. > > > > The goal of this email is to get some feedback on how important it is > > to fix the DPDK namespace. > > > > If there is enough agreement that we should do something, I suggest to > > introduce the "dpdk_" prefix slowly and live with both "rte_" and "dpdk_" > > during some time. > > We could start using the new prefix for the new APIs (example: crypto) > > or when there is a significant API break (example: mempool). > > > > Opinions welcome! > I don't have an opinion on how important it is to fix the namespace, though it > does seem like a good idea. > However if it's to be done, in my opinion it should be completed quickly or > will > just cause more confusion. > So if rte_cryptoxxx becomes dpdk_cryptoxxx all other libraries should follow > in > next release or two, with the resulting ABI compatibility handling. Maybe with > dual naming handled for several releases, but a clear end date when all are > converted. > Else there will be many years with a mix of rte_ and dpdk_ An alternative: Would it not be better to do this as one specific namespace-change-only release, e.g. an extra 16.06 release, rather than bundling with functional changes?
[dpdk-dev] [PATCH v2] ixgbe: fix occasional timeouts when starting VF
Increase the polling wait time from 10 milleseconds to 15.
Fixes: af75078fece3 ("first public release")
Signed-off-by: Bernard Iremonger
---
Change in v2:
added fixes line
---
drivers/net/ixgbe/ixgbe_rxtx.c | 6 +++---
drivers/net/ixgbe/ixgbe_rxtx.h | 3 ++-
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
index b018ba7..4ad947f 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx.c
+++ b/drivers/net/ixgbe/ixgbe_rxtx.c
@@ -1,7 +1,7 @@
/*-
* BSD LICENSE
*
- * Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
+ * Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
* Copyright 2014 6WIND S.A.
* All rights reserved.
*
@@ -4961,7 +4961,7 @@ ixgbevf_dev_rxtx_start(struct rte_eth_dev *dev)
txdctl |= IXGBE_TXDCTL_ENABLE;
IXGBE_WRITE_REG(hw, IXGBE_VFTXDCTL(i), txdctl);
- poll_ms = 10;
+ poll_ms = RTE_IXGBE_REGISTER_POLL_WAIT_15_MS;
/* Wait until TX Enable ready */
do {
rte_delay_ms(1);
@@ -4979,7 +4979,7 @@ ixgbevf_dev_rxtx_start(struct rte_eth_dev *dev)
IXGBE_WRITE_REG(hw, IXGBE_VFRXDCTL(i), rxdctl);
/* Wait until RX Enable ready */
- poll_ms = 10;
+ poll_ms = RTE_IXGBE_REGISTER_POLL_WAIT_15_MS;
do {
rte_delay_ms(1);
rxdctl = IXGBE_READ_REG(hw, IXGBE_VFRXDCTL(i));
diff --git a/drivers/net/ixgbe/ixgbe_rxtx.h b/drivers/net/ixgbe/ixgbe_rxtx.h
index f9e708f..8085cf4 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx.h
+++ b/drivers/net/ixgbe/ixgbe_rxtx.h
@@ -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
@@ -77,6 +77,7 @@
#endif
#define RTE_IXGBE_REGISTER_POLL_WAIT_10_MS 10
+#define RTE_IXGBE_REGISTER_POLL_WAIT_15_MS 15
#define RTE_IXGBE_WAIT_100_US 100
#define RTE_IXGBE_VMTXSW_REGISTER_COUNT 2
--
2.6.3
[dpdk-dev] [PATCH] doc: mempool ABI deprecation notice for 16.07
> >>> Add a deprecation notice for coming changes in mempool for 16.07. > >> [...] > >>> +* librte_mempool: new fixes and features will be added in 16.07: > >>> + allocation of large mempool in several virtual memory chunks, new API > >>> + to populate a mempool, new API to free a mempool, allocation in > >>> + anonymous mapping, drop of specific dom0 code. These changes will > >>> + induce a modification of the rte_mempool structure, plus a > >>> + modification of the API of rte_mempool_obj_iter(), implying a breakage > >>> + of the ABI. > >> Acked-by: Thomas Monjalon > >> > >> Other people involved in the discussion wanting to bring their support? > > > >Acked-by: David Hunt > > Acked-by: Keith Wiles Applied, thanks
[dpdk-dev] [PATCH v3] PCI: ABI change request for adding new field in rte_pci_id structure
> > The purpose of this patch is used to add a new field > > "class" in rte_pci_id structure. The new class field includes > > class_id, subcalss_id, programming interface of a pci device. > > With this field, we can identify pci device by its class info, > > which can be more flexible instead of probing the device by > > vendor_id OR device_id OR subvendor_id OR subdevice_id. > > For example, we can probe all nvme devices by class field, which > > can be quite convenient. > > > > Signed-off-by: Ziye Yang > > Acked-by: Bruce Richardson > Acked-by: Helin Zhang > Acked-by: Cunming Liang Applied, thanks
[dpdk-dev] [PATCH v2 1/1] cmdline: add any multi string mode to token string
2016-04-05 13:21, Olivier Matz: > > On 04/05/2016 10:47 AM, Piotr Azarewicz wrote: > > While parsing token string there may be several modes: > > - fixed single string > > - multi-choice single string > > - any single string > > > > This patch add one more mode - any multi string. > > > > Signed-off-by: Piotr Azarewicz > > Acked-by: Olivier Matz This patch does not fix anything working currently. As the release is closing in few days, it will be integrated in 16.07. Thanks
[dpdk-dev] [PATCH] doc: announce ABI changes for user-owned mempool caches
On 04/05/2016 11:23 AM, Lazaros Koromilas wrote: > Deprecation notice for 16.04 for changes targeting release 16.07. > The changes affect struct rte_mempool, rte_mempool_cache and the > mempool API. > > Signed-off-by: Lazaros Koromilas Acked-by: Olivier Matz
[dpdk-dev] [PATCH] doc: announce ABI change for rte_port_source_params structure
2016-03-31 14:29, Fan Zhang: > Several new fields will be added to structure rte_port_source_params for > source port enhancement with pcap file reading support. > > Signed-off-by: Fan Zhang > Acked-by: Cristian Dumitrescu Anyone interested or against this ABI break in rte_port? It will be accepted when having 3 acks without any nack.
[dpdk-dev] [PATCH v2] ixgbe: fix occasional timeouts when starting VF
2016-04-05 15:55, Bernard Iremonger: > - poll_ms = 10; > + poll_ms = RTE_IXGBE_REGISTER_POLL_WAIT_15_MS; [...] > #define RTE_IXGBE_REGISTER_POLL_WAIT_10_MS 10 > +#define RTE_IXGBE_REGISTER_POLL_WAIT_15_MS 15 > #define RTE_IXGBE_WAIT_100_US 100 I don't understand why these constants are needed. There is no semantic, just an arbitrary number.
[dpdk-dev] [PATCH v3 0/4] fix creation of duplicate lpm and hash
2016-04-05 13:53, Olivier Matz: > Seen while trying to fix the func_reentrancy autotest. The > series addresses several issues: > > 1/ Hash and lpm return a pointer to an existing object if the user requests > the >creation with an already existing name. This look dangerous: when an object >is returned, the user does not know if it should be freed or not. > > 2/ There is a race condition in cuckoo_hash as the lock is not held in >rte_hash_create(). We could find some cases where NULL is returned when the >object already exists (ex: when rte_ring_create() fails). > > 3/ There is a race condition func_reentrancy that can fail even if the tested >API behaves correctly. Pablo, Bruce, What do you think of these fixes for 16.04?
[dpdk-dev] [PATCH] vhost: Fix retrieval of numa information in PMD
After some testing, it was found that retrieving numa information
about a vhost device via a call to get_mempolicy is more
accurate when performed during the new_device callback versus
the vring_state_changed callback, in particular upon initial boot
of the VM. Performing this check during new_device is also
potentially more efficient as this callback is only triggered once
during device initialisation, compared with vring_state_changed
which may be called multiple times depending on the number of
queues assigned to the device.
Reorganise the code to perform this check and assign the correct
socket_id to the device during the new_device callback.
Signed-off-by: Ciara Loftus
---
drivers/net/vhost/rte_eth_vhost.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/net/vhost/rte_eth_vhost.c
b/drivers/net/vhost/rte_eth_vhost.c
index 4cc6bec..b1eb082 100644
--- a/drivers/net/vhost/rte_eth_vhost.c
+++ b/drivers/net/vhost/rte_eth_vhost.c
@@ -229,6 +229,9 @@ new_device(struct virtio_net *dev)
struct pmd_internal *internal;
struct vhost_queue *vq;
unsigned i;
+#ifdef RTE_LIBRTE_VHOST_NUMA
+ int newnode, ret;
+#endif
if (dev == NULL) {
RTE_LOG(INFO, PMD, "Invalid argument\n");
@@ -244,6 +247,17 @@ new_device(struct virtio_net *dev)
eth_dev = list->eth_dev;
internal = eth_dev->data->dev_private;
+#ifdef RTE_LIBRTE_VHOST_NUMA
+ ret = get_mempolicy(&newnode, NULL, 0, dev,
+ MPOL_F_NODE | MPOL_F_ADDR);
+ if (ret < 0) {
+ RTE_LOG(ERR, PMD, "Unknown numa node\n");
+ return -1;
+ }
+
+ eth_dev->data->numa_node = newnode;
+#endif
+
for (i = 0; i < eth_dev->data->nb_rx_queues; i++) {
vq = eth_dev->data->rx_queues[i];
if (vq == NULL)
@@ -352,9 +366,6 @@ vring_state_changed(struct virtio_net *dev, uint16_t vring,
int enable)
struct rte_vhost_vring_state *state;
struct rte_eth_dev *eth_dev;
struct internal_list *list;
-#ifdef RTE_LIBRTE_VHOST_NUMA
- int newnode, ret;
-#endif
if (dev == NULL) {
RTE_LOG(ERR, PMD, "Invalid argument\n");
@@ -370,17 +381,6 @@ vring_state_changed(struct virtio_net *dev, uint16_t
vring, int enable)
eth_dev = list->eth_dev;
/* won't be NULL */
state = vring_states[eth_dev->data->port_id];
-
-#ifdef RTE_LIBRTE_VHOST_NUMA
- ret = get_mempolicy(&newnode, NULL, 0, dev,
- MPOL_F_NODE | MPOL_F_ADDR);
- if (ret < 0) {
- RTE_LOG(ERR, PMD, "Unknown numa node\n");
- return -1;
- }
-
- eth_dev->data->numa_node = newnode;
-#endif
rte_spinlock_lock(&state->lock);
state->cur[vring] = enable;
state->max_vring = RTE_MAX(vring, state->max_vring);
--
2.4.3
[dpdk-dev] Change new libraries to have dpdk_ prefix instead of rte_
> >> -Original Message- >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Declan Doherty >> Sent: Tuesday, April 05, 2016 2:29 PM >> To: dev at dpdk.org >> Subject: [dpdk-dev] Change new libraries to have dpdk_ prefix instead of rte_ >> >> I'd like people opinion of Thomas proposal to have all new libraries use >> a dpdk_ prefix instead of rte_*. Although I agree that dpdk_ would >> probably make sense, I don't like the ascetics of inconsistent prefixes >> on dpdk libraries. Any comments? > >I suppose it is a bit strange to have rte_ prefix for one set of libraries, >and dpdk_ prefix for others. >If we'd decide to change the prefix, then my vote would be to do >that for all dpdk libraries at once. >BTW, why do we need to change it at all? >'rte_' is probably not the best one, but at least it is well known/used. >Konstantin I agree with Thomas as a Type One like person I would like to change it too, but think Konstantin?s point is very valid and we do not need to change existing APIs. I could live with changing the new libraries only, but then we get into the multiple prefixes problem :-( > > >> >> >> >> >> 2016-04-05 09:48, Trahe, Fiona: >> > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] >> > > 2016-04-05 08:53, Fiona Trahe: >> > > > The cryptodev API was introduced in the DPDK 2.2 release. >> > > > Since then it has >> > > > - been reviewed and iterated for the DPDK 16.04 release >> > > > - had extensive use by the l2fwd-crypto app, >> > > >the ipsec-secgw example app, >> > > >the test app. >> > > > We believe it is now stable and the EXPERIMENTAL label should be >> > > > removed. >> > > >> > > Are you sure sure? :) >> > > It means you will try hard to not change the API anymore or you'll need a >> > > deprecation notice strongly agreed (outside of your team). >> > >> > We're sure sure :) >> >> I think we could change the namespace before making this API stable. >> What about using a dpdk_ prefix instead of rte_ ? >> (and some macros have CRYPTODEV or CDEV prefixes) >> > > Regards, Keith
[dpdk-dev] [PATCH] doc: announce xstats api change for 16.07
This patch adds a notice that the API for the xstats functionality will be modified in the 16.07 release, with no backwards compatibility planned as it would require code duplication in each PMD that supports xstats. Signed-off-by: Harry van Haaren --- doc/guides/rel_notes/deprecation.rst | 5 + 1 file changed, 5 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index 98d5529..13c3a95 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -54,3 +54,8 @@ Deprecation Notices induce a modification of the rte_mempool structure, plus a modification of the API of rte_mempool_obj_iter(), implying a breakage of the ABI. + +* ABI change is planned for the xstats API and rte_eth_xstats struct, to + facilitate updating to an API that allows retrieval of values without any + string copies or parsing. No backwards compatibility is planned, as it would + require code duplication in every PMD that supports xstats. -- 2.5.0
[dpdk-dev] [PATCH] doc: add enic features to nic features matrix
Signed-off-by: John Daley --- doc/guides/nics/overview.rst | 38 +++--- 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/doc/guides/nics/overview.rst b/doc/guides/nics/overview.rst index ec1af46..f3d374b 100644 --- a/doc/guides/nics/overview.rst +++ b/doc/guides/nics/overview.rst @@ -87,27 +87,27 @@ Most of these differences are summarized below. c c c c c c = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = speed capabilities - link status X X X X X X X + link status X X X X X X X X link status eventX X X X X queue status event X Rx interrupt X X X X - queue start/stop X X X X X X X X X + queue start/stop X X X X X X X X X X MTU update X X X X - jumbo frame X X X X X X X X + jumbo frame X X X X X X X X X scattered Rx X X X X X X X X X LRO TSO X X X X X X - promiscuous mode X X X X X X X X + promiscuous mode X X X X X X X X X allmulticast modeX X X X X X X X - unicast MAC filter X X X X - multicast MAC filter X X X X - RSS hash X X X X X X X X + unicast MAC filter X X X X X + multicast MAC filter X X X X X + RSS hash X X X X X X X X X RSS key update X X X X X X RSS reta update X X X X X X VMDq X X SR-IOV X X X X X DCB X X - VLAN filter X X X X X X + VLAN filterX X X X X X X ethertype filter X X n-tuple filter SYN filter @@ -118,31 +118,31 @@ Most of these differences are summarized below. flow control X X X rate limitation traffic mirroringX X - CRC offload X X X X X - VLAN offload X X X X X + CRC offload X X X X X X + VLAN offload X X X X X X QinQ offload X X - L3 checksum offload X X X X X X - L4 checksum offload X X X X X X + L3 checksum offload X X X X X X X + L4 checksum offload X X X X X X X inner L3 checksumX X X X inner L4 checksumX X X X - packet type parsing X X X X X + packet type parsing X X X X X X timesync X X - basic stats X X X X X X X X X X + basic stats X X X X X X X X X X X extended stats X X X X X stats per queue X X X X EEPROM dump registers dump multiprocess aware X X X X X X - BSD nic_uio X X X X X - Linux UIOX X X X X X - Linux VFIO X X X X X + BSD nic_uio X X X X X X + Linux UIOX X X X X X X + Linux VFIO X X X X X X other kdrv X ARMv7 ARMv8 Power8 X X TILE-Gx - x86-32 X X X X X X X X X - x86-64 X X X X X X X X X X + x86-32 X X X X X X X X X X + x86-64 X X X X X X X X X X X usage docX X X X design doc perf
[dpdk-dev] [PATCH] doc: announce xstats api change for 16.07
2016-04-05 18:58, Harry van Haaren: > +* ABI change is planned for the xstats API and rte_eth_xstats struct, to > + facilitate updating to an API that allows retrieval of values without any > + string copies or parsing. No backwards compatibility is planned, as it > would > + require code duplication in every PMD that supports xstats. Have you already submitted a RFC patch to let us have an opinion on the change? We need, at least, to see the structure changes. Thanks
[dpdk-dev] [dpdk-dev, 07/10] lib: fix missing include dependencies
Hello Adrien,
just quickly skimming through the ARM fixes...
On Tue, 5 Apr 2016 16:08:07 +0200
Adrien Mazarguil wrote:
> Exported header files for use by applications should be self sufficient and
> allow out of order inclusion. Moreover, they must include all the system
> headers they need for types and macros.
>
> This commit prevents the following errors:
>
> error: `RTE_MAX_LCORE' undeclared here (not in a function)
> error: `RTE_LPM_VALID_EXT_ENTRY_BITMASK' undeclared (first use in this
> function)
> error: #error "Unsupported cache line size"
> error: `asm' undeclared (first use in this function)
> error: implicit declaration of function `[...]'
> error: unknown type name `[...]'
> error: field `mac_addr' has incomplete type
> error: `CHAR_BIT' undeclared here (not in a function)
> error: `struct timespec' declared inside parameter list
>
> Signed-off-by: Adrien Mazarguil
>
> ---
[...]
> +
> #ifdef __cplusplus
> extern "C" {
> #endif
> diff --git a/lib/librte_eal/common/include/arch/arm/rte_byteorder.h
> b/lib/librte_eal/common/include/arch/arm/rte_byteorder.h
> index 3f2dd1f..c2078e7 100644
> --- a/lib/librte_eal/common/include/arch/arm/rte_byteorder.h
> +++ b/lib/librte_eal/common/include/arch/arm/rte_byteorder.h
> @@ -37,6 +37,9 @@
> # error Platform must be built with CONFIG_RTE_FORCE_INTRINSICS
> #endif
>
> +#include
> +#include
Why not to place it into the extern "C" { block? There is already:
#include "generic/rte_byteorder.h"
> +
> #ifdef __cplusplus
> extern "C" {
> #endif
> diff --git a/lib/librte_eal/common/include/arch/arm/rte_prefetch_32.h
> b/lib/librte_eal/common/include/arch/arm/rte_prefetch_32.h
> index 5aeed22..29b831b 100644
> --- a/lib/librte_eal/common/include/arch/arm/rte_prefetch_32.h
> +++ b/lib/librte_eal/common/include/arch/arm/rte_prefetch_32.h
> @@ -33,6 +33,8 @@
> #ifndef _RTE_PREFETCH_ARM32_H_
> #define _RTE_PREFETCH_ARM32_H_
>
> +#include
I don't see any reason for this. The header does not use anything
special. Just "asm", but that should be a keyword...
> +
> #ifdef __cplusplus
> extern "C" {
> #endif
> diff --git a/lib/librte_eal/common/include/arch/arm/rte_prefetch_64.h
> b/lib/librte_eal/common/include/arch/arm/rte_prefetch_64.h
> index 3ed46a4..600c6f0 100644
> --- a/lib/librte_eal/common/include/arch/arm/rte_prefetch_64.h
> +++ b/lib/librte_eal/common/include/arch/arm/rte_prefetch_64.h
> @@ -33,6 +33,8 @@
> #ifndef _RTE_PREFETCH_ARM_64_H_
> #define _RTE_PREFETCH_ARM_64_H_
>
> +#include
Same here.
> +
> #ifdef __cplusplus
> extern "C" {
> #endif
> diff --git a/lib/librte_eal/common/include/arch/arm/rte_vect.h
> b/lib/librte_eal/common/include/arch/arm/rte_vect.h
> index a33c054..b86c2cf 100644
> --- a/lib/librte_eal/common/include/arch/arm/rte_vect.h
> +++ b/lib/librte_eal/common/include/arch/arm/rte_vect.h
> @@ -33,6 +33,7 @@
> #ifndef _RTE_VECT_ARM_H_
> #define _RTE_VECT_ARM_H_
>
> +#include
> #include "arm_neon.h"
>
> #ifdef __cplusplus
[...]
Regards
Jan
[dpdk-dev] [PATCH] doc: announce ABI change for rte_port_source_params structure
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Fan Zhang > Sent: Thursday, March 31, 2016 2:29 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH] doc: announce ABI change for > rte_port_source_params structure > > Several new fields will be added to structure rte_port_source_params for > source port enhancement with pcap file reading support. > > Signed-off-by: Fan Zhang > Acked-by: Cristian Dumitrescu Acked-by: Jasvinder Singh
[dpdk-dev] [PATCH v3 1/4] bnx2x: Update documentation
Signed-off-by: Harish Patil Signed-off-by: Rasesh Mody --- doc/guides/nics/bnx2x.rst|1 + doc/guides/nics/overview.rst | 22 +++--- 2 files changed, 12 insertions(+), 11 deletions(-) diff --git a/doc/guides/nics/bnx2x.rst b/doc/guides/nics/bnx2x.rst index ed0e5e5..df8fb47 100644 --- a/doc/guides/nics/bnx2x.rst +++ b/doc/guides/nics/bnx2x.rst @@ -60,6 +60,7 @@ The features not yet supported include: - LRO/TSO offload - Checksum offload - SR-IOV PF +- Rx TX scatter gather Co-existence considerations --- diff --git a/doc/guides/nics/overview.rst b/doc/guides/nics/overview.rst index ec1af46..482a59c 100644 --- a/doc/guides/nics/overview.rst +++ b/doc/guides/nics/overview.rst @@ -87,8 +87,8 @@ Most of these differences are summarized below. c c c c c c = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = speed capabilities - link status X X X X X X X - link status eventX X X X X + link statusX X X X X X X X X + link status event X X X X X X X queue status event X Rx interrupt X X X X queue start/stop X X X X X X X X X @@ -97,15 +97,15 @@ Most of these differences are summarized below. scattered Rx X X X X X X X X X LRO TSO X X X X X X - promiscuous mode X X X X X X X X + promiscuous mode X X X X X X X X X X allmulticast modeX X X X X X X X - unicast MAC filter X X X X - multicast MAC filter X X X X + unicast MAC filter X X X X X X + multicast MAC filter X X X X X X RSS hash X X X X X X X X RSS key update X X X X X X RSS reta update X X X X X X VMDq X X - SR-IOV X X X X X + SR-IOV X X X X X X DCB X X VLAN filter X X X X X X ethertype filter X X @@ -127,14 +127,14 @@ Most of these differences are summarized below. inner L4 checksumX X X X packet type parsing X X X X X timesync X X - basic stats X X X X X X X X X X - extended stats X X X X X + basic statsX X X X X X X X X X X X + extended stats X X X X X X X stats per queue X X X X EEPROM dump registers dump multiprocess aware X X X X X X BSD nic_uio X X X X X - Linux UIOX X X X X X + Linux UIO X X X X X X X X Linux VFIO X X X X X other kdrv X ARMv7 @@ -142,8 +142,8 @@ Most of these differences are summarized below. Power8 X X TILE-Gx x86-32 X X X X X X X X X - x86-64 X X X X X X X X X X - usage docX X X X + x86-64 X X X X X X X X X X X X + usage doc X X X X X X design doc perf doc = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -- 1.7.10.3
[dpdk-dev] [PATCH v3 2/4] bnx2x: Fix Tx Performance
Change the Tx routine logic to ring the doorbell once per burst and not
on every Tx packet. This driver-level optimization is necessary to achieve
line rates for larger frame sizes (1k or more).
Fixes: 540a211084a7 ("bnx2x: driver core")
Signed-off-by: Harish Patil
Signed-off-by: Rasesh Mody
---
drivers/net/bnx2x/bnx2x.c | 207 ++--
drivers/net/bnx2x/bnx2x.h |4 +-
drivers/net/bnx2x/bnx2x_rxtx.c | 45 -
3 files changed, 118 insertions(+), 138 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x.c b/drivers/net/bnx2x/bnx2x.c
index 6edb2f9..149fdef 100644
--- a/drivers/net/bnx2x/bnx2x.c
+++ b/drivers/net/bnx2x/bnx2x.c
@@ -1293,7 +1293,7 @@ bnx2x_free_tx_pkt(__rte_unused struct bnx2x_fastpath *fp,
struct bnx2x_tx_queue
struct rte_mbuf *tx_mbuf = txq->sw_ring[TX_BD(pkt_idx, txq)];
if (likely(tx_mbuf != NULL)) {
- rte_pktmbuf_free(tx_mbuf);
+ rte_pktmbuf_free_seg(tx_mbuf);
} else {
PMD_RX_LOG(ERR, "fp[%02d] lost mbuf %lu",
fp->index, (unsigned long)TX_BD(pkt_idx, txq));
@@ -2113,147 +2113,128 @@ bnx2x_nic_unload(struct bnx2x_softc *sc, uint32_t
unload_mode, uint8_t keep_link
* the mbuf and return to the caller.
*
* Returns:
- * 0 = Success, !0 = Failure
+ * Number of TX BDs used for the mbuf
* Note the side effect that an mbuf may be freed if it causes a problem.
*/
-int bnx2x_tx_encap(struct bnx2x_tx_queue *txq, struct rte_mbuf **m_head, int
m_pkts)
+uint32_t
+bnx2x_tx_encap(struct bnx2x_tx_queue *txq, struct rte_mbuf *m0)
{
- struct rte_mbuf *m0;
struct eth_tx_start_bd *tx_start_bd;
uint16_t bd_prod, pkt_prod;
- int m_tx;
struct bnx2x_softc *sc;
uint32_t nbds = 0;
- struct bnx2x_fastpath *fp;
sc = txq->sc;
- fp = &sc->fp[txq->queue_id];
bd_prod = txq->tx_bd_tail;
pkt_prod = txq->tx_pkt_tail;
- for (m_tx = 0; m_tx < m_pkts; m_tx++) {
+ txq->sw_ring[TX_BD(pkt_prod, txq)] = m0;
- m0 = *m_head++;
+ tx_start_bd = &txq->tx_ring[TX_BD(bd_prod, txq)].start_bd;
- if (unlikely(txq->nb_tx_avail < 3)) {
- PMD_TX_LOG(ERR, "no enough bds %d/%d",
- bd_prod, txq->nb_tx_avail);
- return -ENOMEM;
- }
+ tx_start_bd->addr =
+ rte_cpu_to_le_64(rte_mbuf_data_dma_addr(m0));
+ tx_start_bd->nbytes = rte_cpu_to_le_16(m0->data_len);
+ tx_start_bd->bd_flags.as_bitfield = ETH_TX_BD_FLAGS_START_BD;
+ tx_start_bd->general_data =
+ (1 << ETH_TX_START_BD_HDR_NBDS_SHIFT);
- txq->sw_ring[TX_BD(pkt_prod, txq)] = m0;
+ tx_start_bd->nbd = rte_cpu_to_le_16(2);
- tx_start_bd = &txq->tx_ring[TX_BD(bd_prod, txq)].start_bd;
-
- tx_start_bd->addr =
- rte_cpu_to_le_64(rte_mbuf_data_dma_addr(m0));
- tx_start_bd->nbytes = rte_cpu_to_le_16(m0->data_len);
- tx_start_bd->bd_flags.as_bitfield = ETH_TX_BD_FLAGS_START_BD;
- tx_start_bd->general_data =
- (1 << ETH_TX_START_BD_HDR_NBDS_SHIFT);
-
- tx_start_bd->nbd = rte_cpu_to_le_16(2);
+ if (m0->ol_flags & PKT_TX_VLAN_PKT) {
+ tx_start_bd->vlan_or_ethertype =
+ rte_cpu_to_le_16(m0->vlan_tci);
+ tx_start_bd->bd_flags.as_bitfield |=
+ (X_ETH_OUTBAND_VLAN <<
+ETH_TX_BD_FLAGS_VLAN_MODE_SHIFT);
+ } else {
+ if (IS_PF(sc))
+ tx_start_bd->vlan_or_ethertype =
+ rte_cpu_to_le_16(pkt_prod);
+ else {
+ struct ether_hdr *eh =
+ rte_pktmbuf_mtod(m0, struct ether_hdr *);
- if (m0->ol_flags & PKT_TX_VLAN_PKT) {
tx_start_bd->vlan_or_ethertype =
- rte_cpu_to_le_16(m0->vlan_tci);
- tx_start_bd->bd_flags.as_bitfield |=
- (X_ETH_OUTBAND_VLAN <<
-ETH_TX_BD_FLAGS_VLAN_MODE_SHIFT);
- } else {
- if (IS_PF(sc))
- tx_start_bd->vlan_or_ethertype =
- rte_cpu_to_le_16(pkt_prod);
- else {
- struct ether_hdr *eh
- = rte_pktmbuf_mtod(m0, struct ether_hdr *);
-
- tx_start_bd->vlan_or_ethertype
- =
rte_cpu_to_le_16(rte_be_to_cpu_16(eh->ether_type));
- }
+rte_cpu_to_le_16(rte_be_to_cpu_16(eh->ether_type));
}
+ }
- bd_prod = NEXT_TX_BD(bd_prod);
- if (IS_VF(sc)) {
-
[dpdk-dev] [PATCH v3 3/4] bnx2x: Enhance stats get
Enhance the stats_get() routine to display drop counters under
imissed counter.
Added extended stats get support to provide additional info.
Signed-off-by: Rasesh Mody
---
drivers/net/bnx2x/bnx2x_ethdev.c | 72 ++
drivers/net/bnx2x/bnx2x_rxtx.c |2 ++
2 files changed, 74 insertions(+)
diff --git a/drivers/net/bnx2x/bnx2x_ethdev.c b/drivers/net/bnx2x/bnx2x_ethdev.c
index 071b44f..1f38f6d 100644
--- a/drivers/net/bnx2x/bnx2x_ethdev.c
+++ b/drivers/net/bnx2x/bnx2x_ethdev.c
@@ -276,6 +276,9 @@ static void
bnx2x_dev_stats_get(struct rte_eth_dev *dev, struct rte_eth_stats *stats)
{
struct bnx2x_softc *sc = dev->data->dev_private;
+ uint32_t brb_truncate_discard;
+ uint64_t brb_drops;
+ uint64_t brb_truncates;
PMD_INIT_FUNC_TRACE();
@@ -316,6 +319,73 @@ bnx2x_dev_stats_get(struct rte_eth_dev *dev, struct
rte_eth_stats *stats)
stats->rx_nombuf =
HILO_U64(sc->eth_stats.no_buff_discard_hi,
sc->eth_stats.no_buff_discard_lo);
+
+ brb_drops =
+ HILO_U64(sc->eth_stats.brb_drop_hi,
+sc->eth_stats.brb_drop_lo);
+
+ brb_truncates =
+ HILO_U64(sc->eth_stats.brb_truncate_hi,
+sc->eth_stats.brb_truncate_lo);
+
+ brb_truncate_discard = sc->eth_stats.brb_truncate_discard;
+
+ stats->imissed = brb_drops + brb_truncates +
+brb_truncate_discard + stats->rx_nombuf;
+}
+
+#define BNX2X_EXTENDED_STATS 9
+
+static int
+bnx2x_dev_xstats_get(struct rte_eth_dev *dev, struct rte_eth_xstats *xstats,
+unsigned n)
+{
+ struct bnx2x_softc *sc = dev->data->dev_private;
+ unsigned num = BNX2X_EXTENDED_STATS;
+
+ if (n < num)
+ return num;
+
+ num = 0;
+
+ bnx2x_stats_handle(sc, STATS_EVENT_UPDATE);
+
+ snprintf(xstats[num].name, sizeof(xstats[num].name), "brb_drops");
+ xstats[num++].value = HILO_U64(sc->eth_stats.brb_drop_hi,
+ sc->eth_stats.brb_drop_lo);
+
+ snprintf(xstats[num].name, sizeof(xstats[num].name), "brb_truncates");
+ xstats[num++].value = HILO_U64(sc->eth_stats.brb_truncate_hi,
+ sc->eth_stats.brb_truncate_lo);
+
+ snprintf(xstats[num].name, sizeof(xstats[num].name),
+"brb_truncate_discard");
+ xstats[num++].value = sc->eth_stats.brb_truncate_discard;
+
+ snprintf(xstats[num].name, sizeof(xstats[num].name),
+"mac_filter_discard");
+ xstats[num++].value = sc->eth_stats.mac_filter_discard;
+
+ snprintf(xstats[num].name, sizeof(xstats[num].name), "mf_tag_discard");
+ xstats[num++].value = sc->eth_stats.mf_tag_discard;
+
+ snprintf(xstats[num].name, sizeof(xstats[num].name), "tx_pause");
+ xstats[num++].value = HILO_U64(sc->eth_stats.pause_frames_sent_hi,
+ sc->eth_stats.pause_frames_sent_lo);
+
+ snprintf(xstats[num].name, sizeof(xstats[num].name), "rx_pause");
+ xstats[num++].value = HILO_U64(sc->eth_stats.pause_frames_received_hi,
+ sc->eth_stats.pause_frames_received_lo);
+
+ snprintf(xstats[num].name, sizeof(xstats[num].name), "tx_pfc");
+ xstats[num++].value = HILO_U64(sc->eth_stats.pfc_frames_sent_hi,
+ sc->eth_stats.pfc_frames_sent_lo);
+
+ snprintf(xstats[num].name, sizeof(xstats[num].name), "rx_pfc");
+ xstats[num++].value = HILO_U64(sc->eth_stats.pfc_frames_received_hi,
+ sc->eth_stats.pfc_frames_received_lo);
+
+ return num;
}
static void
@@ -360,6 +430,7 @@ static const struct eth_dev_ops bnx2x_eth_dev_ops = {
.allmulticast_disable = bnx2x_dev_allmulticast_disable,
.link_update = bnx2x_dev_link_update,
.stats_get= bnx2x_dev_stats_get,
+ .xstats_get = bnx2x_dev_xstats_get,
.dev_infos_get= bnx2x_dev_infos_get,
.rx_queue_setup = bnx2x_dev_rx_queue_setup,
.rx_queue_release = bnx2x_dev_rx_queue_release,
@@ -383,6 +454,7 @@ static const struct eth_dev_ops bnx2xvf_eth_dev_ops = {
.allmulticast_disable = bnx2x_dev_allmulticast_disable,
.link_update = bnx2xvf_dev_link_update,
.stats_get= bnx2x_dev_stats_get,
+ .xstats_get = bnx2x_dev_xstats_get,
.dev_infos_get= bnx2x_dev_infos_get,
.rx_queue_setup = bnx2x_dev_rx_queue_setup,
.rx_queue_release = bnx2x_dev_rx_queue_release,
diff --git a/drivers/net/bnx2x/bnx2x_rxtx.c b/drivers/net/bnx2x/bnx2x_rxtx.c
index 8b047d4..60bd08b 100644
--- a/drivers/net/bnx2x/bnx2x_rxtx.c
+++ b/drivers/ne
[dpdk-dev] [PATCH v3 4/4] bnx2x: Update PMD version to 1.0.1.1
Signed-off-by: Rasesh Mody
---
drivers/net/bnx2x/bnx2x.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x.c b/drivers/net/bnx2x/bnx2x.c
index 149fdef..dcd21f8 100644
--- a/drivers/net/bnx2x/bnx2x.c
+++ b/drivers/net/bnx2x/bnx2x.c
@@ -32,18 +32,20 @@
#define BNX2X_PMD_VER_PREFIX "BNX2X PMD"
#define BNX2X_PMD_VERSION_MAJOR 1
#define BNX2X_PMD_VERSION_MINOR 0
-#define BNX2X_PMD_VERSION_PATCH 0
+#define BNX2X_PMD_VERSION_REVISION 1
+#define BNX2X_PMD_VERSION_PATCH 1
static inline const char *
bnx2x_pmd_version(void)
{
static char version[32];
- snprintf(version, sizeof(version), "%s %s_%d.%d.%d",
+ snprintf(version, sizeof(version), "%s %s_%d.%d.%d.%d",
BNX2X_PMD_VER_PREFIX,
BNX2X_DRIVER_VERSION,
BNX2X_PMD_VERSION_MAJOR,
BNX2X_PMD_VERSION_MINOR,
+ BNX2X_PMD_VERSION_REVISION,
BNX2X_PMD_VERSION_PATCH);
return version;
--
1.7.10.3
[dpdk-dev] ovs crash when running traffic from VM to VM over DPDK and vhostuser
This OVS crash was first sent to openvswitch bug report mailing list, but it was suggested it is posted to dpdk as crash is in netdev code. What you did that make the problem appear. - We have an openstack kilo setup. it has 3 controllers and 3 computes. 1 of the controllers runs an ODL, which manages the OVS on each compute host. The compute hosts are running an hlinux OS, which is HPE's Debian8-based OS. each host has 2 numa nodes, each with 12 cores (24 Hyper Threaded). each numa with 64GB. We patched neutron to create vhostuser ports (which is not available in stable kilo), in order to work with dpdk in order to achieve highest throughput possible. OVS was running with "-c 4" and pmd-core-mask 0x38. all these cores were isolated. nova was configured with vcpu_pin_set=6-11, and the flavor had 6 vCPUs. flavor had 16 1GB huge pages, backed up by real 1GB huge pages in host. Then running a traffic generator inside 2 VMs, using DPDK, in order to generate traffic. sending directly to the other VMs mac and IP. - What you expected to happen. We expected traffic to flow. - What actually happened. OVS crashed (in dpdk code). Attached BT. - The Open vSwitch version number (as output by?ovs-vswitchd --version) root at BASE-CCP-CPN-N0001-NETCLM:~# ovs-vswitchd --version ovs-vswitchd (Open vSwitch) 2.5.0 Compiled Apr? 4 2016 08:51:09 - Any local patches or changes you have applied (if any). applied ce179f1163f947fe8dc5afa35a2cdd0756bb53a0 The following are also handy sometimes: - The kernel version on which Open vSwitch is running (from?/proc/version) and the distribution and version number of your OS (e.g. "Centos 5.0"). root at BASE-CCP-CPN-N0001-NETCLM:~# cat /proc/version Linux version 3.14.48-1-amd64-hlinux (pbuilder at build) (gcc version 4.9.2 (Debian 4.9.2-10) ) #hlinux1 SMP Thu Aug 6 16:02:22 UTC 2015 - If you have Open vSwitch configured to connect to an OpenFlow controller, the output of?ovs-ofctl show ?for each??configured in the vswitchd configuration database. We are using odl. attached outputs. - A fix or workaround, if you have one We disabled mrg_rxbuf (mrg_rxbuf=off) in qemu We can supply more info if necessary, like our exact build process etc. -- next part -- An embedded and charset-unspecified text was scrubbed... Name: ovs-ofctl.txt URL: <http://dpdk.org/ml/archives/dev/attachments/20160405/fc6860eb/attachment-0002.txt> -- next part -- An embedded and charset-unspecified text was scrubbed... Name: ovs-vswitchd-gdb.txt URL: <http://dpdk.org/ml/archives/dev/attachments/20160405/fc6860eb/attachment-0003.txt>
