Re: [dpdk-dev] [PATCH] examples/l3fwd: support separate buffer pool per port
Hi Shreyansh, > -Original Message- > From: Shreyansh Jain > Sent: Monday, April 15, 2019 14:48 > To: Ruifeng Wang (Arm Technology China) ; > Ananyev, Konstantin ; dev@dpdk.org > Cc: nd ; nd > Subject: RE: [dpdk-dev] [PATCH] examples/l3fwd: support separate buffer > pool per port > > Hi Ruifeng, > > [...] > > > > > > > For hardware backed pools, hardware access and exclusion are > > expensive. By > > > segregating pool/port/lcores it is possible to attain a conflict free > > path. This is > > > the use-case this patch targets. > > > And anyways, this is an optional feature. > > > > > > > Konstantin > > > > > > > > > In dual core test, both modes had nearly same performance. > > > > > > OK > > > > > > > > > > > > > My setup only has two ports which is limited. > > > > > Just want to know the per-port-pool mode has more performance > gain > > > > when many ports are bound to different cores? > > > > > > Yes, though not necessarily *many* - in my case, I had 4 ports and > > even then > > > about ~10% improvement was directly visible. I increased the port > > count and > > > I was able to touch about ~15%. I did pin each port to a separate > > core, though. > > > But again, important point is that without this feature enabled, I > > didn't see > > > any drop in performance. Did you observe any drop? > > > > > > > No, no drop without the feature enabled in my test. > > So, in case this is an optional feature, it should be fine, right? > (Obviously, assuming that my logical implementation is correct) > > At my end also, I saw no drop in performance without this feature (Default) > and a decent increase with this (with separate port-core combination) on > NXP platform. > > [...] Tested on LS2088A and observed 12% performance gain when 4 ports were used. I think sample_app_ug document should be updated to add the new option. Acked-by: Ruifeng Wang Regards, /Ruifeng
Re: [dpdk-dev] [PATCH 1/6] net/bnx2x: fix eth dev MTU
On 4/12/2019 2:47 AM, Rasesh Mody wrote:
> Fix to update eth dev MTU for jumbo frames
>
> Fixes: 540a211084a7 ("bnx2x: driver core")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Rasesh Mody
Series applied to dpdk-next-net/master, thanks.
[dpdk-dev] [PATCH 0/3] net/ifc: SW relay improvement and fix
This patch set removes unnecessary relay on Tx queue and fixes 2 bugs to improve stability. Xiao Wang (3): net/ifc: do not relay for Tx queue net/ifc: fix mediated vring initialization net/ifc: fix used ring update drivers/net/ifc/ifcvf_vdpa.c | 104 --- 1 file changed, 57 insertions(+), 47 deletions(-) -- 2.15.1
[dpdk-dev] [PATCH 1/3] net/ifc: do not relay for Tx queue
Relay for Tx queue doesn't provide any benefit, since the packet buffer
in Tx queue is read-only, there's no dirty page logging for Tx buffer.
This change further reduces CPU usage and improves throughput.
Signed-off-by: Xiao Wang
---
drivers/net/ifc/ifcvf_vdpa.c | 88 +++-
1 file changed, 46 insertions(+), 42 deletions(-)
diff --git a/drivers/net/ifc/ifcvf_vdpa.c b/drivers/net/ifc/ifcvf_vdpa.c
index 921a7e058..619cdc245 100644
--- a/drivers/net/ifc/ifcvf_vdpa.c
+++ b/drivers/net/ifc/ifcvf_vdpa.c
@@ -66,6 +66,8 @@ struct ifcvf_internal {
bool sw_fallback_running;
/* mediated vring for sw fallback */
struct vring m_vring[IFCVF_MAX_QUEUES * 2];
+ /* eventfd for used ring interrupt */
+ int intr_fd[IFCVF_MAX_QUEUES * 2];
};
struct internal_list {
@@ -334,7 +336,7 @@ vdpa_ifcvf_stop(struct ifcvf_internal *internal)
#define MSIX_IRQ_SET_BUF_LEN (sizeof(struct vfio_irq_set) + \
sizeof(int) * (IFCVF_MAX_QUEUES * 2 + 1))
static int
-vdpa_enable_vfio_intr(struct ifcvf_internal *internal)
+vdpa_enable_vfio_intr(struct ifcvf_internal *internal, bool m_rx)
{
int ret;
uint32_t i, nr_vring;
@@ -342,6 +344,7 @@ vdpa_enable_vfio_intr(struct ifcvf_internal *internal)
struct vfio_irq_set *irq_set;
int *fd_ptr;
struct rte_vhost_vring vring;
+ int fd;
nr_vring = rte_vhost_get_vring_num(internal->vid);
@@ -355,9 +358,22 @@ vdpa_enable_vfio_intr(struct ifcvf_internal *internal)
fd_ptr = (int *)&irq_set->data;
fd_ptr[RTE_INTR_VEC_ZERO_OFFSET] = internal->pdev->intr_handle.fd;
+ for (i = 0; i < nr_vring; i++)
+ internal->intr_fd[i] = -1;
+
for (i = 0; i < nr_vring; i++) {
rte_vhost_get_vhost_vring(internal->vid, i, &vring);
fd_ptr[RTE_INTR_VEC_RXTX_OFFSET + i] = vring.callfd;
+ if ((i & 1) == 0 && m_rx == true) {
+ fd = eventfd(0, EFD_NONBLOCK | EFD_CLOEXEC);
+ if (fd < 0) {
+ DRV_LOG(ERR, "can't setup eventfd: %s",
+ strerror(errno));
+ return -1;
+ }
+ internal->intr_fd[i] = fd;
+ fd_ptr[RTE_INTR_VEC_RXTX_OFFSET + i] = fd;
+ }
}
ret = ioctl(internal->vfio_dev_fd, VFIO_DEVICE_SET_IRQS, irq_set);
@@ -374,6 +390,7 @@ static int
vdpa_disable_vfio_intr(struct ifcvf_internal *internal)
{
int ret;
+ uint32_t i, nr_vring;
char irq_set_buf[MSIX_IRQ_SET_BUF_LEN];
struct vfio_irq_set *irq_set;
@@ -384,6 +401,13 @@ vdpa_disable_vfio_intr(struct ifcvf_internal *internal)
irq_set->index = VFIO_PCI_MSIX_IRQ_INDEX;
irq_set->start = 0;
+ nr_vring = rte_vhost_get_vring_num(internal->vid);
+ for (i = 0; i < nr_vring; i++) {
+ if (internal->intr_fd[i] >= 0)
+ close(internal->intr_fd[i]);
+ internal->intr_fd[i] = -1;
+ }
+
ret = ioctl(internal->vfio_dev_fd, VFIO_DEVICE_SET_IRQS, irq_set);
if (ret) {
DRV_LOG(ERR, "Error disabling MSI-X interrupts: %s",
@@ -505,7 +529,7 @@ update_datapath(struct ifcvf_internal *internal)
if (ret)
goto err;
- ret = vdpa_enable_vfio_intr(internal);
+ ret = vdpa_enable_vfio_intr(internal, 0);
if (ret)
goto err;
@@ -591,9 +615,19 @@ m_ifcvf_start(struct ifcvf_internal *internal)
}
hw->vring[i].avail = gpa;
- hw->vring[i].used = m_vring_iova +
- (char *)internal->m_vring[i].used -
- (char *)internal->m_vring[i].desc;
+ /* Direct I/O for Tx queue, relay for Rx queue */
+ if (i & 1) {
+ gpa = hva_to_gpa(vid, (uint64_t)(uintptr_t)vq.used);
+ if (gpa == 0) {
+ DRV_LOG(ERR, "Fail to get GPA for used ring.");
+ return -1;
+ }
+ hw->vring[i].used = gpa;
+ } else {
+ hw->vring[i].used = m_vring_iova +
+ (char *)internal->m_vring[i].used -
+ (char *)internal->m_vring[i].desc;
+ }
hw->vring[i].size = vq.size;
@@ -647,35 +681,6 @@ m_ifcvf_stop(struct ifcvf_internal *internal)
return 0;
}
-static int
-m_enable_vfio_intr(struct ifcvf_internal *internal)
-{
- uint32_t nr_vring;
- struct rte_intr_handle *intr_handle = &internal->pdev->intr_handle;
- int ret;
-
- nr_vring = rte_vhost_get_vring_num(internal->vid);
-
- ret = rte_intr_efd_enable(intr_handle, nr_vring)
[dpdk-dev] [PATCH 3/3] net/ifc: fix used ring update
The vring relay thread is created after HW datapath start and is
canceled before HW datapath stop, so we need to take care of the
ring update when the relay thread is not on duty.
Fixes: 4bb531e152d3 ("net/ifc: support SW assisted VDPA live migration")
Signed-off-by: Xiao Wang
---
drivers/net/ifc/ifcvf_vdpa.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/ifc/ifcvf_vdpa.c b/drivers/net/ifc/ifcvf_vdpa.c
index 9e729ff72..e59084034 100644
--- a/drivers/net/ifc/ifcvf_vdpa.c
+++ b/drivers/net/ifc/ifcvf_vdpa.c
@@ -81,6 +81,8 @@ static struct internal_list_head internal_list =
static pthread_mutex_t internal_list_lock = PTHREAD_MUTEX_INITIALIZER;
+static void update_used_ring(struct ifcvf_internal *internal, uint16_t qid);
+
static struct internal_list *
find_internal_resource_by_did(int did)
{
@@ -666,6 +668,10 @@ m_ifcvf_stop(struct ifcvf_internal *internal)
ifcvf_stop_hw(hw);
for (i = 0; i < hw->nr_vring; i++) {
+ /* synchronize remaining new used entries if any */
+ if ((i & 1) == 0)
+ update_used_ring(internal, i);
+
rte_vhost_get_vhost_vring(vid, i, &vq);
len = IFCVF_USED_RING_LEN(vq.size);
rte_vhost_log_used_vring(vid, i, 0, len);
@@ -735,6 +741,7 @@ vring_relay(void *arg)
DRV_LOG(ERR, "epoll add error: %s", strerror(errno));
return NULL;
}
+ update_used_ring(internal, qid);
}
/* start relay with a first kick */
--
2.15.1
[dpdk-dev] [PATCH 2/3] net/ifc: fix mediated vring initialization
The mediated vring's index should be set as initial value before enabling
HW datapath.
Fixes: 4bb531e152d3 ("net/ifc: support SW assisted VDPA live migration")
Signed-off-by: Xiao Wang
---
drivers/net/ifc/ifcvf_vdpa.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ifc/ifcvf_vdpa.c b/drivers/net/ifc/ifcvf_vdpa.c
index 619cdc245..9e729ff72 100644
--- a/drivers/net/ifc/ifcvf_vdpa.c
+++ b/drivers/net/ifc/ifcvf_vdpa.c
@@ -631,6 +631,10 @@ m_ifcvf_start(struct ifcvf_internal *internal)
hw->vring[i].size = vq.size;
+ rte_vhost_get_vring_base(vid, i,
+ &internal->m_vring[i].avail->idx,
+ &internal->m_vring[i].used->idx);
+
rte_vhost_get_vring_base(vid, i, &hw->vring[i].last_avail_idx,
&hw->vring[i].last_used_idx);
@@ -702,11 +706,6 @@ vring_relay(void *arg)
vid = internal->vid;
q_num = rte_vhost_get_vring_num(vid);
- /* prepare the mediated vring */
- for (qid = 0; qid < q_num; qid++)
- rte_vhost_get_vring_base(vid, qid,
- &internal->m_vring[qid].avail->idx,
- &internal->m_vring[qid].used->idx);
/* add notify fd and interrupt fd to epoll */
epfd = epoll_create(IFCVF_MAX_QUEUES * 2);
--
2.15.1
Re: [dpdk-dev] [PATCH 2/2] net/af_xdp: make reserve/submit peek/release consistent
On Fri, Apr 12, 2019 at 4:54 PM Xiaolong Ye wrote:
> As David pointed out, if we reserve N slots, but only submit n slots,
> we would end up with an incorrect opinion of the number of available slots
> later, we also would get wrong idx when we call xsk_ring_prod__reserve next
> time. It also applies to xsk_ring_cons__peek()/xsk_ring_cons__release().
>
> This patch ensures that both reserve/submit and peek/release are
> consistent.
>
> Fixes: f1debd77efaf ("net/af_xdp: introduce AF_XDP PMD")
>
> Reported-by: David Marchand
> Signed-off-by: Xiaolong Ye
> ---
> drivers/net/af_xdp/rte_eth_af_xdp.c | 80 +++--
> 1 file changed, 41 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/net/af_xdp/rte_eth_af_xdp.c
> b/drivers/net/af_xdp/rte_eth_af_xdp.c
> index 5cc643ce2..76a6a8331 100644
> --- a/drivers/net/af_xdp/rte_eth_af_xdp.c
> +++ b/drivers/net/af_xdp/rte_eth_af_xdp.c
> @@ -138,22 +138,19 @@ reserve_fill_queue(struct xsk_umem_info *umem, int
> reserve_size)
> {
> struct xsk_ring_prod *fq = &umem->fq;
> uint32_t idx;
> - int i, ret;
> -
> - ret = xsk_ring_prod__reserve(fq, reserve_size, &idx);
> - if (unlikely(!ret)) {
> - AF_XDP_LOG(ERR, "Failed to reserve enough fq descs.\n");
> - return ret;
> - }
> + int i;
>
> for (i = 0; i < reserve_size; i++) {
> __u64 *fq_addr;
> void *addr = NULL;
> if (rte_ring_dequeue(umem->buf_ring, &addr)) {
> - i--;
> break;
> }
> - fq_addr = xsk_ring_prod__fill_addr(fq, idx++);
> + if (unlikely(!xsk_ring_prod__reserve(fq, 1, &idx))) {
> + AF_XDP_LOG(WARNING, "Failed to reserve 1 fq
> desc.\n");
> + break;
> + }
> + fq_addr = xsk_ring_prod__fill_addr(fq, idx);
> *fq_addr = (uint64_t)addr;
> }
>
>
I just spotted that reserve_fill_queue always returns 0.
I understand that xsk_configure expects an errors when not succeeding in
populating this ring.
And for this, it expects a non zero value for this.
How about something like (neither tested nor compiled):
static inline int
reserve_fill_queue(struct xsk_umem_info *umem, int reserve_size)
{
struct xsk_ring_prod *fq = &umem->fq;
void *addrs[reserve_size];
uint32_t idx;
int i, ret;
if (rte_ring_dequeue_bulk(umem->buf_ring, &addrs, reserve_size, NULL)
!= reserve_size) {
AF_XDP_LOG(DEBUG, "Failed to get enough buffers for fq.\n");
return -1;
}
ret = xsk_ring_prod__reserve(fq, reserve_size, &idx);
if (unlikely(!ret)) {
AF_XDP_LOG(DEBUG, "Failed to reserve enough fq descs.\n");
rte_ring_enqueue_bulk(umem->buf_ring, &addrs, reserve_size,
NULL);
return -1;
}
for (i = 0; i < reserve_size; i++) {
__u64 *fq_addr;
fq_addr = xsk_ring_prod__fill_addr(fq, idx++);
*fq_addr = (uint64_t)addrs[i];
}
xsk_ring_prod__submit(fq, reserve_size);
return 0;
}
@@ -179,6 +176,9 @@ eth_af_xdp_rx(void *queue, struct rte_mbuf **bufs,
> uint16_t nb_pkts)
>
> nb_pkts = RTE_MIN(nb_pkts, ETH_AF_XDP_TX_BATCH_SIZE);
>
> + if (unlikely(rte_pktmbuf_alloc_bulk(rxq->mb_pool, mbufs, nb_pkts)
> != 0))
> + return 0;
> +
> rcvd = xsk_ring_cons__peek(rx, nb_pkts, &idx_rx);
> if (rcvd == 0)
> return 0;
>
When xsk_ring_cons__peek() returns 0, we will leak nb_pkts freshly
allocated mbufs.
See below for a suggestion.
@@ -186,9 +186,6 @@ eth_af_xdp_rx(void *queue, struct rte_mbuf **bufs,
> uint16_t nb_pkts)
> if (xsk_prod_nb_free(fq, free_thresh) >= free_thresh)
> (void)reserve_fill_queue(umem, ETH_AF_XDP_RX_BATCH_SIZE);
>
> - if (unlikely(rte_pktmbuf_alloc_bulk(rxq->mb_pool, mbufs, rcvd) !=
> 0))
> - return 0;
> -
> for (i = 0; i < rcvd; i++) {
> const struct xdp_desc *desc;
> uint64_t addr;
> @@ -211,6 +208,10 @@ eth_af_xdp_rx(void *queue, struct rte_mbuf **bufs,
> uint16_t nb_pkts)
>
> xsk_ring_cons__release(rx, rcvd);
>
> + /* free the extra mbufs */
> + for (; rcvd < nb_pkts; rcvd++)
> + rte_pktmbuf_free(mbufs[rcvd]);
> +
>
You can move this block after the statistic update...
/* statistics */
> rxq->stats.rx_pkts += (rcvd - dropped);
> rxq->stats.rx_bytes += rx_bytes;
>
... then define a out: label.
And those mbufs are still clean and coming from a single mempool, we can
put them back as a single bulk.
Something like (again, untested):
out:
if (count != nb_pkts) {
rte_mempool_put_bulk(rxq->mb_pool, &mbufs[count],
nb_pkts - count);
}
return count;
}
And you would jump to this label when xsk_ring_cons__peek() == 0.
What do you think ?
Re: [dpdk-dev] [PATCH v2] kni: implement header_ops parse method
Hi Ferruh,
To be absolutely sure, I performed a test using the test application.
When I send pings from an interface:
3: ens8: mtu 1500 qdisc pfifo_fast state
UP mode DEFAULT group default qlen 1000
link/ether 52:54:00:c8:79:c6 brd ff:ff:ff:ff:ff:ff
Here is what's in sockaddr_ll:
$2 = {sll_family = 0x11, sll_protocol = 0x8, sll_ifindex = 0x2, sll_hatype
= 0x1, sll_pkttype = 0x0, sll_halen = 0x6, sll_addr = {
0x52, 0x54, 0x0, 0xc8, 0x79, 0xc6, 0x0, 0x0}}
So everything works as expected – the address in sll_addr is correct.
Last two bytes are zero because the length of sll_addr is 8, however,
Ethernet length is 6.
Igor
On Fri, Apr 12, 2019 at 8:15 PM Ferruh Yigit wrote:
> On 4/12/2019 6:12 PM, Igor Ryzhov wrote:
> > Hi Ferruh,
> >
> > I didn't test it with any special application, but FRR's ISIS works for
> me after
> > the patch, and it didn't work before.
>
> That is good enough, and by work you mean that you are able to get correct
> value
> on 'sll_addr', right?
>
> >
> > Igor
> >
> > On Fri, Apr 12, 2019 at 5:53 PM Ferruh Yigit > > wrote:
> >
> > On 4/12/2019 3:52 PM, Ferruh Yigit wrote:
> > > On 4/10/2019 11:30 AM, Igor Ryzhov wrote:
> > >> It allows applications running packet sockets over KNI interfaces
> to get
> > >> source Ethernet addresses of packets received using recvfrom
> function.
> > >>
> > >> Signed-off-by: Igor Ryzhov iryz...@nfware.com>>
> > >
> > > Acked-by: Ferruh Yigit > >
> > >
> > >
> > > Hi Igor,
> > >
> > > I tested this with a quick application on top of kni interfaces,
> that
> > reads and
> > > prints the 'sll_halen', but the last two bytes of the mac address
> are always
> >
> > I mean 'sll_addr', 'sll_halen' is right (6).
> >
> > > zero, it is quite possible that something is not right in the test
> app, but
> > > before spending any time on it, can you please confirm this is
> working
> > fine for you?
> > >
> >
>
>
[dpdk-dev] [PATCH] net/mlx4: fix memory region cleanup routine
mlx4 driver has a global list of Memory Regions created by
device, and there is a ml4_mr_release() routine which makes
a memory cleanup at device closing. The head of device MR list
was fetched outside the rwlock protected section. Also some
noticed typos are fixed.
Fixes: 9797bfcce1c9 ("net/mlx4: add new memory region support")
Cc: sta...@dpdk.org
Signed-off-by: Viacheslav Ovsiienko
Acked-by: Yongseok Koh
---
drivers/net/mlx4/mlx4_mr.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/net/mlx4/mlx4_mr.c b/drivers/net/mlx4/mlx4_mr.c
index ad7d483..48d458a 100644
--- a/drivers/net/mlx4/mlx4_mr.c
+++ b/drivers/net/mlx4/mlx4_mr.c
@@ -477,7 +477,7 @@ struct mr_update_mp_data {
}
/**
- * Releass resources of detached MR having no online entry.
+ * Release resources of detached MR having no online entry.
*
* @param dev
* Pointer to Ethernet device.
@@ -527,7 +527,7 @@ struct mr_update_mp_data {
}
/**
- * Create a new global Memroy Region (MR) for a missing virtual address.
+ * Create a new global Memory Region (MR) for a missing virtual address.
* This API should be called on a secondary process, then a request is sent to
* the primary process in order to create a MR for the address. As the global
MR
* list is on the shared memory, following LKey lookup should succeed unless
the
@@ -573,7 +573,7 @@ struct mr_update_mp_data {
}
/**
- * Create a new global Memroy Region (MR) for a missing virtual address.
+ * Create a new global Memory Region (MR) for a missing virtual address.
* Register entire virtually contiguous memory chunk around the address.
* This must be called from the primary process.
*
@@ -682,7 +682,7 @@ struct mr_update_mp_data {
bmp_mem = RTE_PTR_ALIGN_CEIL(mr + 1, RTE_CACHE_LINE_SIZE);
mr->ms_bmp = rte_bitmap_init(ms_n, bmp_mem, bmp_size);
if (mr->ms_bmp == NULL) {
- WARN("port %u unable to initialize bitamp for a new MR of"
+ WARN("port %u unable to initialize bitmap for a new MR of"
" address (%p).",
dev->data->port_id, (void *)addr);
rte_errno = EINVAL;
@@ -820,7 +820,7 @@ struct mr_update_mp_data {
}
/**
- * Create a new global Memroy Region (MR) for a missing virtual address.
+ * Create a new global Memory Region (MR) for a missing virtual address.
* This can be called from primary and secondary process.
*
* @param dev
@@ -1434,7 +1434,7 @@ struct mr_update_mp_data {
mlx4_mr_release(struct rte_eth_dev *dev)
{
struct mlx4_priv *priv = dev->data->dev_private;
- struct mlx4_mr *mr_next = LIST_FIRST(&priv->mr.mr_list);
+ struct mlx4_mr *mr_next;
/* Remove from memory callback device list. */
rte_rwlock_write_lock(&mlx4_shared_data->mem_event_rwlock);
@@ -1445,6 +1445,7 @@ struct mr_update_mp_data {
#endif
rte_rwlock_write_lock(&priv->mr.rwlock);
/* Detach from MR list and move to free list. */
+ mr_next = LIST_FIRST(&priv->mr.mr_list);
while (mr_next != NULL) {
struct mlx4_mr *mr = mr_next;
--
1.8.3.1
Re: [dpdk-dev] [dpdk-stable] [PATCH 1/1] net/mlx5: fix memory region cleanup routine
> -Original Message-
> From: Shahaf Shuler
> Sent: Sunday, April 14, 2019 9:58
> To: Yongseok Koh ; Slava Ovsiienko
>
> Cc: dev ; sta...@dpdk.org
> Subject: RE: [dpdk-stable] [PATCH 1/1] net/mlx5: fix memory region cleanup
> routine
>
> Friday, April 12, 2019 8:55 PM, Yongseok Koh:
> > Subject: Re: [dpdk-stable] [PATCH 1/1] net/mlx5: fix memory region
> > cleanup routine
> >
> >
> > > On Apr 12, 2019, at 8:45 AM, Viacheslav Ovsiienko
> > wrote:
> > >
> > > mlx5 driver has a global list of Memory Regions created by device,
> > > and there is a ml5_mr_release() routine which makes a memory cleanup
> > > at device closing. The head of device MR list was fetched outside
> > > the rwlock protected section. Also some noticed typos are fixed.
> > >
> > > Fixes: 974f1e7ef146 ("net/mlx5: add new memory region support")
> > > Cc: sta...@dpdk.org
> > >
> > > Signed-off-by: Viacheslav Ovsiienko
> > > ---
> >
> > Nice catch, Slava
> > Can you please submit the same fix for mlx4?
> >
> > Acked-by: Yongseok Koh
>
> Slava - please merge both mlx4 and mlx5 into the same patch.
> Keep Koh's acked-by.
>
> I will take the v2.
There are some troubles with passing check-log script for mlx4/mlx5 merged
patch.
So, I prepared the separated patch for mlx4 with right headline and fix
reference.
http://patches.dpdk.org/patch/52791/
If you don't mind - please apply both (for mlx4 and mlx5) patches. Thanks.
With best regards,
Slava
>
> >
> > Thanks
> >
> > > drivers/net/mlx5/mlx5_mr.c | 13 +++--
> > > 1 file changed, 7 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/net/mlx5/mlx5_mr.c b/drivers/net/mlx5/mlx5_mr.c
> > > index 44b6591..a3732d4 100644
> > > --- a/drivers/net/mlx5/mlx5_mr.c
> > > +++ b/drivers/net/mlx5/mlx5_mr.c
> > > @@ -466,7 +466,7 @@ struct mr_update_mp_data { }
> > >
> > > /**
> > > - * Releass resources of detached MR having no online entry.
> > > + * Release resources of detached MR having no online entry.
> > > *
> > > * @param dev
> > > * Pointer to Ethernet device.
> > > @@ -516,7 +516,7 @@ struct mr_update_mp_data { }
> > >
> > > /**
> > > - * Create a new global Memroy Region (MR) for a missing virtual
> address.
> > > + * Create a new global Memory Region (MR) for a missing virtual
> address.
> > > * This API should be called on a secondary process, then a request
> > > is sent to
> > > * the primary process in order to create a MR for the address. As
> > > the global MR
> > > * list is on the shared memory, following LKey lookup should
> > > succeed unless the @@ -562,7 +562,7 @@ struct mr_update_mp_data { }
> > >
> > > /**
> > > - * Create a new global Memroy Region (MR) for a missing virtual
> address.
> > > + * Create a new global Memory Region (MR) for a missing virtual
> address.
> > > * Register entire virtually contiguous memory chunk around the address.
> > > * This must be called from the primary process.
> > > *
> > > @@ -673,7 +673,7 @@ struct mr_update_mp_data {
> > > bmp_mem = RTE_PTR_ALIGN_CEIL(mr + 1, RTE_CACHE_LINE_SIZE);
> > > mr->ms_bmp = rte_bitmap_init(ms_n, bmp_mem, bmp_size);
> > > if (mr->ms_bmp == NULL) {
> > > - DEBUG("port %u unable to initialize bitamp for a new MR of"
> > > + DEBUG("port %u unable to initialize bitmap for a new MR of"
> > > " address (%p).",
> > > dev->data->port_id, (void *)addr);
> > > rte_errno = EINVAL;
> > > @@ -811,7 +811,7 @@ struct mr_update_mp_data { }
> > >
> > > /**
> > > - * Create a new global Memroy Region (MR) for a missing virtual
> address.
> > > + * Create a new global Memory Region (MR) for a missing virtual
> address.
> > > * This can be called from primary and secondary process.
> > > *
> > > * @param dev
> > > @@ -1600,7 +1600,7 @@ struct mr_update_mp_data {
> > > mlx5_mr_release(struct rte_eth_dev *dev) {
> > > struct mlx5_priv *priv = dev->data->dev_private;
> > > - struct mlx5_mr *mr_next = LIST_FIRST(&priv->mr.mr_list);
> > > + struct mlx5_mr *mr_next;
> > >
> > > /* Remove from memory callback device list. */
> > > rte_rwlock_write_lock(&mlx5_shared_data->mem_event_rwlock);
> > > @@ -1610,6 +1610,7 @@ struct mr_update_mp_data {
> > > mlx5_mr_dump_dev(dev);
> > > rte_rwlock_write_lock(&priv->mr.rwlock);
> > > /* Detach from MR list and move to free list. */
> > > + mr_next = LIST_FIRST(&priv->mr.mr_list);
> > > while (mr_next != NULL) {
> > > struct mlx5_mr *mr = mr_next;
> > >
> > > --
> > > 1.8.3.1
> > >
Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
On Sat, Apr 13, 2019 at 08:42:02PM -0400, Neil Horman wrote: > On Mon, Apr 08, 2019 at 10:04:21AM +0100, Ray Kinsella wrote: > > On 07/04/2019 10:48, Thomas Monjalon wrote: > > > 04/04/2019 16:07, Burakov, Anatoly: > > >> On 04-Apr-19 1:52 PM, Ray Kinsella wrote: > > >>> On 04/04/2019 11:54, Bruce Richardson wrote: > > On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote: > > > On 03-Apr-19 4:42 PM, Ray Kinsella wrote: > > [SNIP] > > >> So, if we are to cement our core API - we have to make a concrete effort > > >> to specify what goes and what stays, if we want it to be maintainable. > > >> The DPDK 1.0 specification, if you will :) > > > > > > "DPDK 1.0 specification", that's a great project name :-) > > > > > > > Honestly - I would say that I am nervous of this. > > > > The definition of a DPDK 1.0 specification as a gate to API stability, > > feels like a "great plan tomorrow" instead of a "good plan" today. I > > think that getting people to dedicate time to such a specification might > > prove problematic and I could see this effort being very time consuming. > > It might never get completed. > > > > My preference would be to instead adopt a well-publicised community > > timeline for adopting more conservative API maintenance rules. > > > > Perhaps we could give ourselves as a community a time-limited window in > > which to address concerns around the API before they become hardened - > > perhaps say until DPDK 19.11 LTS, or something of the order of 6 months > > to 9 months. > > > > We then would know the timeline when niggles like exposure of internal > > structures and mbuf structure needed to be sorted by and could > > prioritize accordingly. > > > > Ray K > > I'm hesitant to say this, because I'm not usually a fan of throwing up > barricades to progress, but might some level of CI integration be useful here? > > Part of the problem, as I've seen it (and I think you've noted previously in > this thread), is that ABI stability just hasn't been a priority, and not > something that developers look at when making changes, nor when reviewers > review > patches. When I wrote the early ABI checking tools for DPDK, while the > reaction > was generally positive (I think), the results were informational, and treated > as > such (something to take note of perhaps, but something that could be ignored > if > there were more pressing issues). Perhaps a concrete step might be to run the > ABI checker during a CI run on every commit, and block acceptance of a patch > if > it modifies the ABI. That would at least put a procedural break in ABI > modification without clear approval from the board. > No objections to that here. Sounds a reasonable suggestion.
Re: [dpdk-dev] [PATCH v8 3/3] test/ticketlock: add ticket lock test case
> -Original Message-
> From: Thomas Monjalon
> Sent: Monday, April 15, 2019 4:38 AM
> To: Joyce Kong (Arm Technology China)
> Cc: dev@dpdk.org; David Marchand ; nd
> ; Stephen Hemminger ;
> Jerin Jacob ; Ananyev, Konstantin
> ; Honnappa Nagarahalli
> ; Gavin Hu (Arm Technology China)
>
> Subject: Re: [dpdk-dev] [PATCH v8 3/3] test/ticketlock: add ticket lock test
> case
>
> 08/04/2019 22:18, David Marchand:
> > On Mon, Mar 25, 2019 at 12:12 PM Joyce Kong
> wrote:
> > > --- a/app/test/autotest_data.py
> > > +++ b/app/test/autotest_data.py
> > > @@ -171,6 +171,12 @@
> > > "Report": None,
> > > },
> > > {
> > > +"Name":"Ticketlock autotest",
> > > +"Command": "ticketlock_autotest",
> > > +"Func":ticketlock_autotest,
> > > +"Report": None,
> > > +}
> > > +{
> > > "Name":"Byte order autotest",
> > > "Command": "byteorder_autotest",
> > > "Func":default_autotest,
> > >
> >
> > Please, can you fix this ?
> >
> > We are missing a , and ticketlock_autotest has no implementation in
> > python afaics.
>
> Please, send a fix ASAP.
Fix in the patch test/ticketlock: implement ticketlock autotest .
Re: [dpdk-dev] [PATCH 1/1] net/mlx5: add support for PF representor
Hi, Shahaf
> -Original Message-
> From: Shahaf Shuler
> Sent: Sunday, April 14, 2019 10:43
> To: Slava Ovsiienko ; dev@dpdk.org
> Subject: RE: [dpdk-dev] [PATCH 1/1] net/mlx5: add support for PF
> representor
>
> Hi Slava,
>
> Friday, April 12, 2019 6:48 PM, Viacheslav Ovsiienko:
> > Subject: [dpdk-dev] [PATCH 1/1] net/mlx5: add support for PF
> > representor
> >
> > On BlueField platform we have the new entity - PF representor.
> > This one represents the PCI PF attached to external host on the side of
> ARM.
> > The traffic sent by the external host to the NIC via PF will be seem
> > by ARM on this PF representor.
> >
> > This patch extends port recognizing capability on the base of physical
> > port name. The following naming formats are supported:
> >
> > - missing physical port name (no sysfs/netlink key) at all,
> > this is old style (before kernel 5.0) format, master assumed
> > - 1 (decimal digits) - old style (before kernel 5.0) format,
> > exists only for representors, master does not have physical
> > port name at all (see above)
> > - p0 ("p" followed by decimal digits), new style (kernel version
> > is 5.0 or higher, Mellanox OFED 4.6 or higher) name format
> > for uplink representor, plays the role of master
> > - pf0vf0 ("pf" followed by PF index concatenated with "vf"
> > followed by VF index), new style (kernel version is 5.0
> > or higher, Mellanox OFED 4.6 or higher) name format for
> > VF representor. If index of VF is "-1" it is a special case
> > of host PF representor, this representor must be indexed in
> > devargs as 65535, for example representor=[0-3,65535] will
> > allow representors for VF0, VF1, VF2, VF3 and host PF.
> > Note: do not specify representor=[0-65535] it causes devargs
> > processing error, because number of ports (rte_eth_dev) is
> > limited.
> >
>
> The above is a bit complex to understand and in fact we have 2 modes:
> 1. legacy - phys_port_name are numbers. Master doesn't have
> phys_port_name 2. modern - phys_port_name are strings.
> uplink representor is p%d
> representors are (including PF representor) pf%dvf%d. the vf index for the PF
> representor is 65535.
OK, I'll try to update the commit message to make it more clear.
>
> > Applications should distinguish representors and master devices
> > exclusively by device flag RTE_ETH_DEV_REPRESENTOR and do not rely on
> > switch port_id (mlx5 PMD deduces ones from representor_id) values
> > returned by
> > dev_infos_get() API.
> >
>
> Please also reference the kernel commit which introduce the name change.
OK.
>
> > Signed-off-by: Viacheslav Ovsiienko
> > ---
> > drivers/net/mlx5/mlx5.h| 11 ++-
> > drivers/net/mlx5/mlx5_ethdev.c | 68 +++
> > ---
> > drivers/net/mlx5/mlx5_nl.c | 42 +-
> > 3 files changed, 82 insertions(+), 39 deletions(-)
> >
> > diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h index
> > 8eb1019..81c02ce 100644
> > --- a/drivers/net/mlx5/mlx5.h
> > +++ b/drivers/net/mlx5/mlx5.h
> > @@ -80,11 +80,20 @@ struct mlx5_mp_param {
> > /** Key string for IPC. */
> > #define MLX5_MP_NAME "net_mlx5_mp"
> >
> > +/* Recognized Infiniband device physical port name types. */ enum
> > +mlx5_phys_port_name_type {
> > + MLX5_PHYS_PORT_NAME_TYPE_UNKNOWN = 0, /* Unrecognized.
> > */
> > + MLX5_PHYS_PORT_NAME_TYPE_LEGACY, /* before kernel ver < 5.0
> > */
> > + MLX5_PHYS_PORT_NAME_TYPE_UPLINK, /* p0, kernel ver >= 5.0 */
> > + MLX5_PHYS_PORT_NAME_TYPE_PFVF, /* pf0vf0, kernel ver >= 5.0
> > */ };
> > +
> > /** Switch information returned by mlx5_nl_switch_info(). */ struct
> > mlx5_switch_info {
> > uint32_t master:1; /**< Master device. */
> > uint32_t representor:1; /**< Representor device. */
> > - uint32_t port_name_new:1; /**< Rep. port name is in new format.
> > */
> > + enum mlx5_phys_port_name_type name_type; /** < Port name
> > type. */
> > + int32_t pf_num; /**< PF number (valid for pfxvfx format only). */
> > int32_t port_name; /**< Representor port name. */
> > uint64_t switch_id; /**< Switch identifier. */ }; diff --git
> > a/drivers/net/mlx5/mlx5_ethdev.c b/drivers/net/mlx5/mlx5_ethdev.c
> > index 3992918..371989f 100644
> > --- a/drivers/net/mlx5/mlx5_ethdev.c
> > +++ b/drivers/net/mlx5/mlx5_ethdev.c
> > @@ -1395,12 +1395,11 @@ int mlx5_fw_version_get(struct rte_eth_dev
> > *dev, char *fw_ver, size_t fw_size)
> > struct mlx5_switch_info data = {
> > .master = 0,
> > .representor = 0,
> > - .port_name_new = 0,
> > + .name_type = MLX5_PHYS_PORT_NAME_TYPE_UNKNOWN,
> > .port_name = 0,
> > .switch_id = 0,
> > };
> > DIR *dir;
> > - bool port_name_set = false;
> > bool port_switch_id_set = false;
> > bool device_dir = false;
> > char c;
> > @@ -1423,8 +1422,7 @@ int mlx5_fw_version_get(struct rte_eth_dev
>
[dpdk-dev] [PATCH v1] test/ticketlock: implement ticketlock autotest
Add ticketlock_autotest implementation in python.
Fixes: efbcdaa55b93 ("test/ticketlock: add test cases")
Signed-off-by: Joyce Kong
---
app/test/autotest_data.py | 2 +-
app/test/autotest_test_funcs.py | 34 ++
2 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/app/test/autotest_data.py b/app/test/autotest_data.py
index db25274..72c56e5 100644
--- a/app/test/autotest_data.py
+++ b/app/test/autotest_data.py
@@ -175,7 +175,7 @@
"Command": "ticketlock_autotest",
"Func":ticketlock_autotest,
"Report": None,
-}
+},
{
"Name":"Byte order autotest",
"Command": "byteorder_autotest",
diff --git a/app/test/autotest_test_funcs.py b/app/test/autotest_test_funcs.py
index 65fe335..31cc0f5 100644
--- a/app/test/autotest_test_funcs.py
+++ b/app/test/autotest_test_funcs.py
@@ -131,6 +131,40 @@ def rwlock_autotest(child, test_name):
return 0, "Success"
+def ticketlock_autotest(child, test_name):
+i = 0
+ir = 0
+child.sendline(test_name)
+while True:
+index = child.expect(["Test OK",
+ "Test Failed",
+ "Hello from core ([0-9]*) !",
+ "Hello from within recursive locks "
+ "from ([0-9]*) !",
+ pexpect.TIMEOUT], timeout=5)
+# ok
+if index == 0:
+break
+
+# message, check ordering
+elif index == 2:
+if int(child.match.groups()[0]) < i:
+return -1, "Fail [Bad order]"
+i = int(child.match.groups()[0])
+elif index == 3:
+if int(child.match.groups()[0]) < ir:
+return -1, "Fail [Bad order]"
+ir = int(child.match.groups()[0])
+
+# fail
+elif index == 4:
+return -1, "Fail [Timeout]"
+elif index == 1:
+return -1, "Fail"
+
+return 0, "Success"
+
+
def logs_autotest(child, test_name):
child.sendline(test_name)
--
2.7.4
Re: [dpdk-dev] [PATCH v2 3/3] app/test/meson: auto detect number of cores
On Fri, Apr 12, 2019 at 02:21:41PM -0400, Aaron Conole wrote:
> Bruce Richardson writes:
>
> > On Fri, Apr 12, 2019 at 12:21:41PM -0400, Aaron Conole wrote:
> >> The arguments being passed will cause failures on laptops that have,
> >> for instance, 2 cores only. Most of the tests don't require more
> >> than a single core. Some require multiple cores (but those tests
> >> should be modified to 'SKIP' when the correct number of cores
> >> aren't available).
> >>
> >> The unit test results shouldn't be impacted by this change, but it
> >> allows for a future enhancement to pass flags such as '--no-huge'.
> >>
> >> Also include a fix to a reported issue with running on FreeBSD.
> >>
> >> Signed-off-by: Aaron Conole
> >> Reviewed-by: David Marchand
> >> Acked-by: Luca Boccassi
> >> ---
> >> v2:
> >> * Fix a spelling mistake
> >> * Add support for FreeBSD
> >> * Include a default fallback
> >> * Use a more robust core-mask argument source (rather than lscpu)
> >>
> >> Conflicts with http://patches.dpdk.org/patch/50850/
> >>
> >> app/test/meson.build | 35 ---
> >> 1 file changed, 32 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/app/test/meson.build b/app/test/meson.build
> >> index 867cc5863..5e056eb59 100644
> >> --- a/app/test/meson.build
> >> +++ b/app/test/meson.build
> >> @@ -344,17 +344,43 @@ if get_option('tests')
> >>timeout_seconds = 600
> >>timeout_seconds_fast = 10
> >>
> >> + # Retrieve the number of CPU cores, defaulting to 4.
> >> + num_cores = '0-3'
> >> + if host_machine.system() == 'linux'
> >> + num_cores = run_command('cat',
> >> + '/sys/devices/system/cpu/present'
> >> + ).stdout().strip()
> >> + elif host_machine.system() == 'freebsd'
> >> + snum_cores = run_command('/sbin/sysctl', '-n',
> >> + 'hw.ncpu').stdout().strip()
> >> + inum_cores = snum_cores.to_int() - 1
> >> +num_cores = '0-@0@'.format(inum_cores)
> >> + endif
> >> +
> >> + num_cores_arg = '-l ' + num_cores
> >> +
> >> + test_args = [num_cores_arg, '-n 4']
> >
> > This -n 4 parameter can be dropped. Four is the default setting IIRC.
>
> For another patch. I thought about doing it with this one, but I'd
> rather keep the changes a little bit traceable. If you think I should
> resubmit with it dropped, I will.
>
> > I also wonder are the parameters coming through to the app correctly,
> > generally meson does not work well with parameters with spaces in them -
> > I'd expect the "-l" and the num_cores values to be separated in the array.
> > I also think num_cores_arg value could be dropped too.
> >
> > If it works though, I'm ok to keep as-is though.
>
> It does work. Actually, I needed to change because on some of the VM
> setups (including the one used by Travis) the '-c f' arg errors because
> it wants 4 cores, and only 2 exist. Either way, this patch doesn't
> change the spacing being passed with args :)
>
> >>foreach arg : fast_parallel_test_names
> >> - test(arg, dpdk_test,
> >> - env : ['DPDK_TEST=' + arg],
> >> - args : ['-c f','-n 4', '--file-prefix=@0@'.format(arg)],
> >> + if host_machine.system() == 'linux'
> >> + test(arg, dpdk_test,
> >> +env : ['DPDK_TEST=' + arg],
> >> +args : test_args +
> >> + ['--file-prefix=@0@'.format(arg)],
> >> + timeout : timeout_seconds_fast,
> >> + suite : 'fast-tests')
> >> + else
> >> + test(arg, dpdk_test,
> >> + env : ['DPDK_TEST=' + arg],
> >> + args : test_args,
> >>timeout : timeout_seconds_fast,
> >>suite : 'fast-tests')
> >> + endif
> >>endforeach
> >
> > While this is needed now, I think in the medium term we should have the
> > "file-prefix" flag being a warning rather than a hard-error on FreeBSD.
> > [i.e. keep this, but we should fix it in 19.08 to be shorter]
>
> Agreed. Probably a good cleanup in the future.
>
Fair responses to all comments.
Acked-by: Bruce Richardson
Re: [dpdk-dev] [PATCH] examples/vm_power: add conditional compilation for PMD specific code
Hi David,
On 2/4/2019 7:14 PM, David Christensen wrote:
Signed-off-by: David Christensen
---
Running the devtools/test-build.sh script on IBM Power systems fails
because the IXGBE_PMD is explicity disabled for Power as an untested
driver, but the examples/vm_power_manager application has a hard
dependency on a function call in the IXGBE_PMD.
Modify the example application so that all dependencies on PMD code
are conditionally compiled.
examples/vm_power_manager/main.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/examples/vm_power_manager/main.c b/examples/vm_power_manager/main.c
index 893bf4c..bb50a2a 100644
--- a/examples/vm_power_manager/main.c
+++ b/examples/vm_power_manager/main.c
@@ -31,9 +31,15 @@
#include "vm_power_cli.h"
#include "oob_monitor.h"
#include "parse.h"
+#ifdef RTE_LIBRTE_IXGBE_PMD
#include
+#endif
+#ifdef RTE_LIBRTE_I40E_PMD
#include
+#endif
+#ifdef RTE_LIBRTE_BNXT_PMD
#include
+#endif
#define RX_RING_SIZE 1024
#define TX_RING_SIZE 1024
@@ -369,14 +375,21 @@
for (w = 0; w < MAX_VFS; w++) {
eth.addr_bytes[5] = w + 0xf0;
+ret = -ENOTSUP;
+#ifdef RTE_LIBRTE_IXGBE_PMD
ret = rte_pmd_ixgbe_set_vf_mac_addr(portid,
w, ð);
+#endif
+#ifdef RTE_LIBRTE_I40E_PMD
if (ret == -ENOTSUP)
ret = rte_pmd_i40e_set_vf_mac_addr(
portid, w, ð);
+#endif
+#ifdef RTE_LIBRTE_BNXT_PMD
if (ret == -ENOTSUP)
ret = rte_pmd_bnxt_set_vf_mac_addr(
portid, w, ð);
+#endif
switch (ret) {
case 0:
Acked-by: David Hunt
Re: [dpdk-dev] [PATCH 3/6] net/mlx: fix library search in meson build
On Fri, Apr 12, 2019 at 04:24:48PM -0700, Yongseok Koh wrote:
> If MLNX_OFED is installed, there's no .pc file installed for libraries and
> dependency() can't find libraries by pkg-config. By adding fallback of
> using cc.find_library(), libraries are properly located.
>
> Fixes: e30b4e566f47 ("build: improve dependency handling")
> Cc: bl...@debian.org
> Cc: sta...@dpdk.org
>
> Signed-off-by: Yongseok Koh
> ---
> drivers/net/mlx4/meson.build | 19 +++
> drivers/net/mlx5/meson.build | 19 +++
> 2 files changed, 22 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/net/mlx4/meson.build b/drivers/net/mlx4/meson.build
> index de020701d1..9082f69f25 100644
> --- a/drivers/net/mlx4/meson.build
> +++ b/drivers/net/mlx4/meson.build
> @@ -13,21 +13,24 @@ if pmd_dlopen
> '-DMLX4_GLUE_VERSION="@0@"'.format(LIB_GLUE_VERSION),
> ]
> endif
> -libs = [
> - dependency('libmnl', required:false),
> - dependency('libmlx4', required:false),
> - dependency('libibverbs', required:false),
> -]
> +libs = [ 'libmnl', 'libmlx4', 'libibverbs' ]
> +lib_deps = []
Minor suggestion - you can reduce the size of the diff in this patch by
defining the first array as "libnames" and keeping the actual dependency
objects as "libs".
/Bruce
Re: [dpdk-dev] [PATCH] lib/librte_power: set new frequecy on turbo_disable
On 12/4/2019 4:57 PM, Lee Daly wrote:
This patch will ensure the correct max frequency of a core is set in
the lcore_power_info struct when disabling turbo, while using the
intel pstate driver.
Fixes: e6c6dc0f96c8 ("power: add p-state driver compatibility")
Cc: liang.j...@intel.com
Cc: sta...@dpdk.org
Signed-off-by: Lee Daly
---
lib/librte_power/power_pstate_cpufreq.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/lib/librte_power/power_pstate_cpufreq.c
b/lib/librte_power/power_pstate_cpufreq.c
index 336c13869..d2ac75123 100644
--- a/lib/librte_power/power_pstate_cpufreq.c
+++ b/lib/librte_power/power_pstate_cpufreq.c
@@ -810,7 +810,15 @@ power_pstate_disable_turbo(unsigned int lcore_id)
pi->turbo_enable = 0;
-
+ if ((pi->turbo_available) && (pi->curr_idx <= 1)) {
+ /* Try to set freq to max by default coming out of turbo */
+ if (power_pstate_cpufreq_freq_max(lcore_id) < 0) {
+ RTE_LOG(ERR, POWER,
+ "Failed to set frequency of lcore %u to max\n",
+ lcore_id);
+ return -1;
+ }
+ }
return 0;
}
Acked-by: David Hunt
[dpdk-dev] [PATCH] net/bonding: fix potential out of bounds read
Add validation to pointer constructed from the IPv4 header length
in order to prevent malformed packets from generating a potential
out of bounds memory read.
Signed-off-by: Radu Nicolau
---
drivers/net/bonding/rte_eth_bond_pmd.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bonding/rte_eth_bond_pmd.c
b/drivers/net/bonding/rte_eth_bond_pmd.c
index b0d191d..25dbddc 100644
--- a/drivers/net/bonding/rte_eth_bond_pmd.c
+++ b/drivers/net/bonding/rte_eth_bond_pmd.c
@@ -842,6 +842,7 @@ burst_xmit_l34_hash(struct rte_mbuf **buf, uint16_t nb_pkts,
for (i = 0; i < nb_pkts; i++) {
eth_hdr = rte_pktmbuf_mtod(buf[i], struct ether_hdr *);
+ size_t pkt_end = (size_t)eth_hdr + rte_pktmbuf_pkt_len(buf[i]);
proto = eth_hdr->ether_type;
vlan_offset = get_vlan_offset(eth_hdr, &proto);
l3hash = 0;
@@ -865,13 +866,17 @@ burst_xmit_l34_hash(struct rte_mbuf **buf, uint16_t
nb_pkts,
tcp_hdr = (struct tcp_hdr *)
((char *)ipv4_hdr +
ip_hdr_offset);
- l4hash = HASH_L4_PORTS(tcp_hdr);
+ if ((size_t)tcp_hdr + sizeof(*tcp_hdr)
+ < pkt_end)
+ l4hash = HASH_L4_PORTS(tcp_hdr);
} else if (ipv4_hdr->next_proto_id ==
IPPROTO_UDP) {
udp_hdr = (struct udp_hdr *)
((char *)ipv4_hdr +
ip_hdr_offset);
- l4hash = HASH_L4_PORTS(udp_hdr);
+ if ((size_t)udp_hdr + sizeof(*udp_hdr)
+ < pkt_end)
+ l4hash = HASH_L4_PORTS(udp_hdr);
}
}
} else if (rte_cpu_to_be_16(ETHER_TYPE_IPv6) == proto) {
--
2.7.5
Re: [dpdk-dev] [PATCH 3/6] net/mlx: fix library search in meson build
On Fri, 2019-04-12 at 16:24 -0700, Yongseok Koh wrote:
> If MLNX_OFED is installed, there's no .pc file installed for
> libraries and
> dependency() can't find libraries by pkg-config. By adding fallback
> of
> using cc.find_library(), libraries are properly located.
>
> Fixes: e30b4e566f47 ("build: improve dependency handling")
> Cc:
> bl...@debian.org
>
> Cc:
> sta...@dpdk.org
>
>
> Signed-off-by: Yongseok Koh <
> ys...@mellanox.com
> >
> ---
> drivers/net/mlx4/meson.build | 19 +++
> drivers/net/mlx5/meson.build | 19 +++
> 2 files changed, 22 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/net/mlx4/meson.build
> b/drivers/net/mlx4/meson.build
> index de020701d1..9082f69f25 100644
> --- a/drivers/net/mlx4/meson.build
> +++ b/drivers/net/mlx4/meson.build
> @@ -13,21 +13,24 @@ if pmd_dlopen
> '-DMLX4_GLUE_VERSION="@0@"'.format(LIB_GLUE_VERSION),
> ]
> endif
> -libs = [
> - dependency('libmnl', required:false),
> - dependency('libmlx4', required:false),
> - dependency('libibverbs', required:false),
> -]
> +libs = [ 'libmnl', 'libmlx4', 'libibverbs' ]
> +lib_deps = []
> build = true
> foreach lib:libs
> - if not lib.found()
> + lib_dep = dependency(lib, required:false)
> + if not lib_dep.found()
> + lib_dep = cc.find_library(lib, required:false)
Doesn't this end up trying to link the test program to -llibmnl and
thus failing?
> + endif
> + if lib_dep.found()
> + lib_deps += [ lib_dep ]
> + else
> build = false
> endif
> endforeach
> # Compile PMD
> if build
> allow_experimental_apis = true
> - ext_deps += libs
> + ext_deps += lib_deps
> sources = files(
> 'mlx4.c',
> 'mlx4_ethdev.c',
> @@ -103,7 +106,7 @@ if pmd_dlopen and build
> dlopen_sources,
> include_directories: global_inc,
> c_args: cflags,
> - dependencies: libs,
> + dependencies: libs_deps,
> link_args: [
> '-Wl,-export-dynamic',
> '-Wl,-h,@0@'.format(LIB_GLUE),
--
Kind regards,
Luca Boccassi
Re: [dpdk-dev] [PATCH] examples/l3fwd: support separate buffer pool per port
Hello Ruifeng, > > > Hi Shreyansh, > > > -Original Message- > > From: Shreyansh Jain > > Sent: Monday, April 15, 2019 14:48 > > To: Ruifeng Wang (Arm Technology China) ; > > Ananyev, Konstantin ; dev@dpdk.org > > Cc: nd ; nd > > Subject: RE: [dpdk-dev] [PATCH] examples/l3fwd: support separate > buffer > > pool per port > > > > Hi Ruifeng, > > > > [...] > > > > > > > > > > For hardware backed pools, hardware access and exclusion are > > > expensive. By > > > > segregating pool/port/lcores it is possible to attain a conflict > free > > > path. This is > > > > the use-case this patch targets. > > > > And anyways, this is an optional feature. > > > > > > > > > Konstantin > > > > > > > > > > > In dual core test, both modes had nearly same performance. > > > > > > > > OK > > > > > > > > > > > > > > > > My setup only has two ports which is limited. > > > > > > Just want to know the per-port-pool mode has more performance > > gain > > > > > when many ports are bound to different cores? > > > > > > > > Yes, though not necessarily *many* - in my case, I had 4 ports and > > > even then > > > > about ~10% improvement was directly visible. I increased the port > > > count and > > > > I was able to touch about ~15%. I did pin each port to a separate > > > core, though. > > > > But again, important point is that without this feature enabled, I > > > didn't see > > > > any drop in performance. Did you observe any drop? > > > > > > > > > > No, no drop without the feature enabled in my test. > > > > So, in case this is an optional feature, it should be fine, right? > > (Obviously, assuming that my logical implementation is correct) > > > > At my end also, I saw no drop in performance without this feature > (Default) > > and a decent increase with this (with separate port-core combination) > on > > NXP platform. > > > > [...] > > Tested on LS2088A and observed 12% performance gain when 4 ports were > used. Thanks for verifying this. > I think sample_app_ug document should be updated to add the new option. Yes, indeed. I will send an updated version. > Acked-by: Ruifeng Wang > Thanks.
[dpdk-dev] [PATCH] doc: fix heading levels in bbdev test guide
The section "Test Vector files" should not be at the same level as
the main title "dpdk-test-bbdev Application".
Fixes: f714a18885a6 ("app/testbbdev: add test application for bbdev")
Cc: sta...@dpdk.org
Cc: amr.mokh...@intel.com
Signed-off-by: Thomas Monjalon
---
doc/guides/tools/testbbdev.rst | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/doc/guides/tools/testbbdev.rst b/doc/guides/tools/testbbdev.rst
index f3386472d..07da35e52 100644
--- a/doc/guides/tools/testbbdev.rst
+++ b/doc/guides/tools/testbbdev.rst
@@ -307,7 +307,7 @@ baseband_null device does not have to be defined explicitly
as it is created by
Test Vector files
-=
+-
Test Vector files contain the data which is used to set turbo decoder/encoder
parameters and buffers for validation purpose. New test vector files should be
@@ -316,7 +316,7 @@ the syntax of the test vector files is in the following
section.
Basic principles for test vector files
---
+~~
Line started with ``#`` is treated as a comment and is ignored.
If variable is a chain of values, values should be separated by a comma. If
@@ -351,7 +351,7 @@ documented in *rte_bbdev_op.h*
Turbo decoder test vectors template
+~~~
For turbo decoder it has to be always set to ``RTE_BBDEV_OP_TURBO_DEC``
@@ -528,7 +528,7 @@ Following statuses can be used:
Turbo encoder test vectors template
+~~~
For turbo encoder it has to be always set to ``RTE_BBDEV_OP_TURBO_ENC``
--
2.21.0
Re: [dpdk-dev] [PATCH] examples/l3fwd: support separate buffer pool per port
Hi Shreyansh, > > > I tried this patch on MacchiatoBin + 82599 NIC. > > > Compared with global-pool mode, per-port-pool mode showed slightly > > lower performance in single core test. > > > > That was my thought too - for the case when queues from multiple ports > > are handled by the same core > > it probably would only slowdown things. > > Thanks for your comments. > > This is applicable for cases where separate cores can handle separate ports - > each with their pools. (somehow I felt that message in commit > was adequate - I can rephrase if that is misleading) > > In case there is enough number of cores available for datapath, such > segregation can result in better performance - possibly because of > drop in pool and cache conflicts. > At least on some of NXP SoC, this resulted in over 15% improvement. > And, in other cases it didn't lead to any drop/negative-impact. If each core manages just one port, then yes definitely performance increase is expected. If that's the case you'd like enable, then can I suggest to have mempool per lcore not per port? I think it would be plausible for both cases: - one port per core (your case). - multiple ports per core. Konstantin > > > Wonder what is the use case for the patch and what is the performance > > gain you observed? > > For hardware backed pools, hardware access and exclusion are expensive. By > segregating pool/port/lcores it is possible to attain a conflict > free path. This is the use-case this patch targets. > And anyways, this is an optional feature. > > > Konstantin > > > > > In dual core test, both modes had nearly same performance. > > OK > > > > > > > My setup only has two ports which is limited. > > > Just want to know the per-port-pool mode has more performance gain > > when many ports are bound to different cores? > > Yes, though not necessarily *many* - in my case, I had 4 ports and even then > about ~10% improvement was directly visible. I increased the > port count and I was able to touch about ~15%. I did pin each port to a > separate core, though. > But again, important point is that without this feature enabled, I didn't see > any drop in performance. Did you observe any drop? > > > > > > > Used commands: > > > sudo ./examples/l3fwd/build/l3fwd -c 0x4 -w :01:00.0 -w > > :01:00.1 -- -P -p 3 --config='(0,0,2),(1,0,2)' --per-port-pool > > > sudo ./examples/l3fwd/build/l3fwd -c 0xc -w :01:00.0 -w > > :01:00.1 -- -P -p 3 --config='(0,0,2),(1,0,3)' --per-port-pool > > > > > > Regards, > > > /Ruifeng > > > > > [...]
Re: [dpdk-dev] [PATCH] net/ice: enable RSS for IPv4/IPv6 packets
> -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Leyi Rong > Sent: Monday, April 15, 2019 2:04 PM > To: Yang, Qiming ; Lu, Wenzhuo > > Cc: dev@dpdk.org; Rong, Leyi > Subject: [dpdk-dev] [PATCH] net/ice: enable RSS for IPv4/IPv6 packets > > Signed-off-by: Leyi Rong Acked-by: Qi Zhang Applied to dpdk-next-net-intel. Thanks Qi
Re: [dpdk-dev] [PATCH] net/i40e: fix crash when calling i40e_vsi_delete_mac
Hi,
> Now the macvlan filter list may be accessed in the same time by two
> different threads and may cause a lot of optional errors. This patch
> protects the macvlan filter access with a spinlock.
>
> Call Trace:
> #1 0x7ffb4cbe2e3c in i40e_vsi_delete_mac (vsi=vsi@entry=
> 0x400052804b40, addr=addr@entry=0x7ffb47672244) at /usr/src/
> debug/dpdk-18.11/drivers/net/i40e/i40e_ethdev.c:7266
> #2 0x7ffb4cbe342b in i40e_set_default_mac_addr (dev=,
> mac_addr=0x400052a6618d) at /usr/src/debug/dpdk-18.11/drivers/net/
> i40e/i40e_ethdev.c:11893
> #3 0x7ffb4f569d4a in rte_eth_dev_default_mac_addr_set (port_id=
> , addr=addr@entry=0x400052a6618d) at /usr/src/debug/
> dpdk-18.11/lib/librte_ethdev/rte_ethdev.c:3366
> #4 0x7ffb4d0bb403 in mac_address_slaves_update (bonded_eth_dev=
> bonded_eth_dev@entry=0xacf8c0 ) at /usr/src/debug/
> dpdk-18.11/drivers/net/bonding/rte_eth_bond_pmd.c:1854
> #5 0x7ffb4d0bd221 in bond_ethdev_lsc_event_callback (port_id=
> , type=, param=,
> ret_param= ) at /usr/src/debug/dpdk-18.11/drivers/
> net/bonding/rte_eth_bond_pmd.c:3076
> #6 0x7ffb4f56aa09 in _rte_eth_dev_callback_process (dev=dev@entry=
> 0xad3940 , event=event@entry=
> RTE_ETH_EVENT_INTR_LSC, ret_param=ret_param@entry=0x0)
> at /usr/src/debug/dpdk-18.11/lib/librte_ethdev/rte_ethdev.c:3699
> #7 0x7ffb4cbb99f1 in i40e_dev_handle_aq_msg (dev=dev@entry=0xad3940
> ) at /usr/src/debug/dpdk-18.11/drivers/net/
> i40e/i40e_ethdev.c:6573
> #8 0x7ffb4cbdfbed in i40e_dev_alarm_handler (param=0xad3940
> ) at /usr/src/debug/dpdk-18.11/drivers/net/
> i40e/i40e_ethdev.c:6681
> #9 0x7ffb4fb9766f in eal_alarm_callback (arg=) at
> /usr/src/debug/dpdk-18.11/lib/librte_eal/linuxapp/eal/eal_alarm.c:90
> #10 0x7ffb4fb95dd2 in eal_intr_process_interrupts (nfds= out>, events=) at /usr/src/debug/dpdk-18.11/lib/
> librte_eal/linuxapp/eal/eal_interrupts.c:886
> #11 eal_intr_handle_interrupts (totalfds=, pfd=20) at
> /usr/src/debug/dpdk-18.11/lib/librte_eal/linuxapp/eal/
> eal_interrupts.c:946
> #12 eal_intr_thread_main (arg=) at /usr/src/debug/
> dpdk-18.11/lib/librte_eal/linuxapp/eal/eal_interrupts.c:1035
> #13 0x7ffb4b208dd5 in start_thread () from /usr/lib64/libpthread.so.0
> #14 0x7ffb4981659d in clone () from /usr/lib64/libc.so.6
That is not specific to i40e or macvlan filter.
If inside your app several threads concurrently access/modify NIC config,
then you need to provide some synchronization mechanism for them.
DPDK ethdev API (as most others) on itself doesn't provide any synchronization,
leaving it up to the upper layer to choose the most appropriate one.
Konstantin
>
> Fixes: 4861cde46116 ("i40e: new poll mode driver")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Yunjian Wang
> ---
> drivers/net/i40e/i40e_ethdev.c | 28 +---
> drivers/net/i40e/i40e_ethdev.h | 1 +
> drivers/net/i40e/i40e_pf.c | 6 ++
> drivers/net/i40e/rte_pmd_i40e.c | 12
> 4 files changed, 44 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
> index 5b01dc1..e4f6818 100644
> --- a/drivers/net/i40e/i40e_ethdev.c
> +++ b/drivers/net/i40e/i40e_ethdev.c
> @@ -4036,8 +4036,9 @@ static int i40e_dev_xstats_get_names(__rte_unused
> struct rte_eth_dev *dev,
> vsi = pf->main_vsi;
> else
> vsi = pf->vmdq[pool - 1].vsi;
> -
> + rte_spinlock_lock(&vsi->mac_list_lock);
> ret = i40e_vsi_add_mac(vsi, &mac_filter);
> + rte_spinlock_unlock(&vsi->mac_list_lock);
> if (ret != I40E_SUCCESS) {
> PMD_DRV_LOG(ERR, "Failed to add MACVLAN filter");
> return -ENODEV;
> @@ -4075,7 +4076,9 @@ static int i40e_dev_xstats_get_names(__rte_unused
> struct rte_eth_dev *dev,
> }
> vsi = pf->vmdq[i - 1].vsi;
> }
> + rte_spinlock_lock(&vsi->mac_list_lock);
> ret = i40e_vsi_delete_mac(vsi, macaddr);
> + rte_spinlock_unlock(&vsi->mac_list_lock);
>
> if (ret) {
> PMD_DRV_LOG(ERR, "Failed to remove MACVLAN
> filter");
> @@ -4138,7 +4141,9 @@ static int i40e_dev_xstats_get_names(__rte_unused
> struct rte_eth_dev *dev,
>ETHER_ADDR_LEN);
>
> mac_filter.filter_type = filter->filter_type;
> + rte_spinlock_lock(&vf->vsi->mac_list_lock);
> ret = i40e_vsi_add_mac(vf->vsi, &mac_filter);
> + rte_spinlock_unlock(&vf->vsi->mac_list_lock);
> if (ret != I40E_SUCCESS) {
> PMD_DRV_LOG(ERR, "Failed to add MAC filter.");
> return -1;
> @@ -4147,7 +4152,9 @@ static int i40
Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
> -Original Message- > From: Stephen Hemminger [mailto:step...@networkplumber.org] > Sent: Saturday, April 13, 2019 12:06 AM > To: Honnappa Nagarahalli > Cc: Ananyev, Konstantin ; > paul...@linux.ibm.com; Kovacevic, Marko ; > dev@dpdk.org; Gavin Hu (Arm Technology China) ; Dharmik > Thakkar ; Malvika Gupta > ; nd > Subject: Re: [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism > > On Fri, 12 Apr 2019 22:24:45 + > Honnappa Nagarahalli wrote: > > > > > > > On Fri, 12 Apr 2019 15:20:37 -0500 > > > Honnappa Nagarahalli wrote: > > > > > > > Add RCU library supporting quiescent state based memory reclamation > > > method. > > > > This library helps identify the quiescent state of the reader threads > > > > so that the writers can free the memory associated with the lock less > > > > data structures. > > > > > > > > Signed-off-by: Honnappa Nagarahalli > > > > Reviewed-by: Steve Capper > > > > Reviewed-by: Gavin Hu > > > > Reviewed-by: Ola Liljedahl > > > > Acked-by: Konstantin Ananyev > > > > > > After evaluating long term API/ABI issues, I think you need to get rid of > > > almost > > > all use of inline and visible structures. Yes it might be marginally > > > slower, but > > > you thank me the first time you have to fix something. > > > > > Agree, I was planning on another version to address this (I am yet to take > > a look at your patch addressing the ABI). > > The structure visibility definitely needs to be addressed. > > For the inline functions, is the plan to convert all the inline functions > > in DPDK? If yes, I think we need to consider the performance > difference. May be consider L3-fwd application, change all the inline > functions in its path and run a test? > > Every function that is not in the direct datapath should not be inline. > Exceptions or things like rx/tx burst, ring enqueue/dequeue, and packet > alloc/free Plus synchronization routines: spin/rwlock/barrier, etc. I think rcu should be one of such exceptions - it is just another synchronization mechanism after all (just a bit more sophisticated). Konstantin
Re: [dpdk-dev] [PATCH v8 00/14] Add patch set for IPN3KE
On 4/15/2019 6:06 AM, Rosen Xu wrote: > v8 updates: > = > - Fix meter color definition replacement > > v7 updates: > = > - Fix Stephen comments > > v6 updates: > == > - Fix v5 comments > - Fix TM Shaper rate issue > > v5 updates: > == > - Fix EXPERIMENTAL symbol definition issue > > v4 updates: > == > - Fix coding style issues > > v3 updates: > == > - Fix v2 comments > - Update MAC BAR of AFU index get ops > - Remove OPAE share code dependency of libfdt > > v2 updates: > == > - Fix v1 comments > - Add support for 10G Base Line Design Bitstream > - Add support for 25G Base Line Design Bitstream > > This patch set adds the support of a new net PMD, Intel® FPGA Programmable > Acceleration Card N3000, also called ipn3ke. > > The ipn3ke PMD (librte_pmd_ipn3ke) provides poll mode driver support > for Intel® FPGA PAC(Programmable Acceleration Card) N3000 based on > the Intel Ethernet Controller X710/XXV710 and Intel Arria 10 FPGA. > > In this card, FPGA is an acceleration bridge between network interface > and the Intel Ethernet Controller. Although both FPGA and Ethernet > Controllers are connected to CPU with PCIe Gen3x16 Switch, all the > packet RX/TX is handled by Intel Ethernet Controller. So from application > point of view the data path is still the legacy Intel Ethernet Controller > X710/XXV710 PMD. Besides this, users can enable more acceleration > features by FPGA IP. > > > Rosen Xu (7): > bus/ifpga: add AFU shared data > bus/ifpga: add function for AFU search by name > net/ipn3ke: add IPN3KE ethdev PMD driver > net/ipn3ke: add IPN3KE representor of PMD driver > net/ipn3ke: add IPN3KE TM of PMD driver > net/ipn3ke: add IPN3KE Flow of PMD driver > raw/ifpga_rawdev: add IPN3KE support for IFPGA Rawdev > > Tianfei zhang (7): > raw/ifpga_rawdev: clean up code for ifpga share code > raw/ifpga_rawdev: store private features in FME and Port > raw/ifpga_rawdev: add SPI and MAX10 device driver > raw/ifpga_rawdev: add I2C and at24 EEPROM driver > raw/ifpga_rawdev: add eth group driver > raw/ifpga_rawdev: add version description on README > raw/ifpga_rawdev: using prefix name for feature and its ops Hi Rosen, Overall patchset looks good to me, only there are a few minor issues I have put comment on individual patches, can you please check them? Thanks, ferruh
Re: [dpdk-dev] [PATCH v8 02/14] bus/ifpga: add function for AFU search by name
On 4/15/2019 6:06 AM, Rosen Xu wrote:
> In many scenarios, AFU is needed searched by name, this
> function add the feature.
>
> Signed-off-by: Rosen Xu
> Signed-off-by: Andy Pei
> ---
> drivers/bus/ifpga/ifpga_bus.c | 13 +
> drivers/bus/ifpga/rte_bus_ifpga.h | 9 +
> drivers/bus/ifpga/rte_bus_ifpga_version.map | 6 ++
> 3 files changed, 28 insertions(+)
>
> diff --git a/drivers/bus/ifpga/ifpga_bus.c b/drivers/bus/ifpga/ifpga_bus.c
> index 55d3abf..8bfae29 100644
> --- a/drivers/bus/ifpga/ifpga_bus.c
> +++ b/drivers/bus/ifpga/ifpga_bus.c
> @@ -73,6 +73,19 @@ void rte_ifpga_driver_unregister(struct rte_afu_driver
> *driver)
> return NULL;
> }
>
> +struct rte_afu_device *__rte_experimental
> +rte_ifpga_find_afu_by_name(const char *name)
> +{
> + struct rte_afu_device *afu_dev = NULL;
> +
> + TAILQ_FOREACH(afu_dev, &ifpga_afu_dev_list, next) {
> + if (afu_dev &&
> + !strcmp(afu_dev->device.name, name))
> + return afu_dev;
> + }
> + return NULL;
> +}
> +
> static const char * const valid_args[] = {
> #define IFPGA_ARG_NAME "ifpga"
> IFPGA_ARG_NAME,
> diff --git a/drivers/bus/ifpga/rte_bus_ifpga.h
> b/drivers/bus/ifpga/rte_bus_ifpga.h
> index 820eeaa..c00f60e 100644
> --- a/drivers/bus/ifpga/rte_bus_ifpga.h
> +++ b/drivers/bus/ifpga/rte_bus_ifpga.h
> @@ -120,6 +120,15 @@ struct rte_afu_driver {
> }
>
> /**
> + * Find AFU by AFU name.
> + *
> + * @param name
> + * A pointer to AFU name string.
> + */
> +struct rte_afu_device *__rte_experimental
> +rte_ifpga_find_afu_by_name(const char *name);
> +
Hi Rosen,
This is the bus code, and only drivers will call it right? I think there is no
intention to make this run by application code, the functions need to be
exported because driver and bus are different libraries.
If above correct, there is no point of making the function experimental, can
drop the __rte_experimental tag, and update .map file to not use EXPERIMENTAL.
> +/**
> * Register a ifpga afu device driver.
> *
> * @param driver
> diff --git a/drivers/bus/ifpga/rte_bus_ifpga_version.map
> b/drivers/bus/ifpga/rte_bus_ifpga_version.map
> index a027979..247ccfe 100644
> --- a/drivers/bus/ifpga/rte_bus_ifpga_version.map
> +++ b/drivers/bus/ifpga/rte_bus_ifpga_version.map
> @@ -8,3 +8,9 @@ DPDK_18.05 {
>
> local: *;
> };
> +
> +EXPERIMENTAL {
> +global:
> +
> +rte_ifpga_find_afu_by_name;
> +};
> \ No newline at end of file
>
Re: [dpdk-dev] [PATCH v8 03/14] net/ipn3ke: add IPN3KE ethdev PMD driver
On 4/15/2019 6:06 AM, Rosen Xu wrote: > Add Intel FPGA Acceleration NIC IPN3KE ethdev PMD driver. > > Signed-off-by: Rosen Xu > Signed-off-by: Andy Pei > Signed-off-by: Dan Wei <...> > @@ -633,6 +633,12 @@ F: drivers/net/ice/ > F: doc/guides/nics/ice.rst > F: doc/guides/nics/features/ice.ini > > +Intel ipn3ke > +M: Rosen Xu > +T: git://dpdk.org/next/dpdk-next-net-intel > +F: drivers/net/ipn3ke/ > +F: doc/guides/nics/ipn3ke.rst > +F: doc/guides/nics/features/ipn3ke.ini > Marvell mvpp2 Please put an empty line after ipn3ke block. <...> > +Pre-Installation Configuration > +-- > + > +Config File Options > +~~~ > + > +The following options can be modified in the ``config`` file. > +Please note that enabling debugging options may affect system performance. There is no DEBUG option for driver, looks like copy/paste from other driver docs.
Re: [dpdk-dev] [PATCH v8 14/14] raw/ifpga_rawdev: add IPN3KE support for IFPGA Rawdev
On 4/15/2019 6:07 AM, Rosen Xu wrote:
> Add Intel FPGA Acceleration NIC IPN3KE support for IFPGA Rawdev.
>
> Signed-off-by: Rosen Xu
> Signed-off-by: Tianfei Zhang
> Signed-off-by: Andy Pei
<...>
> @@ -128,6 +137,45 @@
> return;
> }
> }
> +
> + /* get opae_manager to rawdev */
> + mgr = opae_adapter_get_mgr(adapter);
> + if (mgr) {
> + //get LineSide BAR Index
Please prefer c89 comments, /* */
<...>
> + }
> + if (!strcmp(attr_name, "NICSideLinkStatus")) {
> + /*
> + *
> + */
Please add some comments or drop.
> + return 0;
> + }
> + if (!strcmp(attr_name, "NICSideBARIndex")) {
> + /* eth_group 1 on FPGA connect to NicSide */
> + if (opae_manager_get_eth_group_region_info(mgr, 1,
> + &opae_eth_grp_reg_info))
> + return -1;
> + *attr_value = (uint64_t)opae_eth_grp_reg_info.mem_idx;
> + return 0;
> + }
> +
> + IFPGA_RAWDEV_PMD_ERR("attr_name not support");
It can be useful to print requested attr_name
<...>
> @@ -8,8 +8,8 @@
> extern int ifpga_rawdev_logtype;
>
> #define IFPGA_RAWDEV_PMD_LOG(level, fmt, args...) \
> - rte_log(RTE_LOG_ ## level, ifpga_rawdev_logtype, "%s(): " fmt "\n", \
> - __func__, ##args)
> + rte_log(RTE_LOG_ ## level, ifpga_rawdev_logtype, "ifpga_rawdev: " fmt, \
> + ##args)
Are you sure about this change? Another commit in this release [1] updates
"ifgpa" -> "%s", __func__; but this commit revert it back to "ifpga_rawdev: "
[1]
Fixes: a3a6a3d94f7e ("raw/ifpga: modify log output")
Cc: andy@intel.com
Re: [dpdk-dev] [PATCH v8 00/14] Add patch set for IPN3KE
> -Original Message- > From: Yigit, Ferruh > Sent: Monday, April 15, 2019 20:28 > To: Xu, Rosen ; dev@dpdk.org > Cc: Zhang, Tianfei ; Wei, Dan > ; Pei, Andy ; Yang, Qiming > ; Wang, Haiyue ; Chen, > Santos ; Zhang, Zhang ; > Lomartire, David ; Hu, Jia > Subject: Re: [PATCH v8 00/14] Add patch set for IPN3KE > > On 4/15/2019 6:06 AM, Rosen Xu wrote: > > v8 updates: > > = > > - Fix meter color definition replacement > > > > v7 updates: > > = > > - Fix Stephen comments > > > > v6 updates: > > == > > - Fix v5 comments > > - Fix TM Shaper rate issue > > > > v5 updates: > > == > > - Fix EXPERIMENTAL symbol definition issue > > > > v4 updates: > > == > > - Fix coding style issues > > > > v3 updates: > > == > > - Fix v2 comments > > - Update MAC BAR of AFU index get ops > > - Remove OPAE share code dependency of libfdt > > > > v2 updates: > > == > > - Fix v1 comments > > - Add support for 10G Base Line Design Bitstream > > - Add support for 25G Base Line Design Bitstream > > > > This patch set adds the support of a new net PMD, Intel® FPGA > > Programmable Acceleration Card N3000, also called ipn3ke. > > > > The ipn3ke PMD (librte_pmd_ipn3ke) provides poll mode driver support > > for Intel® FPGA PAC(Programmable Acceleration Card) N3000 based on the > > Intel Ethernet Controller X710/XXV710 and Intel Arria 10 FPGA. > > > > In this card, FPGA is an acceleration bridge between network interface > > and the Intel Ethernet Controller. Although both FPGA and Ethernet > > Controllers are connected to CPU with PCIe Gen3x16 Switch, all the > > packet RX/TX is handled by Intel Ethernet Controller. So from > > application point of view the data path is still the legacy Intel > > Ethernet Controller > > X710/XXV710 PMD. Besides this, users can enable more acceleration > > features by FPGA IP. > > > > > > Rosen Xu (7): > > bus/ifpga: add AFU shared data > > bus/ifpga: add function for AFU search by name > > net/ipn3ke: add IPN3KE ethdev PMD driver > > net/ipn3ke: add IPN3KE representor of PMD driver > > net/ipn3ke: add IPN3KE TM of PMD driver > > net/ipn3ke: add IPN3KE Flow of PMD driver > > raw/ifpga_rawdev: add IPN3KE support for IFPGA Rawdev > > > > Tianfei zhang (7): > > raw/ifpga_rawdev: clean up code for ifpga share code > > raw/ifpga_rawdev: store private features in FME and Port > > raw/ifpga_rawdev: add SPI and MAX10 device driver > > raw/ifpga_rawdev: add I2C and at24 EEPROM driver > > raw/ifpga_rawdev: add eth group driver > > raw/ifpga_rawdev: add version description on README > > raw/ifpga_rawdev: using prefix name for feature and its ops > > Hi Rosen, > > Overall patchset looks good to me, only there are a few minor issues I have > put comment on individual patches, can you please check them? > > Thanks, > ferruh Okay
Re: [dpdk-dev] [PATCH v8 02/14] bus/ifpga: add function for AFU search by name
Hi Ferruh,
> -Original Message-
> From: Yigit, Ferruh
> Sent: Monday, April 15, 2019 20:28
> To: Xu, Rosen ; dev@dpdk.org
> Cc: Zhang, Tianfei ; Wei, Dan
> ; Pei, Andy ; Yang, Qiming
> ; Wang, Haiyue ; Chen,
> Santos ; Zhang, Zhang ;
> Lomartire, David ; Hu, Jia ;
> Thomas Monjalon
> Subject: Re: [PATCH v8 02/14] bus/ifpga: add function for AFU search by
> name
>
> On 4/15/2019 6:06 AM, Rosen Xu wrote:
> > In many scenarios, AFU is needed searched by name, this function add
> > the feature.
> >
> > Signed-off-by: Rosen Xu
> > Signed-off-by: Andy Pei
> > ---
> > drivers/bus/ifpga/ifpga_bus.c | 13 +
> > drivers/bus/ifpga/rte_bus_ifpga.h | 9 +
> > drivers/bus/ifpga/rte_bus_ifpga_version.map | 6 ++
> > 3 files changed, 28 insertions(+)
> >
> > diff --git a/drivers/bus/ifpga/ifpga_bus.c
> > b/drivers/bus/ifpga/ifpga_bus.c index 55d3abf..8bfae29 100644
> > --- a/drivers/bus/ifpga/ifpga_bus.c
> > +++ b/drivers/bus/ifpga/ifpga_bus.c
> > @@ -73,6 +73,19 @@ void rte_ifpga_driver_unregister(struct
> rte_afu_driver *driver)
> > return NULL;
> > }
> >
> > +struct rte_afu_device *__rte_experimental
> > +rte_ifpga_find_afu_by_name(const char *name) {
> > + struct rte_afu_device *afu_dev = NULL;
> > +
> > + TAILQ_FOREACH(afu_dev, &ifpga_afu_dev_list, next) {
> > + if (afu_dev &&
> > + !strcmp(afu_dev->device.name, name))
> > + return afu_dev;
> > + }
> > + return NULL;
> > +}
> > +
> > static const char * const valid_args[] = {
> > #define IFPGA_ARG_NAME "ifpga"
> > IFPGA_ARG_NAME,
> > diff --git a/drivers/bus/ifpga/rte_bus_ifpga.h
> > b/drivers/bus/ifpga/rte_bus_ifpga.h
> > index 820eeaa..c00f60e 100644
> > --- a/drivers/bus/ifpga/rte_bus_ifpga.h
> > +++ b/drivers/bus/ifpga/rte_bus_ifpga.h
> > @@ -120,6 +120,15 @@ struct rte_afu_driver { }
> >
> > /**
> > + * Find AFU by AFU name.
> > + *
> > + * @param name
> > + * A pointer to AFU name string.
> > + */
> > +struct rte_afu_device *__rte_experimental
> > +rte_ifpga_find_afu_by_name(const char *name);
> > +
>
>
> Hi Rosen,
>
> This is the bus code, and only drivers will call it right? I think there is no
> intention to make this run by application code, the functions need to be
> exported because driver and bus are different libraries.
> If above correct, there is no point of making the function experimental, can
> drop the __rte_experimental tag, and update .map file to not use
> EXPERIMENTAL.
Yes, above is correct.
I will apply it in v9.
>
> > +/**
> > * Register a ifpga afu device driver.
> > *
> > * @param driver
> > diff --git a/drivers/bus/ifpga/rte_bus_ifpga_version.map
> > b/drivers/bus/ifpga/rte_bus_ifpga_version.map
> > index a027979..247ccfe 100644
> > --- a/drivers/bus/ifpga/rte_bus_ifpga_version.map
> > +++ b/drivers/bus/ifpga/rte_bus_ifpga_version.map
> > @@ -8,3 +8,9 @@ DPDK_18.05 {
> >
> > local: *;
> > };
> > +
> > +EXPERIMENTAL {
> > +global:
> > +
> > +rte_ifpga_find_afu_by_name;
> > +};
> > \ No newline at end of file
> >
[dpdk-dev] [PATCH] app/test: add unit test cases for mbuf library APIs
added new unit test cases for
rte_validate_tx_offload,
rte_pktmbuf_alloc_bulk,
rte_pktmbuf_read,
rte_pktmbuf_ext_shinfo_init_helper,
rte_pktmbuf_attach_extbuf,
rte_mbuf_ext_refcnt_read,
rte_mbuf_ext_refcnt_update,
rte_mbuf_ext_refcnt_set,
rte_pktmbuf_detach_extbuf
Signed-off-by: Lavanya Govindarajan
---
app/test/test_mbuf.c | 820 ++-
1 file changed, 817 insertions(+), 3 deletions(-)
diff --git a/app/test/test_mbuf.c b/app/test/test_mbuf.c
index 030385ec5..74259b313 100644
--- a/app/test/test_mbuf.c
+++ b/app/test/test_mbuf.c
@@ -28,16 +28,24 @@
#include
#include
#include
+#include
+#include
+#include
#include "test.h"
+#define MEMPOOL_CACHE_SIZE 32
#define MBUF_DATA_SIZE 2048
#define NB_MBUF 128
#define MBUF_TEST_DATA_LEN 1464
#define MBUF_TEST_DATA_LEN2 50
+#define MBUF_TEST_DATA_LEN3 256
#define MBUF_TEST_HDR1_LEN 20
#define MBUF_TEST_HDR2_LEN 30
#define MBUF_TEST_ALL_HDRS_LEN (MBUF_TEST_HDR1_LEN+MBUF_TEST_HDR2_LEN)
+#define MBUF_TEST_SEG_SIZE 64
+#define MBUF_TEST_BURST 8
+#define EXT_BUF_TEST_DATA_LEN 1024
/* size of private data for mbuf in pktmbuf_pool2 */
#define MBUF2_PRIV_SIZE 128
@@ -59,6 +67,21 @@ static unsigned refcnt_lcore[RTE_MAX_LCORE];
#endif
+/* Test flags for tx_offload capacity */
+enum test_mbuf_tx_ol_flag {
+ MBUF_TEST_INVALID_FLAG = 0,
+ MBUF_TEST_IP_CKSUM_IPV6_SET,
+ MBUF_TEST_IP_TYPE_NOT_SET,
+ MBUF_TEST_IP_TYPE_SET,
+ MBUF_TEST_NULL_TSO_SEGSZ,
+ MBUF_TEST_TSO_IP_CKSUM_NOT_SET,
+ MBUF_TEST_TSO_IPV6_SET,
+ MBUF_TEST_TSO_IP_CKSUM_SET,
+ MBUF_TEST_OUTER_IPV4_NOT_SET,
+ MBUF_TEST_OUTER_IPV4_SET,
+ MBUF_TEST_OL_MASK_NOT_SET
+};
+
/*
* MBUF
*
@@ -502,7 +525,6 @@ test_attach_from_different_pool(struct rte_mempool
*pktmbuf_pool,
rte_pktmbuf_free(clone2);
return -1;
}
-#undef GOTO_FAIL
/*
* test allocation and free of mbufs
@@ -1122,6 +1144,706 @@ test_tx_offload(void)
return (v1 == v2) ? 0 : -EINVAL;
}
+/*
+ * Test to validate tx offload flags in a packet
+ * - Allocate a mbuf and append header and data.
+ * - Set mbuf ol_flag (offload flag) to validate fragmented headers.
+ * - Validate if IP checksum is counted only for IPV4 packet.
+ * - Validate if IP type is set when PKT_TX_L4_MASK is set.
+ * - Test to confirm IP type is set when required.
+ * - Validate if TSO segment size is non zero when TCP_SEG is set.
+ * - Validate if IP checksum is set for TSO capability.
+ * - Test to confirm all the TSO packet requirements are met.
+ * - Validate if outer IP checksum set for non outer IPv4 packet.
+ * - Test to confirm outer IP checksum is set for outer IPV4 packet.
+ * - Confirm if packets with no PKT_TX_OFFLOAD_MASK are skipped.
+ */
+static int
+test_mbuf_validate_tx_offload(struct rte_mempool *pktmbuf_pool,
+ uint32_t test_ol_flag)
+{
+ struct rte_mbuf *m = NULL;
+ int ret = 0;
+
+ /* alloc a mbuf and do sanity check */
+ m = rte_pktmbuf_alloc(pktmbuf_pool);
+ if (m == NULL)
+ GOTO_FAIL("%s: mbuf allocation failed!\n", __func__);
+ if (rte_pktmbuf_pkt_len(m) != 0)
+ GOTO_FAIL("%s: Bad packet length\n", __func__);
+ rte_mbuf_sanity_check(m, 0);
+ m->ol_flags = 0;
+
+ switch (test_ol_flag) {
+ case MBUF_TEST_IP_CKSUM_IPV6_SET:
+ /* set both IP checksum and IPV6 flags */
+ m->ol_flags |= PKT_TX_IP_CKSUM;
+ m->ol_flags |= PKT_TX_IPV6;
+ ret = rte_validate_tx_offload(m);
+ if (ret != -EINVAL)
+ GOTO_FAIL("%s:Expected ret val: %d;recvd: %d\n",
+ __func__, -EINVAL, ret);
+ break;
+ case MBUF_TEST_IP_TYPE_NOT_SET:
+ /* test if any IP type is set */
+ m->ol_flags |= PKT_TX_L4_MASK;
+ ret = rte_validate_tx_offload(m);
+ if (ret != -EINVAL)
+ GOTO_FAIL("%s:Expected ret val: %d;recvd: %d\n",
+ __func__, -EINVAL, ret);
+ break;
+ case MBUF_TEST_IP_TYPE_SET:
+ /* test to confirm IP type (IPV4/IPV6) is set */
+ m->ol_flags |= PKT_TX_IPV6;
+ m->ol_flags |= PKT_TX_L4_MASK;
+ ret = rte_validate_tx_offload(m);
+ if (ret != 0)
+ GOTO_FAIL("%s:Expected ret val: 0; recvd: %d\n",
+ __func__, ret);
+ break;
+ case MBUF_TEST_NULL_TSO_SEGSZ:
+ /* test to check TSO segment size is non-zero */
+ m->ol_flags |= P
Re: [dpdk-dev] [PATCH v8 03/14] net/ipn3ke: add IPN3KE ethdev PMD driver
Hi Ferruh, > -Original Message- > From: Yigit, Ferruh > Sent: Monday, April 15, 2019 20:29 > To: Xu, Rosen ; dev@dpdk.org > Cc: Zhang, Tianfei ; Wei, Dan > ; Pei, Andy ; Yang, Qiming > ; Wang, Haiyue ; Chen, > Santos ; Zhang, Zhang ; > Lomartire, David ; Hu, Jia > Subject: Re: [PATCH v8 03/14] net/ipn3ke: add IPN3KE ethdev PMD driver > > On 4/15/2019 6:06 AM, Rosen Xu wrote: > > Add Intel FPGA Acceleration NIC IPN3KE ethdev PMD driver. > > > > Signed-off-by: Rosen Xu > > Signed-off-by: Andy Pei > > Signed-off-by: Dan Wei > > <...> > > > @@ -633,6 +633,12 @@ F: drivers/net/ice/ > > F: doc/guides/nics/ice.rst > > F: doc/guides/nics/features/ice.ini > > > > +Intel ipn3ke > > +M: Rosen Xu > > +T: git://dpdk.org/next/dpdk-next-net-intel > > +F: drivers/net/ipn3ke/ > > +F: doc/guides/nics/ipn3ke.rst > > +F: doc/guides/nics/features/ipn3ke.ini > > Marvell mvpp2 > > Please put an empty line after ipn3ke block. Fixed in v9. > <...> > > > +Pre-Installation Configuration > > +-- > > + > > +Config File Options > > +~~~ > > + > > +The following options can be modified in the ``config`` file. > > +Please note that enabling debugging options may affect system > performance. > > There is no DEBUG option for driver, looks like copy/paste from other driver > docs. Fixed in v9.
Re: [dpdk-dev] [PATCH 1/2] net/ice: code clean
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wang Ying A
> Sent: Friday, April 12, 2019 9:52 PM
> To: Lu, Wenzhuo ; Yang, Qiming
>
> Cc: dev@dpdk.org; Wang, Ying A ; sta...@dpdk.org
> Subject: [dpdk-dev] [PATCH 1/2] net/ice: code clean
Better to change title to "fix wrong type", since it's actually a bug fix.
>
> Variable "status" should be difined as "int" instead of "uint_16t".
> This patch fixes the issue.
Some typo
>
> Fixes: c945e4bf9063 ("net/ice: support promiscuous mode")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Wang Ying A
> ---
> drivers/net/ice/ice_ethdev.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ice/ice_ethdev.c b/drivers/net/ice/ice_ethdev.c index
> 9d01018..72831bb 100644
> --- a/drivers/net/ice/ice_ethdev.c
> +++ b/drivers/net/ice/ice_ethdev.c
> @@ -2753,7 +2753,7 @@ static int ice_macaddr_set(struct rte_eth_dev *dev,
> struct ice_hw *hw = ICE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> struct ice_vsi *vsi = pf->main_vsi;
> uint8_t pmask;
> - uint16_t status;
> + int status;
Can we use enum ice_status directly here?
Since I saw it will be compared with a enum value ICE_SUCCESS later.
>
> pmask = ICE_PROMISC_UCAST_RX | ICE_PROMISC_UCAST_TX |
> ICE_PROMISC_MCAST_RX | ICE_PROMISC_MCAST_TX; @@ -2769,7
> +2769,7 @@ static int ice_macaddr_set(struct rte_eth_dev *dev,
> struct ice_pf *pf = ICE_DEV_PRIVATE_TO_PF(dev->data->dev_private);
> struct ice_hw *hw = ICE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> struct ice_vsi *vsi = pf->main_vsi;
> - uint16_t status;
> + int status;
> uint8_t pmask;
>
> pmask = ICE_PROMISC_UCAST_RX | ICE_PROMISC_UCAST_TX | @@
> -2787,7 +2787,7 @@ static int ice_macaddr_set(struct rte_eth_dev *dev,
> struct ice_hw *hw = ICE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> struct ice_vsi *vsi = pf->main_vsi;
> uint8_t pmask;
> - uint16_t status;
> + int status;
>
> pmask = ICE_PROMISC_MCAST_RX | ICE_PROMISC_MCAST_TX;
>
> @@ -2802,7 +2802,7 @@ static int ice_macaddr_set(struct rte_eth_dev *dev,
> struct ice_pf *pf = ICE_DEV_PRIVATE_TO_PF(dev->data->dev_private);
> struct ice_hw *hw = ICE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> struct ice_vsi *vsi = pf->main_vsi;
> - uint16_t status;
> + int status;
> uint8_t pmask;
>
> if (dev->data->promiscuous == 1)
> --
> 1.8.3.1
Re: [dpdk-dev] [PATCH] net/i40e: fix crash when calling i40e_vsi_delete_mac
> -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ananyev, Konstantin > Sent: Monday, April 15, 2019 8:21 PM > To: wangyunjian ; dev@dpdk.org > Cc: xudin...@huawei.com; sta...@dpdk.org > Subject: Re: [dpdk-dev] [PATCH] net/i40e: fix crash when calling > i40e_vsi_delete_mac > > Hi, > > > Now the macvlan filter list may be accessed in the same time by two > > different threads and may cause a lot of optional errors. This patch > > protects the macvlan filter access with a spinlock. > > > > Call Trace: > > #1 0x7ffb4cbe2e3c in i40e_vsi_delete_mac (vsi=vsi@entry= > > 0x400052804b40, addr=addr@entry=0x7ffb47672244) at /usr/src/ > > debug/dpdk-18.11/drivers/net/i40e/i40e_ethdev.c:7266 > > #2 0x7ffb4cbe342b in i40e_set_default_mac_addr (dev= out>, > > mac_addr=0x400052a6618d) at > /usr/src/debug/dpdk-18.11/drivers/net/ > > i40e/i40e_ethdev.c:11893 > > #3 0x7ffb4f569d4a in rte_eth_dev_default_mac_addr_set (port_id= > > , addr=addr@entry=0x400052a6618d) at > /usr/src/debug/ > > dpdk-18.11/lib/librte_ethdev/rte_ethdev.c:3366 > > #4 0x7ffb4d0bb403 in mac_address_slaves_update > (bonded_eth_dev= > > bonded_eth_dev@entry=0xacf8c0 ) at > /usr/src/debug/ > > dpdk-18.11/drivers/net/bonding/rte_eth_bond_pmd.c:1854 > > #5 0x7ffb4d0bd221 in bond_ethdev_lsc_event_callback (port_id= > > , type=, param=, > > ret_param= ) at /usr/src/debug/dpdk-18.11/drivers/ > > net/bonding/rte_eth_bond_pmd.c:3076 > > #6 0x7ffb4f56aa09 in _rte_eth_dev_callback_process > (dev=dev@entry= > > 0xad3940 , event=event@entry= > > RTE_ETH_EVENT_INTR_LSC, ret_param=ret_param@entry=0x0) > > at /usr/src/debug/dpdk-18.11/lib/librte_ethdev/rte_ethdev.c:3699 > > #7 0x7ffb4cbb99f1 in i40e_dev_handle_aq_msg > (dev=dev@entry=0xad3940 > > ) at > /usr/src/debug/dpdk-18.11/drivers/net/ > > i40e/i40e_ethdev.c:6573 > > #8 0x7ffb4cbdfbed in i40e_dev_alarm_handler (param=0xad3940 > > ) at > /usr/src/debug/dpdk-18.11/drivers/net/ > > i40e/i40e_ethdev.c:6681 > > #9 0x7ffb4fb9766f in eal_alarm_callback (arg=) at > > > /usr/src/debug/dpdk-18.11/lib/librte_eal/linuxapp/eal/eal_alarm.c:90 > > #10 0x7ffb4fb95dd2 in eal_intr_process_interrupts (nfds= > out>, events=) at /usr/src/debug/dpdk-18.11/lib/ > > librte_eal/linuxapp/eal/eal_interrupts.c:886 > > #11 eal_intr_handle_interrupts (totalfds=, pfd=20) at > > /usr/src/debug/dpdk-18.11/lib/librte_eal/linuxapp/eal/ > > eal_interrupts.c:946 > > #12 eal_intr_thread_main (arg=) at /usr/src/debug/ > > dpdk-18.11/lib/librte_eal/linuxapp/eal/eal_interrupts.c:1035 > > #13 0x7ffb4b208dd5 in start_thread () from > /usr/lib64/libpthread.so.0 > > #14 0x7ffb4981659d in clone () from /usr/lib64/libc.so.6 > > That is not specific to i40e or macvlan filter. > If inside your app several threads concurrently access/modify NIC config, then > you need to provide some synchronization mechanism for them. > DPDK ethdev API (as most others) on itself doesn't provide any > synchronization, > leaving it up to the upper layer to choose the most appropriate one. > Konstantin +1
Re: [dpdk-dev] [PATCH v8 14/14] raw/ifpga_rawdev: add IPN3KE support for IFPGA Rawdev
Hi Ferruh,
> -Original Message-
> From: Yigit, Ferruh
> Sent: Monday, April 15, 2019 20:29
> To: Xu, Rosen ; dev@dpdk.org
> Cc: Zhang, Tianfei ; Wei, Dan
> ; Pei, Andy ; Yang, Qiming
> ; Wang, Haiyue ; Chen,
> Santos ; Zhang, Zhang ;
> Lomartire, David ; Hu, Jia
> Subject: Re: [PATCH v8 14/14] raw/ifpga_rawdev: add IPN3KE support for
> IFPGA Rawdev
>
> On 4/15/2019 6:07 AM, Rosen Xu wrote:
> > Add Intel FPGA Acceleration NIC IPN3KE support for IFPGA Rawdev.
> >
> > Signed-off-by: Rosen Xu
> > Signed-off-by: Tianfei Zhang
> > Signed-off-by: Andy Pei
>
> <...>
>
> > @@ -128,6 +137,45 @@
> > return;
> > }
> > }
> > +
> > + /* get opae_manager to rawdev */
> > + mgr = opae_adapter_get_mgr(adapter);
> > + if (mgr) {
> > + //get LineSide BAR Index
>
> Please prefer c89 comments, /* */
Fixed in v9.
> <...>
>
> > + }
> > + if (!strcmp(attr_name, "NICSideLinkStatus")) {
> > + /*
> > +*
> > +*/
>
> Please add some comments or drop.
Dropped in v9.
> > + return 0;
> > + }
> > + if (!strcmp(attr_name, "NICSideBARIndex")) {
> > + /* eth_group 1 on FPGA connect to NicSide */
> > + if (opae_manager_get_eth_group_region_info(mgr, 1,
> > + &opae_eth_grp_reg_info))
> > + return -1;
> > + *attr_value = (uint64_t)opae_eth_grp_reg_info.mem_idx;
> > + return 0;
> > + }
> > +
> > + IFPGA_RAWDEV_PMD_ERR("attr_name not support");
>
> It can be useful to print requested attr_name
Added in v9.
> <...>
>
> > @@ -8,8 +8,8 @@
> > extern int ifpga_rawdev_logtype;
> >
> > #define IFPGA_RAWDEV_PMD_LOG(level, fmt, args...) \
> > - rte_log(RTE_LOG_ ## level, ifpga_rawdev_logtype, "%s(): " fmt "\n", \
> > - __func__, ##args)
> > + rte_log(RTE_LOG_ ## level, ifpga_rawdev_logtype, "ifpga_rawdev: "
> fmt, \
> > + ##args)
>
> Are you sure about this change? Another commit in this release [1] updates
> "ifgpa" -> "%s", __func__; but this commit revert it back to "ifpga_rawdev: "
>
> [1]
> Fixes: a3a6a3d94f7e ("raw/ifpga: modify log output")
> Cc: andy@intel.com
Thanks you reminder, dropped this change in v9.
Re: [dpdk-dev] [EXT] [PATCH 2/6] meson: change default cache line size for cortex-a72
> > > > > > > > > > -- Per the email discussion [1], the default cache line size of > > > armv8 > > > cortex-a72 is changed to 64 bytes. > > > > IMO, In git commit you remove the reference to specific discussion and > > Update the reason correctly. > > > > > > > > > > [1] https://mails.dpdk.org/archives/dev/2019-January/123218.html > > > > > > Signed-off-by: Yongseok Koh > > > --- > > > config/arm/meson.build | 4 +++- > > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > > > diff --git a/config/arm/meson.build b/config/arm/meson.build index > > > e00b894523..73c581948c 100644 > > > --- a/config/arm/meson.build > > > +++ b/config/arm/meson.build > > > @@ -51,6 +51,8 @@ flags_dpaa2 = [ > > > ['RTE_MAX_LCORE', 16], > > > ['RTE_LIBRTE_DPAA2_USE_PHYS_IOVA', false]] flags_default_extra > > = [] > > > +flags_cortex_a72_extra = [ > > > + ['RTE_CACHE_LINE_SIZE', 64]] > > > flags_thunderx_extra = [ > Which tree does this patch apply to? I do not see the above line in master. Please ignore this comment, I missed the dependency provided in 0/6 > > > > ['RTE_MACHINE', '"thunderx"'], > > > ['RTE_USE_C11_MEM_MODEL', false]] > > > @@ -73,7 +75,7 @@ machine_args_generic = [ > > > ['0xd03', ['-mcpu=cortex-a53']], > > > ['0xd04', ['-mcpu=cortex-a35']], > > > ['0xd07', ['-mcpu=cortex-a57']], > > > - ['0xd08', ['-mcpu=cortex-a72']], > > > + ['0xd08', ['-mcpu=cortex-a72'], flags_cortex_a72_extra], > > > ['0xd09', ['-mcpu=cortex-a73']], > > > ['0xd0a', ['-mcpu=cortex-a75']]] > > > > I think, flags_cortex_a72_extra() can be changed to > > flags_vendor_arm_extra or something similar And update the following > > CPUs also not just cortex-a72. > > > Why not add 'flags_arm' similar to flags_dpaa2/flag_cavium etc? All the > listed Arm cores are 64B cache line size. Just to complete the thought, impl_0x41 can use 'flags_arm' instead of 'flags_generic'. IMO, current use of 'flags_generic' in impl_0x41 is incorrect. > > > ['0xd03', ['-mcpu=cortex-a53']], > > ['0xd04', ['-mcpu=cortex-a35']], > > ['0xd05', ['-mcpu=cortex-a55']], > > ['0xd07', ['-mcpu=cortex-a57']], > > ['0xd08', ['-mcpu=cortex-a72']], > > ['0xd09', ['-mcpu=cortex-a73']], > > ['0xd0a', ['-mcpu=cortex-a75']], > > ['0xd0b', ['-mcpu=cortex-a76']], > > > > > > > > > > -- > > > 2.21.0.196.g041f5ea
Re: [dpdk-dev] [PATCH] examples/vm_power_manager: fix string overflow
On 10/4/2019 3:54 PM, Reshma Pattan wrote:
Use strlcpy instead of strcpy to fix string overflow.
Coverity issue: 337671
Fixes: a63504a90f ("examples/power: add JSON string handling")
CC: david.h...@intel.com
CC: sta...@dpdk.org
Signed-off-by: Reshma Pattan
---
examples/vm_power_manager/channel_monitor.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/examples/vm_power_manager/channel_monitor.c
b/examples/vm_power_manager/channel_monitor.c
index 74df0fe20..0b44a74b5 100644
--- a/examples/vm_power_manager/channel_monitor.c
+++ b/examples/vm_power_manager/channel_monitor.c
@@ -159,7 +159,8 @@ parse_json_to_pkt(json_t *element, struct channel_packet
*pkt)
if (ret)
return ret;
} else if (!strcmp(key, "name")) {
- strcpy(pkt->vm_name, json_string_value(value));
+ strlcpy(pkt->vm_name, json_string_value(value),
+ sizeof(pkt->vm_name));
} else if (!strcmp(key, "command")) {
char command[32];
strlcpy(command, json_string_value(value), 32);
Acked-by: David Hunt
Re: [dpdk-dev] [PATCH 2/2] net/af_xdp: make reserve/submit peek/release consistent
Hi, David
Thanks for you detailed review comment.
On 04/15, David Marchand wrote:
>On Fri, Apr 12, 2019 at 4:54 PM Xiaolong Ye wrote:
>
>> As David pointed out, if we reserve N slots, but only submit n slots,
>> we would end up with an incorrect opinion of the number of available slots
>> later, we also would get wrong idx when we call xsk_ring_prod__reserve next
>> time. It also applies to xsk_ring_cons__peek()/xsk_ring_cons__release().
>>
>> This patch ensures that both reserve/submit and peek/release are
>> consistent.
>>
>> Fixes: f1debd77efaf ("net/af_xdp: introduce AF_XDP PMD")
>>
>> Reported-by: David Marchand
>> Signed-off-by: Xiaolong Ye
>> ---
>> drivers/net/af_xdp/rte_eth_af_xdp.c | 80 +++--
>> 1 file changed, 41 insertions(+), 39 deletions(-)
>>
>> diff --git a/drivers/net/af_xdp/rte_eth_af_xdp.c
>> b/drivers/net/af_xdp/rte_eth_af_xdp.c
>> index 5cc643ce2..76a6a8331 100644
>> --- a/drivers/net/af_xdp/rte_eth_af_xdp.c
>> +++ b/drivers/net/af_xdp/rte_eth_af_xdp.c
>> @@ -138,22 +138,19 @@ reserve_fill_queue(struct xsk_umem_info *umem, int
>> reserve_size)
>> {
>> struct xsk_ring_prod *fq = &umem->fq;
>> uint32_t idx;
>> - int i, ret;
>> -
>> - ret = xsk_ring_prod__reserve(fq, reserve_size, &idx);
>> - if (unlikely(!ret)) {
>> - AF_XDP_LOG(ERR, "Failed to reserve enough fq descs.\n");
>> - return ret;
>> - }
>> + int i;
>>
>> for (i = 0; i < reserve_size; i++) {
>> __u64 *fq_addr;
>> void *addr = NULL;
>> if (rte_ring_dequeue(umem->buf_ring, &addr)) {
>> - i--;
>> break;
>> }
>> - fq_addr = xsk_ring_prod__fill_addr(fq, idx++);
>> + if (unlikely(!xsk_ring_prod__reserve(fq, 1, &idx))) {
>> + AF_XDP_LOG(WARNING, "Failed to reserve 1 fq
>> desc.\n");
>> + break;
>> + }
>> + fq_addr = xsk_ring_prod__fill_addr(fq, idx);
>> *fq_addr = (uint64_t)addr;
>> }
>>
>>
>I just spotted that reserve_fill_queue always returns 0.
>I understand that xsk_configure expects an errors when not succeeding in
>populating this ring.
>And for this, it expects a non zero value for this.
You are right, reserve_fill_queue does need retrun a non zero value when
it fails to populate the ring.
>
>How about something like (neither tested nor compiled):
>
>static inline int
>reserve_fill_queue(struct xsk_umem_info *umem, int reserve_size)
>{
>struct xsk_ring_prod *fq = &umem->fq;
>void *addrs[reserve_size];
>uint32_t idx;
>int i, ret;
>
>if (rte_ring_dequeue_bulk(umem->buf_ring, &addrs, reserve_size, NULL)
>!= reserve_size) {
>AF_XDP_LOG(DEBUG, "Failed to get enough buffers for fq.\n");
>return -1;
>}
>
>ret = xsk_ring_prod__reserve(fq, reserve_size, &idx);
>if (unlikely(!ret)) {
>AF_XDP_LOG(DEBUG, "Failed to reserve enough fq descs.\n");
>rte_ring_enqueue_bulk(umem->buf_ring, &addrs, reserve_size,
> NULL);
>return -1;
>}
>
>for (i = 0; i < reserve_size; i++) {
>__u64 *fq_addr;
>
>fq_addr = xsk_ring_prod__fill_addr(fq, idx++);
>*fq_addr = (uint64_t)addrs[i];
>}
>
>xsk_ring_prod__submit(fq, reserve_size);
>
>return 0;
>}
Sounds better, I'll adopt it in my new version.
>
>
>
>@@ -179,6 +176,9 @@ eth_af_xdp_rx(void *queue, struct rte_mbuf **bufs,
>> uint16_t nb_pkts)
>>
>> nb_pkts = RTE_MIN(nb_pkts, ETH_AF_XDP_TX_BATCH_SIZE);
>>
>> + if (unlikely(rte_pktmbuf_alloc_bulk(rxq->mb_pool, mbufs, nb_pkts)
>> != 0))
>> + return 0;
>> +
>> rcvd = xsk_ring_cons__peek(rx, nb_pkts, &idx_rx);
>> if (rcvd == 0)
>> return 0;
>>
>
>When xsk_ring_cons__peek() returns 0, we will leak nb_pkts freshly
>allocated mbufs.
>See below for a suggestion.
>
>
>@@ -186,9 +186,6 @@ eth_af_xdp_rx(void *queue, struct rte_mbuf **bufs,
>> uint16_t nb_pkts)
>> if (xsk_prod_nb_free(fq, free_thresh) >= free_thresh)
>> (void)reserve_fill_queue(umem, ETH_AF_XDP_RX_BATCH_SIZE);
>>
>> - if (unlikely(rte_pktmbuf_alloc_bulk(rxq->mb_pool, mbufs, rcvd) !=
>> 0))
>> - return 0;
>> -
>> for (i = 0; i < rcvd; i++) {
>> const struct xdp_desc *desc;
>> uint64_t addr;
>> @@ -211,6 +208,10 @@ eth_af_xdp_rx(void *queue, struct rte_mbuf **bufs,
>> uint16_t nb_pkts)
>>
>> xsk_ring_cons__release(rx, rcvd);
>>
>> + /* free the extra mbufs */
>> + for (; rcvd < nb_pkts; rcvd++)
>> + rte_pktmbuf_free(mbufs[rcvd]);
>> +
>>
>
>You can move this block after the statistic update...
>
>
>/* statistics */
>> rxq->stats.rx_pkts += (rcvd - dropped);
>> rxq->stats.rx_bytes += rx_bytes;
>>
>
>... then define a out: la
[dpdk-dev] [PATCH] net/virtio: fix dangling pointer on failure
When eth_virtio_dev_init() is cleaning up, it does not correctly set
the mac_addrs variable to NULL, which will lead to a double free.
Found during unit-test fixes.
Fixes: 43d18765c027 ("net/virtio: fix memory leak on failure")
Cc: sta...@dpdk.org
Reported-by: Michael Santana
Signed-off-by: Aaron Conole
---
drivers/net/virtio/virtio_ethdev.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/virtio/virtio_ethdev.c
b/drivers/net/virtio/virtio_ethdev.c
index 2272bb2e5..d25c08f0a 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -1862,6 +1862,7 @@ eth_virtio_dev_init(struct rte_eth_dev *eth_dev)
out:
rte_free(eth_dev->data->mac_addrs);
+ eth_dev->data->mac_addrs = NULL;
return ret;
}
--
2.19.1
Re: [dpdk-dev] [PATCH] examples/vm_power_manager: fix string null termination
On 9/4/2019 5:00 PM, Reshma Pattan wrote:
After the read() the jason_data null termination is missing
for the case "indent < 0", for "indent > 0" and "indent == 0"
cases null termination is already handled.
So add the missing case "indent < 0" to the existing "indent == 0"
case to fix null termination.
Coverity issue: 337680
Fixes: a63504a90f ("examples/power: add JSON string handling")
CC: david.h...@intel.com
CC: sta...@dpdk.org
Signed-off-by: Reshma Pattan
---
examples/vm_power_manager/channel_monitor.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/examples/vm_power_manager/channel_monitor.c
b/examples/vm_power_manager/channel_monitor.c
index 74df0fe20..c67ca4710 100644
--- a/examples/vm_power_manager/channel_monitor.c
+++ b/examples/vm_power_manager/channel_monitor.c
@@ -807,7 +807,7 @@ read_json_packet(struct channel_info *chan_info)
indent--;
if ((indent > 0) || (idx > 0))
idx++;
- if (indent == 0)
+ if (indent <= 0)
json_data[idx] = 0;
if (idx >= MAX_JSON_STRING_LEN-1)
break;
Acked-by: David Hunt
[dpdk-dev] [PATCH v2 1/3] examples/fips: fix hmac test failure
Application was failing as the HMAC and
Plain SHA fips request files are similar in a
way that they both have SHA- in the top section to
determine the hash algo and hash sizes. And HMAC having the
algo in the second line but the Plain SHA in the third
meant that when the HMAC files was used once it parsed the third
line Plain SHA was set as the algo and not HMAC.
USER1: Failed to get capability for cdev 0
USER1: Error -22: test block
[L=20 SHAAlg=SHA_2]
USER1: Error -22: Failed test /root/FIPS/HMAC/req/HMAC.req
Fixes: f4797bae0050 ("examples/fips_validation: support plain SHA")
Cc: damianx.no...@intel.com
Signed-off-by: Marko Kovacevic
---
v2:
Fixed checkpatch warning
---
examples/fips_validation/fips_validation.c | 80 +-
1 file changed, 45 insertions(+), 35 deletions(-)
diff --git a/examples/fips_validation/fips_validation.c
b/examples/fips_validation/fips_validation.c
index 2f8314fcc..8d43b267e 100644
--- a/examples/fips_validation/fips_validation.c
+++ b/examples/fips_validation/fips_validation.c
@@ -98,6 +98,7 @@ fips_test_parse_header(void)
uint32_t i;
char *tmp;
int ret;
+ int algo_parsed = 0;
time_t t = time(NULL);
struct tm *tm_now = localtime(&t);
@@ -106,41 +107,50 @@ fips_test_parse_header(void)
return ret;
for (i = 0; i < info.nb_vec_lines; i++) {
- if (strstr(info.vec[i], "AESVS")) {
- info.algo = FIPS_TEST_ALGO_AES;
- ret = parse_test_aes_init();
- if (ret < 0)
- return ret;
- } else if (strstr(info.vec[i], "GCM")) {
- info.algo = FIPS_TEST_ALGO_AES_GCM;
- ret = parse_test_gcm_init();
- if (ret < 0)
- return ret;
- } else if (strstr(info.vec[i], "CMAC")) {
- info.algo = FIPS_TEST_ALGO_AES_CMAC;
- ret = parse_test_cmac_init();
- if (ret < 0)
- return 0;
- } else if (strstr(info.vec[i], "CCM")) {
- info.algo = FIPS_TEST_ALGO_AES_CCM;
- ret = parse_test_ccm_init();
- if (ret < 0)
- return 0;
- } else if (strstr(info.vec[i], "HMAC")) {
- info.algo = FIPS_TEST_ALGO_HMAC;
- ret = parse_test_hmac_init();
- if (ret < 0)
- return ret;
- } else if (strstr(info.vec[i], "TDES")) {
- info.algo = FIPS_TEST_ALGO_TDES;
- ret = parse_test_tdes_init();
- if (ret < 0)
- return 0;
- } else if (strstr(info.vec[i], "SHA-")) {
- info.algo = FIPS_TEST_ALGO_SHA;
- ret = parse_test_sha_init();
- if (ret < 0)
- return ret;
+ if (!algo_parsed) {
+ if (strstr(info.vec[i], "AESVS")) {
+ algo_parsed = 1;
+ info.algo = FIPS_TEST_ALGO_AES;
+ ret = parse_test_aes_init();
+ if (ret < 0)
+ return ret;
+ } else if (strstr(info.vec[i], "GCM")) {
+ algo_parsed = 1;
+ info.algo = FIPS_TEST_ALGO_AES_GCM;
+ ret = parse_test_gcm_init();
+ if (ret < 0)
+ return ret;
+ } else if (strstr(info.vec[i], "CMAC")) {
+ algo_parsed = 1;
+ info.algo = FIPS_TEST_ALGO_AES_CMAC;
+ ret = parse_test_cmac_init();
+ if (ret < 0)
+ return 0;
+ } else if (strstr(info.vec[i], "CCM")) {
+ algo_parsed = 1;
+ info.algo = FIPS_TEST_ALGO_AES_CCM;
+ ret = parse_test_ccm_init();
+ if (ret < 0)
+ return 0;
+ } else if (strstr(info.vec[i], "HMAC")) {
+ algo_parsed = 1;
+ info.algo = FIPS_TEST_ALGO_HMAC;
+ ret = parse_test_hmac_init();
+ if (ret < 0)
+ return ret;
+ } else if (strstr(info.vec[i], "TDES")) {
+ algo_parsed = 1;
+
[dpdk-dev] [PATCH v2 3/3] cryptodev: fix uninitialized session clear
added check to see if a session for a device
has been initialised if it has return 0.
Fixes: 5d6c73dd5938 ("cryptodev: add reference count to session private data")
Cc: roy.fan.zh...@intel.com
Cc: sta...@dpdk.org
Signed-off-by: Marko Kovacevic
---
lib/librte_cryptodev/rte_cryptodev.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/librte_cryptodev/rte_cryptodev.c
b/lib/librte_cryptodev/rte_cryptodev.c
index 2675e1ef7..00c2cf432 100644
--- a/lib/librte_cryptodev/rte_cryptodev.c
+++ b/lib/librte_cryptodev/rte_cryptodev.c
@@ -1386,6 +1386,8 @@ rte_cryptodev_sym_session_clear(uint8_t dev_id,
return -EINVAL;
driver_id = dev->driver_id;
+ if (sess->sess_data[driver_id].refcnt == 0)
+ return 0;
if (--sess->sess_data[driver_id].refcnt != 0)
return -EBUSY;
--
2.13.6
[dpdk-dev] [PATCH v2 2/3] examples/fips_validation: fix cmac test failure
As a result of the cmac test running the test where
PT len is 65536 it should give a result back to the
user USER1: Error -1: Prepare op USER1: PT len 65536
as this MSG len is not supported. Issue was
that the application was not freeing the op properly after
a while causing the app to fail.
CRYPTODEV: rte_cryptodev_sym_session_create() line 1340:
couldn't get object from session mempool
USER1: Error -12: test block
USER1: Error -12: Failed test CMAC/req/CMAC.req
Fixes: cd255ccf5764 ("examples/fips_validation: support AES parsing")
Cc: marko.kovace...@intel.com
Cc: sta...@dpdk.org
Signed-off-by: Marko Kovacevic
---
examples/fips_validation/main.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/examples/fips_validation/main.c b/examples/fips_validation/main.c
index 5e3d5baa8..aef45055e 100644
--- a/examples/fips_validation/main.c
+++ b/examples/fips_validation/main.c
@@ -949,19 +949,20 @@ fips_run_test(void)
if (ret < 0) {
RTE_LOG(ERR, USER1, "Error %i: Init session\n",
ret);
- return ret;
+ goto exit;
}
ret = test_ops.prepare_op();
if (ret < 0) {
RTE_LOG(ERR, USER1, "Error %i: Prepare op\n",
ret);
- return ret;
+ goto exit;
}
if (rte_cryptodev_enqueue_burst(env.dev_id, 0, &env.op, 1) < 1) {
RTE_LOG(ERR, USER1, "Error: Failed enqueue\n");
- return ret;
+ ret = -1;
+ goto exit;
}
do {
@@ -973,6 +974,7 @@ fips_run_test(void)
vec.status = env.op->status;
+exit:
rte_cryptodev_sym_session_clear(env.dev_id, env.sess);
rte_cryptodev_sym_session_free(env.sess);
env.sess = NULL;
--
2.13.6
Re: [dpdk-dev] [PATCH v2] doc: updated json sample code for fifo interface
On 29/3/2019 10:22 AM, Lukasz Krakowiak wrote:
Updated doc for JSON sample code related to vm_power_manager
fifo interface: "command": "destroy", "command": "power".
Corrected typo in doc vm_power_management.rst: 'json' instead
of 'jason'.
---
v2:
* coding style improved
Signed-off-by: Lukasz Krakowiak
---
doc/guides/sample_app_ug/vm_power_management.rst | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/doc/guides/sample_app_ug/vm_power_management.rst
b/doc/guides/sample_app_ug/vm_power_management.rst
index 14d432e78..0182a92b3 100644
--- a/doc/guides/sample_app_ug/vm_power_management.rst
+++ b/doc/guides/sample_app_ug/vm_power_management.rst
@@ -384,7 +384,7 @@ the file.
The fifo is at /tmp/powermonitor/fifo
-The jason string can be a policy or instruction, and takes the following
+The json string can be a policy or instruction, and takes the following
format:
.. code-block:: javascript
@@ -597,7 +597,7 @@ Profile destroy example:
.. code-block:: javascript
-{"profile": {
+{"policy": {
"name": "ubuntu",
"command": "destroy",
}}
@@ -606,8 +606,9 @@ Power command example:
.. code-block:: javascript
-{"command": {
+{"instruction": {
"name": "ubuntu",
+ "command": "power",
"unit": "SCALE_MAX",
"resource_id": 10
}}
Acked-by: David Hunt
Re: [dpdk-dev] [PATCH v2 2/3] test: remove prefix _acpi from UT power function/test names
On 3/4/2019 11:32 AM, Lukasz Krakowiak wrote: This patch remove prefix _acpi from power UT function/test names. Signed-off-by: Lukasz Krakowiak --- I would agree with Thomas, this patch should probably be merged with the file rename patch. Rgds, Dave.
Re: [dpdk-dev] [PATCH v2 3/3] test: add UT for power turbo feature
On 3/4/2019 11:32 AM, Lukasz Krakowiak wrote:
Add UT check_power_turbo.
Signed-off-by: Lukasz Krakowiak
---
app/test/test_power_cpufreq.c | 72 +++
1 file changed, 72 insertions(+)
diff --git a/app/test/test_power_cpufreq.c b/app/test/test_power_cpufreq.c
index d099f2f47..d203810da 100644
--- a/app/test/test_power_cpufreq.c
+++ b/app/test/test_power_cpufreq.c
@@ -366,6 +366,59 @@ check_power_freq_min(void)
return 0;
}
+/* Check rte_power_turbo() */
+static int
+check_power_turbo(void)
+{
+ int ret;
+
+ if (rte_power_turbo_status(TEST_POWER_LCORE_ID) == 0) {
+ printf("Turbo not available on lcore %u, skipping test\n",
+ TEST_POWER_LCORE_ID);
+ return 0;
+ }
+
+ /* test with an invalid lcore id */
+ ret = rte_power_freq_enable_turbo(TEST_POWER_LCORE_INVALID);
+ if (ret >= 0) {
+ printf("Unexpectedly enable turbo successfully on lcore %u\n",
+ TEST_POWER_LCORE_INVALID);
+ return -1;
+ }
+ ret = rte_power_freq_enable_turbo(TEST_POWER_LCORE_ID);
+ if (ret < 0) {
+ printf("Fail to enable turbo on lcore %u\n",
+ TEST_POWER_LCORE_ID);
+ return -1;
+ }
+
+ /* Check the current frequency */
+ ret = check_cur_freq(TEST_POWER_LCORE_ID, 0);
+ if (ret < 0)
+ return -1;
+
+ /* test with an invalid lcore id */
+ ret = rte_power_freq_disable_turbo(TEST_POWER_LCORE_INVALID);
+ if (ret >= 0) {
+ printf("Unexpectedly disable turbo successfully on lcore %u\n",
+ TEST_POWER_LCORE_INVALID);
+ return -1;
+ }
+ ret = rte_power_freq_disable_turbo(TEST_POWER_LCORE_ID);
+ if (ret < 0) {
+ printf("Fail to disable turbo on lcore %u\n",
+ TEST_POWER_LCORE_ID);
+ return -1;
+ }
+
+ /* Check the current frequency */
+ ret = check_cur_freq(TEST_POWER_LCORE_ID, 1);
+ if (ret < 0)
+ return -1;
+
+ return 0;
+}
+
static int
test_power_cpufreq(void)
{
@@ -427,6 +480,21 @@ test_power_cpufreq(void)
"been initialised\n");
goto fail_all;
}
+ if (rte_power_turbo_status == NULL) {
+ printf("rte_power_turbo_status should not be NULL, environment has
not "
+ "been initialised\n");
+ goto fail_all;
+ }
+ if (rte_power_freq_enable_turbo == NULL) {
+ printf("rte_power_freq_enable_turbo should not be NULL, environment
has not "
+ "been initialised\n");
+ goto fail_all;
+ }
+ if (rte_power_freq_disable_turbo == NULL) {
+ printf("rte_power_freq_disable_turbo should not be NULL, environment
has not "
+ "been initialised\n");
+ goto fail_all;
+ }
ret = rte_power_exit(TEST_POWER_LCORE_ID);
if (ret < 0) {
@@ -502,6 +570,10 @@ test_power_cpufreq(void)
if (ret < 0)
goto fail_all;
+ ret = check_power_turbo();
+ if (ret < 0)
+ goto fail_all;
+
ret = rte_power_exit(TEST_POWER_LCORE_ID);
if (ret < 0) {
printf("Cannot exit power management for lcore %u\n",
Acked-by: David Hunt
Re: [dpdk-dev] [PATCH v2 2/3] test: remove prefix _acpi from UT power function/test names
On 03/04/2019 11:32, Lukasz Krakowiak wrote: > This patch remove prefix _acpi from power UT function/test names. > Hi, why is it better? Asking because it might mean you have to send some future fixes separately to stable branches. > Signed-off-by: Lukasz Krakowiak > ---
Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
On Mon, 15 Apr 2019 12:24:47 + "Ananyev, Konstantin" wrote: > > -Original Message- > > From: Stephen Hemminger [mailto:step...@networkplumber.org] > > Sent: Saturday, April 13, 2019 12:06 AM > > To: Honnappa Nagarahalli > > Cc: Ananyev, Konstantin ; > > paul...@linux.ibm.com; Kovacevic, Marko ; > > dev@dpdk.org; Gavin Hu (Arm Technology China) ; Dharmik > > Thakkar ; Malvika Gupta > > ; nd > > Subject: Re: [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism > > > > On Fri, 12 Apr 2019 22:24:45 + > > Honnappa Nagarahalli wrote: > > > > > > > > > > On Fri, 12 Apr 2019 15:20:37 -0500 > > > > Honnappa Nagarahalli wrote: > > > > > > > > > Add RCU library supporting quiescent state based memory reclamation > > > > method. > > > > > This library helps identify the quiescent state of the reader threads > > > > > so that the writers can free the memory associated with the lock less > > > > > data structures. > > > > > > > > > > Signed-off-by: Honnappa Nagarahalli > > > > > Reviewed-by: Steve Capper > > > > > Reviewed-by: Gavin Hu > > > > > Reviewed-by: Ola Liljedahl > > > > > Acked-by: Konstantin Ananyev > > > > > > > > After evaluating long term API/ABI issues, I think you need to get rid > > > > of almost > > > > all use of inline and visible structures. Yes it might be marginally > > > > slower, but > > > > you thank me the first time you have to fix something. > > > > > > > Agree, I was planning on another version to address this (I am yet to > > > take a look at your patch addressing the ABI). > > > The structure visibility definitely needs to be addressed. > > > For the inline functions, is the plan to convert all the inline functions > > > in DPDK? If yes, I think we need to consider the performance > > difference. May be consider L3-fwd application, change all the inline > > functions in its path and run a test? > > > > Every function that is not in the direct datapath should not be inline. > > Exceptions or things like rx/tx burst, ring enqueue/dequeue, and packet > > alloc/free > > Plus synchronization routines: spin/rwlock/barrier, etc. > I think rcu should be one of such exceptions - it is just another > synchronization mechanism after all > (just a bit more sophisticated). > Konstantin If you look at the other userspace RCU, you wil see that the only inlines are the rcu_read_lock,rcu_read_unlock and rcu_reference/rcu_assign_pointer. The synchronization logic is all real functions.
Re: [dpdk-dev] [PATCH] eal: fix large multiple calculation in reciprocal division
On Sun, 14 Apr 2019 10:52:59 +0530
wrote:
> + int64_t i;
Since i only does 1..64 it can be int.
> + uint64_t t;
> +
> + for (i = 1; i <= 64; i++) {
> + t = x >> 63;
> + x = (x << 1) | (y >> 63);
> + y = y << 1;
> + if ((x | t) >= z) {
> + x = x - z;
> + y = y + 1;
Re: [dpdk-dev] [PATCH v1] test/ticketlock: implement ticketlock autotest
> -Original Message-
> From: dev On Behalf Of Joyce Kong
> Sent: Monday, April 15, 2019 5:05 PM
> To: dev@dpdk.org
> Cc: nd ; tho...@monjalon.net;
> david.march...@redhat.com; step...@networkplumber.org;
> jerin.ja...@caviumnetworks.com; konstantin.anan...@intel.com;
> Honnappa Nagarahalli ; Gavin Hu (Arm
> Technology China)
> Subject: [dpdk-dev] [PATCH v1] test/ticketlock: implement ticketlock
> autotest
>
> Add ticketlock_autotest implementation in python.
>
> Fixes: efbcdaa55b93 ("test/ticketlock: add test cases")
>
> Signed-off-by: Joyce Kong
> ---
> app/test/autotest_data.py | 2 +-
> app/test/autotest_test_funcs.py | 34
> ++
> 2 files changed, 35 insertions(+), 1 deletion(-)
>
> diff --git a/app/test/autotest_data.py b/app/test/autotest_data.py index
> db25274..72c56e5 100644
> --- a/app/test/autotest_data.py
> +++ b/app/test/autotest_data.py
> @@ -175,7 +175,7 @@
> "Command": "ticketlock_autotest",
> "Func":ticketlock_autotest,
> "Report": None,
> -}
> +},
> {
> "Name":"Byte order autotest",
> "Command": "byteorder_autotest", diff --git
> a/app/test/autotest_test_funcs.py b/app/test/autotest_test_funcs.py
> index 65fe335..31cc0f5 100644
> --- a/app/test/autotest_test_funcs.py
> +++ b/app/test/autotest_test_funcs.py
> @@ -131,6 +131,40 @@ def rwlock_autotest(child, test_name):
> return 0, "Success"
>
>
> +def ticketlock_autotest(child, test_name):
> +i = 0
> +ir = 0
> +child.sendline(test_name)
> +while True:
> +index = child.expect(["Test OK",
> + "Test Failed",
> + "Hello from core ([0-9]*) !",
> + "Hello from within recursive locks "
> + "from ([0-9]*) !",
> + pexpect.TIMEOUT], timeout=5)
> +# ok
> +if index == 0:
> +break
> +
> +# message, check ordering
> +elif index == 2:
> +if int(child.match.groups()[0]) < i:
> +return -1, "Fail [Bad order]"
> +i = int(child.match.groups()[0])
> +elif index == 3:
> +if int(child.match.groups()[0]) < ir:
> +return -1, "Fail [Bad order]"
> +ir = int(child.match.groups()[0])
> +
> +# fail
> +elif index == 4:
> +return -1, "Fail [Timeout]"
> +elif index == 1:
> +return -1, "Fail"
> +
> +return 0, "Success"
> +
> +
> def logs_autotest(child, test_name):
> child.sendline(test_name)
>
> --
> 2.7.4
Hi,
Reviewed-by: Phil Yang
Tested-by: Phil Yang
# python ./app/test/autotest.py x86_64-native-linuxapp-gcc/app/test
./x86_64-native-linuxapp-gcc Ticketlock autotest
x86_64-native-linuxapp-gcc/app/test -c f -n 4
Running tests with 4 workers
Test name Test result TestTotal
Parallel autotests:
Start test2: Success [00m 00s][00m
00s]
Start test1: Success [00m 00s][00m
00s]
Start test0: Success [00m 01s][00m
01s]
Start test3: Success [00m 01s][00m
01s]
Ticketlock autotest: Success [00m 00s][00m 01s]
Total run time: 00m 01s
# python ./app/test/autotest.py arm64-armv8a-linuxapp-gcc/app/test
./arm64-armv8a-linuxapp-gcc Ticketlock autotest
arm64-armv8a-linuxapp-gcc/app/test -c f -n 4
Running tests with 4 workers
Test name Test result TestTotal
Parallel autotests:
Start test0: Success [00m 00s][00m
00s]
Start test1: Success [00m 00s][00m
00s]
Start test3: Success [00m 00s][00m
00s]
Start test2: Success [00m 00s][00m
00s]
Ticketlock autotest: Success [00m 00s][00m 00s]
Total run time: 00m 00s
Thanks,
Phil
Re: [dpdk-dev] [PATCH v2] kni: implement header_ops parse method
On 4/15/2019 9:37 AM, Igor Ryzhov wrote:
> Hi Ferruh,
>
> To be absolutely sure, I performed a test using the test application.
>
> When I send pings from an interface:
> 3: ens8: mtu 1500 qdisc pfifo_fast state
> UP mode DEFAULT group default qlen 1000
> link/ether 52:54:00:c8:79:c6 brd ff:ff:ff:ff:ff:ff
>
> Here is what's in sockaddr_ll:
> $2 = {sll_family = 0x11, sll_protocol = 0x8, sll_ifindex = 0x2, sll_hatype
> = 0x1, sll_pkttype = 0x0, sll_halen = 0x6, sll_addr = {
> 0x52, 0x54, 0x0, 0xc8, 0x79, 0xc6, 0x0, 0x0}}
>
> So everything works as expected – the address in sll_addr is correct.
> Last two bytes are zero because the length of sll_addr is 8, however,
> Ethernet length is 6.
Perfect, thanks for confirming, I am OK with the patch.
For my case sll_halen = 0x6 but only first 4 byte of the sll_addr was the valid,
so it was not the issue of size of sll_addr being 8, anyway it was quick dirty
app, something should be wrong, I believe not need to dig it more.
>
> Igor
>
> On Fri, Apr 12, 2019 at 8:15 PM Ferruh Yigit wrote:
>
>> On 4/12/2019 6:12 PM, Igor Ryzhov wrote:
>>> Hi Ferruh,
>>>
>>> I didn't test it with any special application, but FRR's ISIS works for
>> me after
>>> the patch, and it didn't work before.
>>
>> That is good enough, and by work you mean that you are able to get correct
>> value
>> on 'sll_addr', right?
>>
>>>
>>> Igor
>>>
>>> On Fri, Apr 12, 2019 at 5:53 PM Ferruh Yigit >> > wrote:
>>>
>>> On 4/12/2019 3:52 PM, Ferruh Yigit wrote:
>>> > On 4/10/2019 11:30 AM, Igor Ryzhov wrote:
>>> >> It allows applications running packet sockets over KNI interfaces
>> to get
>>> >> source Ethernet addresses of packets received using recvfrom
>> function.
>>> >>
>>> >> Signed-off-by: Igor Ryzhov > iryz...@nfware.com>>
>>> >
>>> > Acked-by: Ferruh Yigit >> >
>>> >
>>> >
>>> > Hi Igor,
>>> >
>>> > I tested this with a quick application on top of kni interfaces,
>> that
>>> reads and
>>> > prints the 'sll_halen', but the last two bytes of the mac address
>> are always
>>>
>>> I mean 'sll_addr', 'sll_halen' is right (6).
>>>
>>> > zero, it is quite possible that something is not right in the test
>> app, but
>>> > before spending any time on it, can you please confirm this is
>> working
>>> fine for you?
>>> >
>>>
>>
>>
Re: [dpdk-dev] [PATCH v3] power: update for handling fifo path string
Hi Lukasz,
On 15/4/2019 11:01 AM, Lukasz Gosiewski wrote:
From: Lukasz Krakowiak
Removed doubled created fifo path string for channel info.
---
v3:
*improvement to coding style
v2:
* rebase to master changes
Signed-off-by: Lukasz Krakowiak
Signed-off-by: Lukasz Gosiewski
---
examples/vm_power_manager/channel_manager.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/examples/vm_power_manager/channel_manager.c
b/examples/vm_power_manager/channel_manager.c
index 0187f79ab..05c0eea44 100644
--- a/examples/vm_power_manager/channel_manager.c
+++ b/examples/vm_power_manager/channel_manager.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
@@ -362,8 +363,6 @@ setup_host_channel_info(struct channel_info **chan_info_dptr,
chan_info->status = CHANNEL_MGR_CHANNEL_DISCONNECTED;
chan_info->type = CHANNEL_TYPE_JSON;
- fifo_path(chan_info->channel_path, sizeof(chan_info->channel_path));
-
if (open_host_channel(chan_info) < 0) {
RTE_LOG(ERR, CHANNEL_MANAGER, "Could not open host channel: "
"'%s'\n",
@@ -563,8 +562,8 @@ add_host_channel(void)
"channel '%s'\n", socket_path);
return 0;
}
- strlcpy(chan_info->channel_path, socket_path,
- sizeof(chan_info->channel_path));
+ rte_strlcpy(chan_info->channel_path, socket_path, UNIX_PATH_MAX);
+
if (setup_host_channel_info(&chan_info, 0) < 0) {
rte_free(chan_info);
return 0;
I'm not seeing this patch in patchwork, I'm seeing the original v1 from
Lukasz K. Can you try re-sending to mailing list? If it's not in
patchwork, it won't get applied.
Rgds,
Dave.
Re: [dpdk-dev] [PATCH] ethdev: fix QinQ strip offload support
On Sun, 14 Apr 2019 16:41:42 +0530
wrote:
>
> + cur = !!(offload_mask & ETH_QINQ_STRIP_OFFLOAD);
> + org = !!(dev->data->dev_conf.rxmode.offloads &
> + DEV_RX_OFFLOAD_QINQ_STRIP);
> + if (cur != org) {
> + if (cur)
> + dev->data->dev_conf.rxmode.offloads |=
> + DEV_RX_OFFLOAD_QINQ_STRIP;
> + else
> + dev->data->dev_conf.rxmode.offloads &=
> + ~DEV_RX_OFFLOAD_QINQ_STRIP;
> + mask |= ETH_QINQ_STRIP_MASK;
> + }
> +
> /*no change*/
Using a local (pointer) variable for dev->data->dev_conf.rxmode.offloads
would make the code more readable and lines shorter.
Re: [dpdk-dev] [PATCH] ethdev: missing typecast from void in eth_dev_pci_specific_init
On 4/12/2019 10:31 PM, Stephen Hemminger wrote:
> On Fri, 12 Apr 2019 18:29:46 +0100
> Ferruh Yigit wrote:
>
>> On 4/12/2019 6:25 PM, Ferruh Yigit wrote:
>>> On 4/12/2019 6:15 PM, Ananyev, Konstantin wrote:
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ferruh Yigit
> Sent: Friday, April 12, 2019 6:09 PM
> To: Stephen Hemminger ; Richardson, Bruce
>
> Cc: David Christensen ; tho...@monjalon.net;
> arybche...@solarflare.com; dev@dpdk.org;
> radhika.chi...@ibm.com; sta...@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] ethdev: missing typecast from void in
> eth_dev_pci_specific_init
>
> On 4/11/2019 12:08 AM, Stephen Hemminger wrote:
>> On Wed, 10 Apr 2019 22:00:18 +0100
>> Bruce Richardson wrote:
>>
>>> On Wed, Apr 10, 2019 at 03:16:16PM -0500, David Christensen wrote:
The function eth_dev_pci_specific_init is missing a typecast to
(struct rte_pci_device *) for the input argument bus_device.
Cc: sta...@dpdk.org
Signed-off-by: David Christensen
Tested-by: Radhika Chirra
---
lib/librte_ethdev/rte_ethdev_pci.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/librte_ethdev/rte_ethdev_pci.h
b/lib/librte_ethdev/rte_ethdev_pci.h
index 23257e9..a325311 100644
--- a/lib/librte_ethdev/rte_ethdev_pci.h
+++ b/lib/librte_ethdev/rte_ethdev_pci.h
@@ -72,7 +72,7 @@
static inline int
eth_dev_pci_specific_init(struct rte_eth_dev *eth_dev, void
*bus_device) {
- struct rte_pci_device *pci_dev = bus_device;
+ struct rte_pci_device *pci_dev = (struct rte_pci_device
*)bus_device;
>>>
>>> Is this needed for building some C++ apps that are including the header
>>> file (directly, or indirectly), because for pure C, "void *" types
>>> should
>>> be assignable to any other pointer type without casting?
>>>
>>> /Bruce
>>
>> Another example of Why the Hell is this inline?
>>
>
> It has been done inline intentionally at the time as far as remember, this
> header is for drivers not for applications, it has helper functions.
>
> The common code from drivers related to the bus put into header files, so
> the
> code itself belongs to drivers not ethdev and reduces duplicates in them.
>
Ok that's the common code used by the drivers...
But why it still can't be in .c file?
>>>
>>> When it is in .c file, it will be either in ethdev library, single location
>>> in
>>> .c file and binary file, but location is not exactly right, because code
>>> belongs
>>> to drivers.
>>> Or code should be in .c files of each drivers, this will be code
>>> duplication.
>>>
>>> Having in .h file makes code in single place, but when compiled code will
>>> be in
>>> each driver object file/ library.
>>>
>>> Of course it works when put into a .c file in ehtdev, but bus (pci and vdev)
>>> related code are not belongs to ethdev library and I believe shouldn't be
>>> part
>>> of ethdev binary. And those bus helper headers are only for drivers to
>>> include,
>>> so having inline shouldn't be a problem at all because there is not
>>> stability
>>> concern in that interface.
>>>
>>
>> btw, if you put those into .c file in ethdev, you will be creating a
>> dependency
>> from ethdev to bus code, to all available buses which will make impossible to
>> disable any bus type if you use ethdev.
>
> The problem I see is rte_ethdev_pci.h, it should be headers only and then put
> code rte_ethdev_pci.c
>
Where this 'rte_ethdev_pci.c' should be? Because of reasons explained above,
ehtdev is not good place.
Perhaps a 'common' folder for net drivers may work, create a 'rte_ethdev_pci.o'
and link it with relevant drivers.?
Re: [dpdk-dev] [PATCH] lib/librte_power: set new frequecy on turbo_disable
Acked-by: Liang Ma
On 12 Apr 16:57, Lee Daly wrote:
> This patch will ensure the correct max frequency of a core is set in
> the lcore_power_info struct when disabling turbo, while using the
> intel pstate driver.
>
> Fixes: e6c6dc0f96c8 ("power: add p-state driver compatibility")
> Cc: liang.j...@intel.com
> Cc: sta...@dpdk.org
>
> Signed-off-by: Lee Daly
> ---
> lib/librte_power/power_pstate_cpufreq.c | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/lib/librte_power/power_pstate_cpufreq.c
> b/lib/librte_power/power_pstate_cpufreq.c
> index 336c13869..d2ac75123 100644
> --- a/lib/librte_power/power_pstate_cpufreq.c
> +++ b/lib/librte_power/power_pstate_cpufreq.c
> @@ -810,7 +810,15 @@ power_pstate_disable_turbo(unsigned int lcore_id)
>
> pi->turbo_enable = 0;
>
> -
> + if ((pi->turbo_available) && (pi->curr_idx <= 1)) {
> + /* Try to set freq to max by default coming out of turbo */
> + if (power_pstate_cpufreq_freq_max(lcore_id) < 0) {
> + RTE_LOG(ERR, POWER,
> + "Failed to set frequency of lcore %u to max\n",
> + lcore_id);
> + return -1;
> + }
> + }
> return 0;
> }
>
> --
> 2.17.1
>
Re: [dpdk-dev] [PATCH] lib/librte_power: set new frequecy on turbo_disable
On Mon, 15 Apr 2019 17:11:10 +0100
"Liang, Ma" wrote:
> > pi->turbo_enable = 0;
> >
> > -
> > + if ((pi->turbo_available) && (pi->curr_idx <= 1)) {
You (don't) need (so many) parenthesis.
Re: [dpdk-dev] [PATCH] examples/vm_power: add conditional compilation for PMD specific code
On 02/04/2019 19:14, David Christensen wrote: I think it should have Fixes: and probably stable tags. > Signed-off-by: David Christensen > --- > Running the devtools/test-build.sh script on IBM Power systems fails > because the IXGBE_PMD is explicity disabled for Power as an untested > driver, but the examples/vm_power_manager application has a hard > dependency on a function call in the IXGBE_PMD. > > Modify the example application so that all dependencies on PMD code > are conditionally compiled. > > examples/vm_power_manager/main.c | 13 + > 1 file changed, 13 insertions(+)
Re: [dpdk-dev] [PATCH v4 1/3] rcu: add RCU library supporting QSBR mechanism
> > > >
> > > > On Wed, Apr 10, 2019 at 06:20:04AM -0500, Honnappa Nagarahalli
> > wrote:
> > > > > Add RCU library supporting quiescent state based memory
> > > > > reclamation
> > > > method.
> > > > > This library helps identify the quiescent state of the reader
> > > > > threads so that the writers can free the memory associated with
> > > > > the lock less data structures.
> > > >
> > > > I don't see any sign of read-side markers (rcu_read_lock() and
> > > > rcu_read_unlock() in the Linux kernel, userspace RCU, etc.).
> > > >
> > > > Yes, strictly speaking, these are not needed for QSBR to operate,
> > > > but they
> > > These APIs would be empty for QSBR.
> > >
> > > > make it way easier to maintain and debug code using RCU. For
> > > > example, given the read-side markers, you can check for errors like
> > > > having a call to
> > > > rte_rcu_qsbr_quiescent() in the middle of a reader quite easily.
> > > > Without those read-side markers, life can be quite hard and you will
> > > > really hate yourself for failing to have provided them.
> > >
> > > Want to make sure I understood this, do you mean the application
> > would mark before and after accessing the shared data structure on the
> > reader side?
> > >
> > > rte_rcu_qsbr_lock()
> > >
> > > ...
> > > ...
> > >
> > > rte_rcu_qsbr_unlock()
> >
> > Yes, that is the idea.
> >
> > > If someone is debugging this code, they have to make sure that there is
> > an unlock for every lock and there is no call to rte_rcu_qsbr_quiescent in
> > between.
> > > It sounds good to me. Obviously, they will not add any additional cycles
> > as well.
> > > Please let me know if my understanding is correct.
> >
> > Yes. And in some sort of debug mode, you could capture the counter at
> > rte_rcu_qsbr_lock() time and check it at rte_rcu_qsbr_unlock() time. If the
> > counter has advanced too far (more than one, if I am not too confused)
> > there is a bug. Also in debug mode, you could have rte_rcu_qsbr_lock()
> > increment a per-thread counter and rte_rcu_qsbr_unlock() decrement it.
> > If the counter is non-zero at a quiescent state, there is a bug.
> > And so on.
> >
> Added this in V5
>
>
>
> > > > > +
> > > > > +/* Get the memory size of QSBR variable */ size_t
> > > > > +__rte_experimental rte_rcu_qsbr_get_memsize(uint32_t
> > max_threads) {
> > > > > + size_t sz;
> > > > > +
> > > > > + if (max_threads == 0) {
> > > > > + rte_log(RTE_LOG_ERR, rcu_log_type,
> > > > > + "%s(): Invalid max_threads %u\n",
> > > > > + __func__, max_threads);
> > > > > + rte_errno = EINVAL;
> > > > > +
> > > > > + return 1;
> > > > > + }
> > > > > +
> > > > > + sz = sizeof(struct rte_rcu_qsbr);
> > > > > +
> > > > > + /* Add the size of quiescent state counter array */
> > > > > + sz += sizeof(struct rte_rcu_qsbr_cnt) * max_threads;
> > > > > +
> > > > > + /* Add the size of the registered thread ID bitmap array */
> > > > > + sz += RTE_QSBR_THRID_ARRAY_SIZE(max_threads);
> > > > > +
> > > > > + return RTE_ALIGN(sz, RTE_CACHE_LINE_SIZE);
> > > >
> > > > Given that you align here, should you also align in the earlier
> > > > steps in the computation of sz?
> > >
> > > Agree. I will remove the align here and keep the earlier one as the intent
> > is to align the thread ID array.
> >
> > Sounds good!
> Added this in V5
>
> >
> > > > > +}
> > > > > +
> > > > > +/* Initialize a quiescent state variable */ int
> > > > > +__rte_experimental rte_rcu_qsbr_init(struct rte_rcu_qsbr *v,
> > uint32_t max_threads) {
> > > > > + size_t sz;
> > > > > +
> > > > > + if (v == NULL) {
> > > > > + rte_log(RTE_LOG_ERR, rcu_log_type,
> > > > > + "%s(): Invalid input parameter\n", __func__);
> > > > > + rte_errno = EINVAL;
> > > > > +
> > > > > + return 1;
> > > > > + }
> > > > > +
> > > > > + sz = rte_rcu_qsbr_get_memsize(max_threads);
> > > > > + if (sz == 1)
> > > > > + return 1;
> > > > > +
> > > > > + /* Set all the threads to offline */
> > > > > + memset(v, 0, sz);
> > > >
> > > > We calculate sz here, but it looks like the caller must also
> > > > calculate it in order to correctly allocate the memory referenced by
> > > > the "v" argument to this function, with bad things happening if the
> > > > two calculations get different results. Should "v" instead be
> > > > allocated within this function to avoid this sort of problem?
> > >
> > > Earlier version allocated the memory with-in this library. However, it was
> > decided to go with the current implementation as it provides flexibility for
> > the application to manage the memory as it sees fit. For ex: it could
> > allocate this as part of another structure in a single allocation. This also
> > falls inline with similar approach taken in other libraries.
> >
> > So the allocator APIs vary too much to allow a pointer to the desire
Re: [dpdk-dev] [PATCH v5 0/3] lib/rcu: add RCU library supporting QSBR mechanism
Hi quys, > -Original Message- > From: Honnappa Nagarahalli [mailto:honnappa.nagaraha...@arm.com] > Sent: Friday, April 12, 2019 9:21 PM > To: Ananyev, Konstantin ; > step...@networkplumber.org; paul...@linux.ibm.com; Kovacevic, Marko > ; dev@dpdk.org > Cc: honnappa.nagaraha...@arm.com; gavin...@arm.com; dharmik.thak...@arm.com; > malvika.gu...@arm.com > Subject: [PATCH v5 0/3] lib/rcu: add RCU library supporting QSBR mechanism > > Lock-less data structures provide scalability and determinism. > They enable use cases where locking may not be allowed > (for ex: real-time applications). > > In the following paras, the term 'memory' refers to memory allocated > by typical APIs like malloc or anything that is representative of > memory, for ex: an index of a free element array. > > Since these data structures are lock less, the writers and readers > are accessing the data structures concurrently. Hence, while removing > an element from a data structure, the writers cannot return the memory > to the allocator, without knowing that the readers are not > referencing that element/memory anymore. Hence, it is required to > separate the operation of removing an element into 2 steps: > > Delete: in this step, the writer removes the reference to the element from > the data structure but does not return the associated memory to the > allocator. This will ensure that new readers will not get a reference to > the removed element. Removing the reference is an atomic operation. > > Free(Reclaim): in this step, the writer returns the memory to the > memory allocator, only after knowing that all the readers have stopped > referencing the deleted element. > > This library helps the writer determine when it is safe to free the > memory. > > This library makes use of thread Quiescent State (QS). QS can be > defined as 'any point in the thread execution where the thread does > not hold a reference to shared memory'. It is upto the application to > determine its quiescent state. Let us consider the following diagram: > > Time --> > > | | > RT1 $D1+++***D2*|**+++|+++**D3*$ > | | > RT2 $D1++|+**D2|***++**D3*$ > | | > RT3 $D1+++***|D2***|++**D2*$ > | | > |<--->| >Del | Free >| > Cannot free memory > during this period > (Grace Period) > > RTx - Reader thread > < and > - Start and end of while(1) loop > ***Dx*** - Reader thread is accessing the shared data structure Dx. >i.e. critical section. > +++ - Reader thread is not accessing any shared data structure. > i.e. non critical section or quiescent state. > Del - Point in time when the reference to the entry is removed using > atomic operation. > Free - Point in time when the writer can free the entry. > Grace Period - Time duration between Del and Free, during which memory cannot >be freed. > > As shown, thread RT1 accesses data structures D1, D2 and D3. When it is > accessing D2, if the writer has to remove an element from D2, the > writer cannot free the memory associated with that element immediately. > The writer can return the memory to the allocator only after the reader > stops referencing D2. In other words, reader thread RT1 has to enter > a quiescent state. > > Similarly, since thread RT3 is also accessing D2, writer has to wait till > RT3 enters quiescent state as well. > > However, the writer does not need to wait for RT2 to enter quiescent state. > Thread RT2 was not accessing D2 when the delete operation happened. > So, RT2 will not get a reference to the deleted entry. > > It can be noted that, the critical sections for D2 and D3 are quiescent states > for D1. i.e. for a given data structure Dx, any point in the thread execution > that does not reference Dx is a quiescent state. > > Since memory is not freed immediately, there might be a need for > provisioning of additional memory, depending on the application requirements. > > It is important to make sure that this library keeps the overhead of > identifying the end of grace period and subsequent freeing of memory, > to a minimum. The following paras explain how grace period and critical > section affect this overhead. > > The writer has to poll the readers to identify the end of grace period. > Polling introduces memory accesses and wastes CPU cycles. The memory > is not available for reuse during grace period. Longer grace periods > exasperate these conditions. > > The length of the critical section and the number of reader threads > is proportional to the duration of the grace pe
Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
> -Original Message- > From: Stephen Hemminger [mailto:step...@networkplumber.org] > Sent: Monday, April 15, 2019 4:39 PM > To: Ananyev, Konstantin > Cc: Honnappa Nagarahalli ; > paul...@linux.ibm.com; Kovacevic, Marko > ; dev@dpdk.org; Gavin Hu (Arm Technology China) > ; Dharmik Thakkar > ; Malvika Gupta ; nd > > Subject: Re: [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism > > On Mon, 15 Apr 2019 12:24:47 + > "Ananyev, Konstantin" wrote: > > > > -Original Message- > > > From: Stephen Hemminger [mailto:step...@networkplumber.org] > > > Sent: Saturday, April 13, 2019 12:06 AM > > > To: Honnappa Nagarahalli > > > Cc: Ananyev, Konstantin ; > > > paul...@linux.ibm.com; Kovacevic, Marko ; > > > dev@dpdk.org; Gavin Hu (Arm Technology China) ; Dharmik > > > Thakkar ; Malvika > Gupta > > > ; nd > > > Subject: Re: [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism > > > > > > On Fri, 12 Apr 2019 22:24:45 + > > > Honnappa Nagarahalli wrote: > > > > > > > > > > > > > On Fri, 12 Apr 2019 15:20:37 -0500 > > > > > Honnappa Nagarahalli wrote: > > > > > > > > > > > Add RCU library supporting quiescent state based memory reclamation > > > > > method. > > > > > > This library helps identify the quiescent state of the reader > > > > > > threads > > > > > > so that the writers can free the memory associated with the lock > > > > > > less > > > > > > data structures. > > > > > > > > > > > > Signed-off-by: Honnappa Nagarahalli > > > > > > Reviewed-by: Steve Capper > > > > > > Reviewed-by: Gavin Hu > > > > > > Reviewed-by: Ola Liljedahl > > > > > > Acked-by: Konstantin Ananyev > > > > > > > > > > After evaluating long term API/ABI issues, I think you need to get > > > > > rid of almost > > > > > all use of inline and visible structures. Yes it might be marginally > > > > > slower, but > > > > > you thank me the first time you have to fix something. > > > > > > > > > Agree, I was planning on another version to address this (I am yet to > > > > take a look at your patch addressing the ABI). > > > > The structure visibility definitely needs to be addressed. > > > > For the inline functions, is the plan to convert all the inline > > > > functions in DPDK? If yes, I think we need to consider the performance > > > difference. May be consider L3-fwd application, change all the inline > > > functions in its path and run a test? > > > > > > Every function that is not in the direct datapath should not be inline. > > > Exceptions or things like rx/tx burst, ring enqueue/dequeue, and packet > > > alloc/free > > > > Plus synchronization routines: spin/rwlock/barrier, etc. > > I think rcu should be one of such exceptions - it is just another > > synchronization mechanism after all > > (just a bit more sophisticated). > > Konstantin > > If you look at the other userspace RCU, you wil see that the only inlines > are the rcu_read_lock,rcu_read_unlock and rcu_reference/rcu_assign_pointer. > > The synchronization logic is all real functions. In fact, I think urcu provides both flavors: https://github.com/urcu/userspace-rcu/blob/master/include/urcu/static/urcu-qsbr.h I still don't understand why we have to treat it differently then let say spin-lock/ticket-lock or rwlock. If we gone all the way to create our own version of rcu, we probably want it to be as fast as possible (I know that main speedup should come from the fact that readers don't have to wait for writer to finish, but still...) Konstantin
Re: [dpdk-dev] [PATCH v2 3/3] cryptodev: fix uninitialized session clear
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Marko Kovacevic
> Sent: Monday, April 15, 2019 4:05 PM
> To: dev@dpdk.org
> Cc: Mcnamara, John ; Zhao, XinfengX
> ;
> akhil.go...@nxp.com; Kovacevic, Marko ; Zhang, Roy
> Fan
> ; sta...@dpdk.org
> Subject: [dpdk-dev] [PATCH v2 3/3] cryptodev: fix uninitialized session clear
>
> added check to see if a session for a device
> has been initialised if it has return 0.
>
> Fixes: 5d6c73dd5938 ("cryptodev: add reference count to session private data")
> Cc: roy.fan.zh...@intel.com
> Cc: sta...@dpdk.org
>
> Signed-off-by: Marko Kovacevic
Acked-by: Fiona Trahe
Re: [dpdk-dev] [EXT] [PATCH 1/6] meson: disable octeontx for buggy compilers on arm64
> On Apr 12, 2019, at 10:52 PM, Pavan Nikhilesh Bhagavatula
> wrote:
>
> Hi Yongseok,
>
>> --
>> Disable octeontx for gcc 4.8.5 as compiler is emitting "internal compiler
>> error"
>> for aarch64
>>
>> Fixes: bd77f2d64c44 ("event/octeontx: build with meson")
>> Fixes: 4f760550a093 ("mk: disable OcteonTx for buggy compilers")
>> Fixes: f3af3e44a444 ("mk: disable OcteonTx for buggy compilers only on
>> arm64")
>> Cc: pbhagavat...@marvell.com
>> Cc: jer...@marvell.com
>> Cc: sta...@dpdk.org
>>
>> Signed-off-by: Yongseok Koh
>> ---
>> drivers/event/meson.build | 6 +-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/event/meson.build b/drivers/event/meson.build index
>> 836ecbb74b..d364871d15 100644
>> --- a/drivers/event/meson.build
>> +++ b/drivers/event/meson.build
>> @@ -1,7 +1,11 @@
>> # SPDX-License-Identifier: BSD-3-Clause # Copyright(c) 2017 Intel
>> Corporation
>>
>> -drivers = ['dpaa', 'dpaa2', 'octeontx', 'opdl', 'skeleton', 'sw', 'dsw']
>> +drivers = ['dpaa', 'dpaa2', 'opdl', 'skeleton', 'sw', 'dsw'] if
>> +(toolchain == 'gcc' and cc.version().version_compare('>=4.8.6') and
>> +dpdk_conf.has('RTE_ARCH_ARM64'))
>
> Can we make this similar to MAKEFILE[1] case where octeontx is enabled for
> everycase except when
> We are compiling for ARCH_ARM64 is set and compiler is less than < 4.8.6?.
> The reason being we want x86 CI to run (compilation part) to find any errors.
>
> [1]
> '
> ifeq ($(CONFIG_RTE_ARCH), arm64)
>ifeq ($(shell test $(GCC_VERSION)$(GCC_PATCHLEVEL) -lt 486 && echo 1),
> 1)
>CONFIG_RTE_LIBRTE_PMD_OCTEONTX_SSOVF=d
>CONFIG_RTE_LIBRTE_OCTEONTX_MEMPOOL=d
>CONFIG_RTE_LIBRTE_OCTEONTX_PMD=d
>endif
>endif
> '
OMG, I was very wrong about the patch. That was Friday and I was moving fast.
:-)
Will fix it in v2.
thanks,
Yongseok
>
>> +drivers += 'octeontx'
>> +endif
>> std_deps = ['eventdev', 'kvargs']
>> config_flag_fmt = 'RTE_LIBRTE_@0@_EVENTDEV_PMD'
>> driver_name_fmt = 'rte_pmd_@0@_event'
>> --
>> 2.21.0.196.g041f5ea
Re: [dpdk-dev] [EXT] [PATCH 5/6] build: add option for armv8 crypto extension
> On Apr 13, 2019, at 12:22 AM, Jerin Jacob Kollanukkaran
> wrote:
>
>> -Original Message-
>> From: Yongseok Koh
>> Sent: Saturday, April 13, 2019 4:55 AM
>> To: bruce.richard...@intel.com; Jerin Jacob Kollanukkaran
>> ; Pavan Nikhilesh Bhagavatula
>> ; shah...@mellanox.com
>> Cc: dev@dpdk.org; tho...@monjalon.net; gavin...@arm.com;
>> honnappa.nagaraha...@arm.com
>> Subject: [EXT] [PATCH 5/6] build: add option for armv8 crypto extension
>>
>> CONFIG_RTE_MACHINE="armv8a"
>> +CONFIG_RTE_ENABLE_ARMV8_CRYPTO=y
>
> This approach is not scalable. Even, it is not good for BlueField as you
> you need to maintain two images.
>
> Unlike other CPU flags, arm64's crypto cpu flag is really _optional_.
> Access to crypto instructions is always at under runtime check.
> See the following in rte_armv8_pmd.c
>
>
> /* Check CPU for support for AES instruction set */
> if (!rte_cpu_get_flag_enabled(RTE_CPUFLAG_AES)) {
> ARMV8_CRYPTO_LOG_ERR(
> "AES instructions not supported by CPU");
> return -EFAULT;
> }
>
> /* Check CPU for support for SHA instruction set */
> if (!rte_cpu_get_flag_enabled(RTE_CPUFLAG_SHA1) ||
> !rte_cpu_get_flag_enabled(RTE_CPUFLAG_SHA2)) {
> ARMV8_CRYPTO_LOG_ERR(
> "SHA1/SHA2 instructions not supported by CPU");
> return -EFAULT;
> }
>
> So In order to avoid one more config flags specific to armv8 in meson and
> makefile build infra
> And avoid the need for 6/6 patch. IMO,
> # Introduce optional CPU flag scheme in eal. Treat armv8 crypto as optional
> flag
> # Skip the eal init check for optional flag.
>
> Do you see any issues with that approach?
I also thought about that approach and that was my number 1 priority. But, I had
one question came to my mind. Maybe, arm people can confirm it. Is it 100%
guaranteed that compiler never makes use of any of crypto instructions even if
there's no specific asm/intrinsic code? The crypto extension has aes, pmull,
sha1 and sha2. In case of rte_memcpy() for x86, for example, compiler may
optimize code using avx512f instructions even though it is written specifically
with avx2 intrinsics (__mm256_*) unless avx512f is disabled.
If a complier expert in arm (or anyone else) confirm it is completely
**optional**, then I'd love to take that approach for sure.
Copied dpdk-on-arm ML.
Thanks,
Yongseok
Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
> > > > > > > > > > > > After evaluating long term API/ABI issues, I think you need to > > > > > > get rid of almost all use of inline and visible structures. > > > > > > Yes it might be marginally slower, but you thank me the first time > you have to fix something. > > > > > > > > > > > Agree, I was planning on another version to address this (I am yet > to take a look at your patch addressing the ABI). > > > > > The structure visibility definitely needs to be addressed. > > > > > For the inline functions, is the plan to convert all the inline > > > > > functions in DPDK? If yes, I think we need to consider the > > > > > performance > > > > difference. May be consider L3-fwd application, change all the inline > functions in its path and run a test? > > > > > > > > Every function that is not in the direct datapath should not be inline. > > > > Exceptions or things like rx/tx burst, ring enqueue/dequeue, and > > > > packet alloc/free > > > > > > Plus synchronization routines: spin/rwlock/barrier, etc. > > > I think rcu should be one of such exceptions - it is just another > > > synchronization mechanism after all (just a bit more sophisticated). > > > Konstantin > > > > If you look at the other userspace RCU, you wil see that the only > > inlines are the rcu_read_lock,rcu_read_unlock and > rcu_reference/rcu_assign_pointer. > > > > The synchronization logic is all real functions. > > In fact, I think urcu provides both flavors: > https://github.com/urcu/userspace- > rcu/blob/master/include/urcu/static/urcu-qsbr.h > I still don't understand why we have to treat it differently then let say > spin-lock/ticket-lock or rwlock. > If we gone all the way to create our own version of rcu, we probably want > it to be as fast as possible (I know that main speedup should come from > the fact that readers don't have to wait for writer to finish, but still...) > Except for ' rte_rcu_qsbr_synchronize' (will correct in the next version), we have the correct APIs marked as inline. They all are part of the fast path. > Konstantin
Re: [dpdk-dev] [PATCH v4 1/3] rcu: add RCU library supporting QSBR mechanism
>
> > > > >
> > > > > On Wed, Apr 10, 2019 at 06:20:04AM -0500, Honnappa Nagarahalli
> > > wrote:
> > > > > > Add RCU library supporting quiescent state based memory
> > > > > > reclamation
> > > > > method.
> > > > > > This library helps identify the quiescent state of the reader
> > > > > > threads so that the writers can free the memory associated
> > > > > > with the lock less data structures.
> > > > >
> > > > > I don't see any sign of read-side markers (rcu_read_lock() and
> > > > > rcu_read_unlock() in the Linux kernel, userspace RCU, etc.).
> > > > >
> > > > > Yes, strictly speaking, these are not needed for QSBR to
> > > > > operate, but they
> > > > These APIs would be empty for QSBR.
> > > >
> > > > > make it way easier to maintain and debug code using RCU. For
> > > > > example, given the read-side markers, you can check for errors
> > > > > like having a call to
> > > > > rte_rcu_qsbr_quiescent() in the middle of a reader quite easily.
> > > > > Without those read-side markers, life can be quite hard and you
> > > > > will really hate yourself for failing to have provided them.
> > > >
> > > > Want to make sure I understood this, do you mean the application
> > > would mark before and after accessing the shared data structure on
> > > the reader side?
> > > >
> > > > rte_rcu_qsbr_lock()
> > > > ...
> > > > ...
> > > >
> > > > rte_rcu_qsbr_unlock()
> > >
> > > Yes, that is the idea.
> > >
> > > > If someone is debugging this code, they have to make sure that
> > > > there is
> > > an unlock for every lock and there is no call to
> > > rte_rcu_qsbr_quiescent in between.
> > > > It sounds good to me. Obviously, they will not add any additional
> > > > cycles
> > > as well.
> > > > Please let me know if my understanding is correct.
> > >
> > > Yes. And in some sort of debug mode, you could capture the counter
> > > at
> > > rte_rcu_qsbr_lock() time and check it at rte_rcu_qsbr_unlock() time.
> > > If the counter has advanced too far (more than one, if I am not too
> > > confused) there is a bug. Also in debug mode, you could have
> > > rte_rcu_qsbr_lock() increment a per-thread counter and
> rte_rcu_qsbr_unlock() decrement it.
> > > If the counter is non-zero at a quiescent state, there is a bug.
> > > And so on.
> > >
> > Added this in V5
> >
> >
> >
> > > > > > +
> > > > > > +/* Get the memory size of QSBR variable */ size_t
> > > > > > +__rte_experimental rte_rcu_qsbr_get_memsize(uint32_t
> > > max_threads) {
> > > > > > + size_t sz;
> > > > > > +
> > > > > > + if (max_threads == 0) {
> > > > > > + rte_log(RTE_LOG_ERR, rcu_log_type,
> > > > > > + "%s(): Invalid max_threads %u\n",
> > > > > > + __func__, max_threads);
> > > > > > + rte_errno = EINVAL;
> > > > > > +
> > > > > > + return 1;
> > > > > > + }
> > > > > > +
> > > > > > + sz = sizeof(struct rte_rcu_qsbr);
> > > > > > +
> > > > > > + /* Add the size of quiescent state counter array */
> > > > > > + sz += sizeof(struct rte_rcu_qsbr_cnt) * max_threads;
> > > > > > +
> > > > > > + /* Add the size of the registered thread ID bitmap array */
> > > > > > + sz += RTE_QSBR_THRID_ARRAY_SIZE(max_threads);
> > > > > > +
> > > > > > + return RTE_ALIGN(sz, RTE_CACHE_LINE_SIZE);
> > > > >
> > > > > Given that you align here, should you also align in the earlier
> > > > > steps in the computation of sz?
> > > >
> > > > Agree. I will remove the align here and keep the earlier one as
> > > > the intent
> > > is to align the thread ID array.
> > >
> > > Sounds good!
> > Added this in V5
> >
> > >
> > > > > > +}
> > > > > > +
> > > > > > +/* Initialize a quiescent state variable */ int
> > > > > > +__rte_experimental rte_rcu_qsbr_init(struct rte_rcu_qsbr *v,
> > > uint32_t max_threads) {
> > > > > > + size_t sz;
> > > > > > +
> > > > > > + if (v == NULL) {
> > > > > > + rte_log(RTE_LOG_ERR, rcu_log_type,
> > > > > > + "%s(): Invalid input parameter\n", __func__);
> > > > > > + rte_errno = EINVAL;
> > > > > > +
> > > > > > + return 1;
> > > > > > + }
> > > > > > +
> > > > > > + sz = rte_rcu_qsbr_get_memsize(max_threads);
> > > > > > + if (sz == 1)
> > > > > > + return 1;
> > > > > > +
> > > > > > + /* Set all the threads to offline */
> > > > > > + memset(v, 0, sz);
> > > > >
> > > > > We calculate sz here, but it looks like the caller must also
> > > > > calculate it in order to correctly allocate the memory
> > > > > referenced by the "v" argument to this function, with bad things
> > > > > happening if the two calculations get different results. Should
> > > > > "v" instead be allocated within this function to avoid this sort of
> problem?
> > > >
> > > > Earlier version allocated the memory with-in this library.
> > > > However, it was
> > > decided to go with the current implementation as it provides
> > > flexibility for the application to manage the memory as it sees fit.
> > > For ex: it
Re: [dpdk-dev] [PATCH 3/6] net/mlx: fix library search in meson build
Hi,
Thanks,
Yongseok
> On Apr 15, 2019, at 3:12 AM, Luca Boccassi wrote:
>
> On Fri, 2019-04-12 at 16:24 -0700, Yongseok Koh wrote:
>> If MLNX_OFED is installed, there's no .pc file installed for
>> libraries and
>> dependency() can't find libraries by pkg-config. By adding fallback
>> of
>> using cc.find_library(), libraries are properly located.
>>
>> Fixes: e30b4e566f47 ("build: improve dependency handling")
>> Cc:
>> bl...@debian.org
>>
>> Cc:
>> sta...@dpdk.org
>>
>>
>> Signed-off-by: Yongseok Koh <
>> ys...@mellanox.com
>>>
>> ---
>> drivers/net/mlx4/meson.build | 19 +++
>> drivers/net/mlx5/meson.build | 19 +++
>> 2 files changed, 22 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/net/mlx4/meson.build
>> b/drivers/net/mlx4/meson.build
>> index de020701d1..9082f69f25 100644
>> --- a/drivers/net/mlx4/meson.build
>> +++ b/drivers/net/mlx4/meson.build
>> @@ -13,21 +13,24 @@ if pmd_dlopen
>> '-DMLX4_GLUE_VERSION="@0@"'.format(LIB_GLUE_VERSION),
>> ]
>> endif
>> -libs = [
>> -dependency('libmnl', required:false),
>> -dependency('libmlx4', required:false),
>> -dependency('libibverbs', required:false),
>> -]
>> +libs = [ 'libmnl', 'libmlx4', 'libibverbs' ]
>> +lib_deps = []
>> build = true
>> foreach lib:libs
>> -if not lib.found()
>> +lib_dep = dependency(lib, required:false)
>> +if not lib_dep.found()
>> +lib_dep = cc.find_library(lib, required:false)
>
> Doesn't this end up trying to link the test program to -llibmnl and
> thus failing?
I also worried about that. But it works fine.
Looks meson is smart enough. :-)
>> +endif
>> +if lib_dep.found()
>> +lib_deps += [ lib_dep ]
>> +else
>> build = false
>> endif
>> endforeach
>> # Compile PMD
>> if build
>> allow_experimental_apis = true
>> -ext_deps += libs
>> +ext_deps += lib_deps
>> sources = files(
>> 'mlx4.c',
>> 'mlx4_ethdev.c',
>> @@ -103,7 +106,7 @@ if pmd_dlopen and build
>> dlopen_sources,
>> include_directories: global_inc,
>> c_args: cflags,
>> -dependencies: libs,
>> +dependencies: libs_deps,
>> link_args: [
>> '-Wl,-export-dynamic',
>> '-Wl,-h,@0@'.format(LIB_GLUE),
>
> --
> Kind regards,
> Luca Boccassi
Re: [dpdk-dev] [PATCH 3/6] net/mlx: fix library search in meson build
> On Apr 15, 2019, at 2:19 AM, Bruce Richardson
> wrote:
>
> On Fri, Apr 12, 2019 at 04:24:48PM -0700, Yongseok Koh wrote:
>> If MLNX_OFED is installed, there's no .pc file installed for libraries and
>> dependency() can't find libraries by pkg-config. By adding fallback of
>> using cc.find_library(), libraries are properly located.
>>
>> Fixes: e30b4e566f47 ("build: improve dependency handling")
>> Cc: bl...@debian.org
>> Cc: sta...@dpdk.org
>>
>> Signed-off-by: Yongseok Koh
>> ---
>> drivers/net/mlx4/meson.build | 19 +++
>> drivers/net/mlx5/meson.build | 19 +++
>> 2 files changed, 22 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/net/mlx4/meson.build b/drivers/net/mlx4/meson.build
>> index de020701d1..9082f69f25 100644
>> --- a/drivers/net/mlx4/meson.build
>> +++ b/drivers/net/mlx4/meson.build
>> @@ -13,21 +13,24 @@ if pmd_dlopen
>> '-DMLX4_GLUE_VERSION="@0@"'.format(LIB_GLUE_VERSION),
>> ]
>> endif
>> -libs = [
>> -dependency('libmnl', required:false),
>> -dependency('libmlx4', required:false),
>> -dependency('libibverbs', required:false),
>> -]
>> +libs = [ 'libmnl', 'libmlx4', 'libibverbs' ]
>> +lib_deps = []
>
> Minor suggestion - you can reduce the size of the diff in this patch by
> defining the first array as "libnames" and keeping the actual dependency
> objects as "libs".
Sounds good to me.
Will take the suggestion in my v2.
Re: [dpdk-dev] [EXT] [PATCH 5/6] build: add option for armv8 crypto extension
> >> Subject: [EXT] [PATCH 5/6] build: add option for armv8 crypto
> >> extension
> >>
> >> CONFIG_RTE_MACHINE="armv8a"
> >> +CONFIG_RTE_ENABLE_ARMV8_CRYPTO=y
> >
> > This approach is not scalable. Even, it is not good for BlueField as
> > you you need to maintain two images.
> >
> > Unlike other CPU flags, arm64's crypto cpu flag is really _optional_.
> > Access to crypto instructions is always at under runtime check.
> > See the following in rte_armv8_pmd.c
> >
> >
> > /* Check CPU for support for AES instruction set */
> > if (!rte_cpu_get_flag_enabled(RTE_CPUFLAG_AES)) {
> > ARMV8_CRYPTO_LOG_ERR(
> > "AES instructions not supported by CPU");
> > return -EFAULT;
> > }
> >
> > /* Check CPU for support for SHA instruction set */
> > if (!rte_cpu_get_flag_enabled(RTE_CPUFLAG_SHA1) ||
> > !rte_cpu_get_flag_enabled(RTE_CPUFLAG_SHA2)) {
> > ARMV8_CRYPTO_LOG_ERR(
> > "SHA1/SHA2 instructions not supported by CPU");
> > return -EFAULT;
> > }
> >
> > So In order to avoid one more config flags specific to armv8 in meson
> > and makefile build infra And avoid the need for 6/6 patch. IMO, #
> > Introduce optional CPU flag scheme in eal. Treat armv8 crypto as
> > optional flag # Skip the eal init check for optional flag.
> >
> > Do you see any issues with that approach?
>
> I also thought about that approach and that was my number 1 priority.
> But, I had one question came to my mind. Maybe, arm people can confirm
> it. Is it 100% guaranteed that compiler never makes use of any of crypto
> instructions even if there's no specific asm/intrinsic code? The crypto
> extension has aes, pmull,
> sha1 and sha2. In case of rte_memcpy() for x86, for example, compiler may
> optimize code using avx512f instructions even though it is written
> specifically with avx2 intrinsics (__mm256_*) unless avx512f is disabled.
>
> If a complier expert in arm (or anyone else) confirm it is completely
> **optional**, then I'd love to take that approach for sure.
>
> Copied dpdk-on-arm ML.
>
I do not know the answer, will have to check with the compiler team. I will get
back on this.
>
> Thanks,
> Yongseok
>
Re: [dpdk-dev] [EXT] [PATCH 2/6] meson: change default cache line size for cortex-a72
> On Apr 15, 2019, at 6:40 AM, Honnappa Nagarahalli > wrote: > >> -- Per the email discussion [1], the default cache line size of armv8 cortex-a72 is changed to 64 bytes. >>> >>> IMO, In git commit you remove the reference to specific discussion and >>> Update the reason correctly. >>> >>> [1] https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmails.dpdk.org%2Farchives%2Fdev%2F2019-January%2F123218.html&data=02%7C01%7Cyskoh%40mellanox.com%7C4c0cdd9535c84c8dd3c008d6c1a7f5eb%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636909324474698429&sdata=UJO2lBtnYWSs5ud8CsAL7oGXH571f6zGjrVmP2SRChw%3D&reserved=0 Signed-off-by: Yongseok Koh --- config/arm/meson.build | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/config/arm/meson.build b/config/arm/meson.build index e00b894523..73c581948c 100644 --- a/config/arm/meson.build +++ b/config/arm/meson.build @@ -51,6 +51,8 @@ flags_dpaa2 = [ ['RTE_MAX_LCORE', 16], ['RTE_LIBRTE_DPAA2_USE_PHYS_IOVA', false]] flags_default_extra >>> = [] +flags_cortex_a72_extra = [ + ['RTE_CACHE_LINE_SIZE', 64]] flags_thunderx_extra = [ >> Which tree does this patch apply to? I do not see the above line in master. > Please ignore this comment, I missed the dependency provided in 0/6 > >> ['RTE_MACHINE', '"thunderx"'], ['RTE_USE_C11_MEM_MODEL', false]] @@ -73,7 +75,7 @@ machine_args_generic = [ ['0xd03', ['-mcpu=cortex-a53']], ['0xd04', ['-mcpu=cortex-a35']], ['0xd07', ['-mcpu=cortex-a57']], - ['0xd08', ['-mcpu=cortex-a72']], + ['0xd08', ['-mcpu=cortex-a72'], flags_cortex_a72_extra], ['0xd09', ['-mcpu=cortex-a73']], ['0xd0a', ['-mcpu=cortex-a75']]] >>> >>> I think, flags_cortex_a72_extra() can be changed to >>> flags_vendor_arm_extra or something similar And update the following >>> CPUs also not just cortex-a72. >>> >> Why not add 'flags_arm' similar to flags_dpaa2/flag_cavium etc? All the >> listed Arm cores are 64B cache line size. If so, I'd take your approach - flags_arm. If we have an exception (CL size is 128 for some cpu) someday, then we can add an extra flag for that. > Just to complete the thought, impl_0x41 can use 'flags_arm' instead of > 'flags_generic'. IMO, current use of 'flags_generic' in impl_0x41 is > incorrect. > >> >>> ['0xd03', ['-mcpu=cortex-a53']], >>> ['0xd04', ['-mcpu=cortex-a35']], >>> ['0xd05', ['-mcpu=cortex-a55']], >>> ['0xd07', ['-mcpu=cortex-a57']], >>> ['0xd08', ['-mcpu=cortex-a72']], >>> ['0xd09', ['-mcpu=cortex-a73']], >>> ['0xd0a', ['-mcpu=cortex-a75']], >>> ['0xd0b', ['-mcpu=cortex-a76']], >>> >>> -- 2.21.0.196.g041f5ea >
Re: [dpdk-dev] [PATCH v1] test/ticketlock: implement ticketlock autotest
> > Add ticketlock_autotest implementation in python.
> >
> > Fixes: efbcdaa55b93 ("test/ticketlock: add test cases")
> >
> > Signed-off-by: Joyce Kong
> Reviewed-by: Phil Yang
> Tested-by: Phil Yang
Applied, thanks
Re: [dpdk-dev] [RFC 08/12] hash: add support for s390x architecture
Hi,
Please find the inline comment.
> On Apr 9, 2019, at 2:06 PM, Vivian Kong wrote:
>
> Add big endian support for s390x architecture.
>
> Signed-off-by: Vivian Kong
> ---
> lib/librte_hash/rte_fbk_hash.h | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/lib/librte_hash/rte_fbk_hash.h b/lib/librte_hash/rte_fbk_hash.h
> index c4d6976d2..5e49950a7 100644
> --- a/lib/librte_hash/rte_fbk_hash.h
> +++ b/lib/librte_hash/rte_fbk_hash.h
> @@ -125,9 +125,16 @@ rte_fbk_hash_add_key_with_bucket(struct
> rte_fbk_hash_table *ht,
>* corrupted due to race conditions, but it's still possible to
>* overwrite entries that have just been made valid.
>*/
> + #if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
> const uint64_t new_entry = ((uint64_t)(key) << 32) |
> ((uint64_t)(value) << 16) |
> 1; /* 1 = is_entry bit. */
> + #else
> + const uint64_t new_entry =
> + ((uint64_t)(1) << 48) | /* 1 = is_entry bit. */
((uint64_t)(1) << 56)?
> + ((uint64_t)(value) << 32) |
> + (uint64_t)(key);
> + #endif
> uint32_t i;
>
> for (i = 0; i < ht->entries_per_bucket; i++) {
> --
> 2.17.1
>
Re: [dpdk-dev] [EXT] [PATCH 2/6] meson: change default cache line size for cortex-a72
> > > >> > > --- > - > -- Per the email discussion [1], the default cache line size of > armv8 > cortex-a72 is changed to 64 bytes. > >>> > >>> IMO, In git commit you remove the reference to specific discussion > >>> and Update the reason correctly. > >>> > >>> > > [1] > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm > ails.dpdk.org%2Farchives%2Fdev%2F2019- > January%2F123218.html&dat > > a=02%7C01%7Cyskoh%40mellanox.com%7C4c0cdd9535c84c8dd3c008d6c1a > 7f5eb > %7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C6369093244 > 74698429&am > > p;sdata=UJO2lBtnYWSs5ud8CsAL7oGXH571f6zGjrVmP2SRChw%3D&re > served > =0 > > Signed-off-by: Yongseok Koh > --- > config/arm/meson.build | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/config/arm/meson.build b/config/arm/meson.build index > e00b894523..73c581948c 100644 > --- a/config/arm/meson.build > +++ b/config/arm/meson.build > @@ -51,6 +51,8 @@ flags_dpaa2 = [ > ['RTE_MAX_LCORE', 16], > ['RTE_LIBRTE_DPAA2_USE_PHYS_IOVA', false]] flags_default_extra > >>> = [] > +flags_cortex_a72_extra = [ > +['RTE_CACHE_LINE_SIZE', 64]] > flags_thunderx_extra = [ > >> Which tree does this patch apply to? I do not see the above line in > master. > > Please ignore this comment, I missed the dependency provided in 0/6 > > > >> > ['RTE_MACHINE', '"thunderx"'], > ['RTE_USE_C11_MEM_MODEL', false]] > @@ -73,7 +75,7 @@ machine_args_generic = [ > ['0xd03', ['-mcpu=cortex-a53']], > ['0xd04', ['-mcpu=cortex-a35']], > ['0xd07', ['-mcpu=cortex-a57']], > -['0xd08', ['-mcpu=cortex-a72']], > +['0xd08', ['-mcpu=cortex-a72'], flags_cortex_a72_extra], > ['0xd09', ['-mcpu=cortex-a73']], > ['0xd0a', ['-mcpu=cortex-a75']]] > >>> > >>> I think, flags_cortex_a72_extra() can be changed to > >>> flags_vendor_arm_extra or something similar And update the > following > >>> CPUs also not just cortex-a72. > >>> > >> Why not add 'flags_arm' similar to flags_dpaa2/flag_cavium etc? All > >> the listed Arm cores are 64B cache line size. > > If so, I'd take your approach - flags_arm. > If we have an exception (CL size is 128 for some cpu) someday, then we > can add an extra flag for that. > Agree. I see the likelihood to be slim given the list of CPUs with 64B > > Just to complete the thought, impl_0x41 can use 'flags_arm' instead of > 'flags_generic'. IMO, current use of 'flags_generic' in impl_0x41 is > incorrect. > > > >> > >>> ['0xd03', ['-mcpu=cortex-a53']], > >>> ['0xd04', ['-mcpu=cortex-a35']], > >>> ['0xd05', ['-mcpu=cortex-a55']], > >>> ['0xd07', ['-mcpu=cortex-a57']], > >>> ['0xd08', ['-mcpu=cortex-a72']], > >>> ['0xd09', ['-mcpu=cortex-a73']], > >>> ['0xd0a', ['-mcpu=cortex-a75']], > >>> ['0xd0b', ['-mcpu=cortex-a76']], > >>> > >>> > > -- > 2.21.0.196.g041f5ea > >
Re: [dpdk-dev] [EXT] [PATCH 0/6] build: fix build for arm64
> On Apr 13, 2019, at 12:12 AM, Jerin Jacob Kollanukkaran > wrote: > > Other than 1/1, I don't think, this patches series fixing any build for arm64. That's one of reasons for the title. > It is adding features required for Mellanox BlueField support. Hard to agree. > Please change subject to more appropriate name. If the title of the cover letter (which isn't merged anyway but informative) still bothers you, let me know. I'd rather remove the cover letter like your patchset. >> -Original Message- >> From: Yongseok Koh >> Sent: Saturday, April 13, 2019 4:55 AM >> To: bruce.richard...@intel.com; Jerin Jacob Kollanukkaran >> ; Pavan Nikhilesh Bhagavatula >> ; shah...@mellanox.com >> Cc: dev@dpdk.org; tho...@monjalon.net; gavin...@arm.com; >> honnappa.nagaraha...@arm.com >> Subject: [EXT] [PATCH 0/6] build: fix build for arm64 >> >> External Email >> >> -- >> This patchset depends on >> "meson: add infra to support machine specific flags" [1] >> >> [1] >> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatches.dpdk.org%2Fpatch%2F52606%2F&data=02%7C01%7Cyskoh%40mellanox.com%7C0c76f968187240046bfd08d6bfdf7283%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636907363757515638&sdata=X3fQ%2B%2B7RIs8MbTy%2Bok5WVm6wSmslrcyRuIuECAVhxXA%3D&reserved=0 >> >> Yongseok Koh (6): >> meson: disable octeontx for buggy compilers on arm64 >> meson: change default cache line size for cortex-a72 >> net/mlx: fix library search in meson build >> meson: add Mellanox BlueField cross-compile config >> build: add option for armv8 crypto extension >> mk: disable armv8 crypto extension for Mellanox BlueField >> >> config/arm/arm64_bluefield_linux_gcc | 16 >> config/arm/meson.build| 18 +++--- >> config/common_armv8a_linux| 1 + >> config/defconfig_arm64-bluefield-linuxapp-gcc | 6 ++ >> drivers/crypto/armv8/Makefile | 4 >> drivers/event/meson.build | 6 +- >> drivers/net/mlx4/meson.build | 19 +++ >> drivers/net/mlx5/meson.build | 19 +++ >> meson_options.txt | 2 ++ >> mk/machine/armv8a/rte.vars.mk | 4 >> 10 files changed, 71 insertions(+), 24 deletions(-) create mode 100644 >> config/arm/arm64_bluefield_linux_gcc >> >> -- >> 2.21.0.196.g041f5ea >
Re: [dpdk-dev] [PATCH v10 1/4] mk: introduce helper to check valid compiler argument
13/04/2019 22:19, jer...@marvell.com: > Change history of this series: > > v10 Changes: > - Fix the following checkpatch warning > http://mails.dpdk.org/archives/test-report/2019-April/080453.html > > v9 Changes: > - Remove compiler version check as it is now done using >cc.has_argument(). > > v8 Changes: > - Remove redudant lists (rebase aritfacts). (Yongseok Koh) > > v7 Changes: > - Updated cross compile config files align with > "build: improve pcap dependency handling" changeset to fix build issue with > meson > - Some compiler needs the following depended patch to compile with meson >http://patches.dpdk.org/patch/52367/ Applied, thanks
Re: [dpdk-dev] [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism
On Mon, 15 Apr 2019 17:39:07 + "Ananyev, Konstantin" wrote: > > -Original Message- > > From: Stephen Hemminger [mailto:step...@networkplumber.org] > > Sent: Monday, April 15, 2019 4:39 PM > > To: Ananyev, Konstantin > > Cc: Honnappa Nagarahalli ; > > paul...@linux.ibm.com; Kovacevic, Marko > > ; dev@dpdk.org; Gavin Hu (Arm Technology China) > > ; Dharmik Thakkar > > ; Malvika Gupta ; nd > > > > Subject: Re: [PATCH v5 1/3] rcu: add RCU library supporting QSBR mechanism > > > > On Mon, 15 Apr 2019 12:24:47 + > > "Ananyev, Konstantin" wrote: > > > > > > -Original Message- > > > > From: Stephen Hemminger [mailto:step...@networkplumber.org] > > > > Sent: Saturday, April 13, 2019 12:06 AM > > > > To: Honnappa Nagarahalli > > > > Cc: Ananyev, Konstantin ; > > > > paul...@linux.ibm.com; Kovacevic, Marko ; > > > > dev@dpdk.org; Gavin Hu (Arm Technology China) ; > > > > Dharmik Thakkar ; Malvika > > Gupta > > > > ; nd > > > > Subject: Re: [PATCH v5 1/3] rcu: add RCU library supporting QSBR > > > > mechanism > > > > > > > > On Fri, 12 Apr 2019 22:24:45 + > > > > Honnappa Nagarahalli wrote: > > > > > > > > > > > > > > > > On Fri, 12 Apr 2019 15:20:37 -0500 > > > > > > Honnappa Nagarahalli wrote: > > > > > > > > > > > > > Add RCU library supporting quiescent state based memory > > > > > > > reclamation > > > > > > method. > > > > > > > This library helps identify the quiescent state of the reader > > > > > > > threads > > > > > > > so that the writers can free the memory associated with the lock > > > > > > > less > > > > > > > data structures. > > > > > > > > > > > > > > Signed-off-by: Honnappa Nagarahalli > > > > > > > Reviewed-by: Steve Capper > > > > > > > Reviewed-by: Gavin Hu > > > > > > > Reviewed-by: Ola Liljedahl > > > > > > > Acked-by: Konstantin Ananyev > > > > > > > > > > > > After evaluating long term API/ABI issues, I think you need to get > > > > > > rid of almost > > > > > > all use of inline and visible structures. Yes it might be > > > > > > marginally slower, but > > > > > > you thank me the first time you have to fix something. > > > > > > > > > > > Agree, I was planning on another version to address this (I am yet to > > > > > take a look at your patch addressing the ABI). > > > > > The structure visibility definitely needs to be addressed. > > > > > For the inline functions, is the plan to convert all the inline > > > > > functions in DPDK? If yes, I think we need to consider the > > > > > performance > > > > difference. May be consider L3-fwd application, change all the inline > > > > functions in its path and run a test? > > > > > > > > Every function that is not in the direct datapath should not be inline. > > > > Exceptions or things like rx/tx burst, ring enqueue/dequeue, and packet > > > > alloc/free > > > > > > Plus synchronization routines: spin/rwlock/barrier, etc. > > > I think rcu should be one of such exceptions - it is just another > > > synchronization mechanism after all > > > (just a bit more sophisticated). > > > Konstantin > > > > If you look at the other userspace RCU, you wil see that the only inlines > > are the rcu_read_lock,rcu_read_unlock and rcu_reference/rcu_assign_pointer. > > > > The synchronization logic is all real functions. > > In fact, I think urcu provides both flavors: > https://github.com/urcu/userspace-rcu/blob/master/include/urcu/static/urcu-qsbr.h > I still don't understand why we have to treat it differently then let say > spin-lock/ticket-lock or rwlock. > If we gone all the way to create our own version of rcu, we probably want it > to be as fast as possible > (I know that main speedup should come from the fact that readers don't have > to wait for writer to finish, but still...) > > Konstantin > Having locking functions inline is already a problem in current releases. The implementation can not be improved without breaking ABI (or doing special workarounds like lock v2)
Re: [dpdk-dev] [PATCH] ethdev: fix QinQ strip offload support
>Using a local (pointer) variable for dev->data->dev_conf.rxmode.offloads >would make the code more readable and lines shorter. +1
Re: [dpdk-dev] 17.11.6-rc1 patches review and test
> On Mar 27, 2019, at 3:05 PM, Yongseok Koh wrote: > > Hi all, > > Here is a list of patches targeted for LTS release 17.11.6. Please help review > and test. The planned date for the final release is April 8, Before that, > please > shout if anyone has objection with these patches being applied. > > For the companies committed to running regression tests, please run the tests > and report any issue before the release date. I have received a test result from Mellanox. Do other vendors have any plan? Please let me know. Thanks, Yongseok > A release candidate tarball can be found at: > > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdpdk.org%2Fbrowse%2Fdpdk-stable%2Ftag%2F%3Fid%3Dv17.11.6-rc1&data=02%7C01%7Cyskoh%40mellanox.com%7C8a9d0a8540134ed33d8e08d6b301a562%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636893217006597884&sdata=Z88TDgVd%2FyoBPGjTNhAKd1RI%2BuRRVzzkAepwOnUo3%2BE%3D&reserved=0 > > These patches are located in the dpdk-stable repo: > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.dpdk.org%2Fdpdk-stable%2Flog%2F%3Fh%3D17.11&data=02%7C01%7Cyskoh%40mellanox.com%7C8a9d0a8540134ed33d8e08d6b301a562%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636893217006597884&sdata=XWE1yov9Ms%2Ff%2FN5le21u0edt9AlW24N979fwMd7f%2BA0%3D&reserved=0 > > Also, there's the list of missing patches attached at the end. Please take a > look and respond. It is not late yet. > > > Thanks, > Yongseok > > --- > > Alejandro Lucero (1): > vfio: fix error message > > Anatoly Burakov (3): > test/memzone: fix typo > test/memzone: handle previously allocated memzones > eal: check string parameter lengths > > Andrew Rybchenko (6): > net/sfc: pass HW Tx queue index on creation > net/sfc: fix typo in preprocessor check > net/sfc: fix VF error/missed stats mapping > net/sfc: fix Rx packets counter > ethdev: fix errno to have positive value > gso: fix VxLAN/GRE tunnel checks > > Arek Kusztal (1): > crypto/qat: fix block size error handling > > Bruce Richardson (2): > net: fix underflow for checksum of invalid IPv4 packets > net/tap: add buffer overflow checks before checksum > > Cristian Dumitrescu (1): > app/testpmd: fix quit to stop all ports before close > > David Hunt (1): > doc: fix references in power management guide > > David Marchand (1): > eal: fix out of bound access when no CPU available > > David Zeng (1): > kni: fix build on RHEL8 for arm and Power9 > > Declan Doherty (1): > net/bonding: fix possible null pointer reference > > Dekel Peled (2): > net/mlx5: fix validation of Rx queue number > examples/flow_filtering: fix example documentation > > Didier Pallard (2): > drivers/net: fix several Tx prepare functions > net/i40e: revert fix offload not supported mask > > Erik Gabriel Carrillo (1): > timer: fix race condition > > Fan Zhang (1): > drivers/crypto: fix PMDs memory leak > > Ferruh Yigit (4): > net/tap: fix possible uninitialized variable access > mk: fix scope of disabling AVX512F support > kni: fix build for dev_open in Linux 5.0 > kni: fix build for igb_ndo_bridge_setlink in Linux 5.0 > > Fiona Trahe (1): > test/crypto: fix misleading trace message > > Gage Eads (1): > eventdev: fix xstats documentation typo > > Gavin Hu (1): > devtools: fix wrong headline lowercase for arm > > Hari Kumar Vemula (2): > eal: fix core number validation > efd: fix tail queue leak > > Hemant Agrawal (1): > net/dpaa: fix secondary process > > Hyong Youb Kim (1): > net/enic: remove useless include > > Igor Romanov (1): > net/sfc/base: fix Tx descriptor max number check > > Ilya Maximets (1): > net/virtio: add barrier before reading the flags > > Ivan Malov (3): > net/sfc: discard last seen VLAN TCI if Tx packet is dropped > net/sfc: fix datapath name references in logs > net/sfc: fix port ID log > > Jiayu Hu (1): > gro: check invalid TCP header length > > Julien Meunier (1): > net/fm10k: fix internal switch initial status > > Konstantin Ananyev (2): > examples/ipsec-secgw: fix outbound codepath for single SA > examples/ipsec-secgw: make local variables static > > Luca Boccassi (1): > doc: fix garbage text in generated HTML guides > > Matthias Gatto (1): > vhost: fix race condition when adding fd in the fdset > > Maxime Coquelin (3): > vhost: fix error handling when mem table gets updated > vhost: fix payload size of reply > vhost: fix crash after mmap failure > > Michal Krawczyk (2): > net/ena: fix dev init with multi-process > net/ena: fix errno to positive value > > Pallantla Poornima (1): > drivers: fix sprintf with snprintf > > Player, Timmons (1): > net/igb: fix LSC interrupt when using MSI-X > > Qiming Yang (2): > net/i40e: fix getting RSS configuration > net/i4
Re: [dpdk-dev] [PATCH 2/2] net/ice: fix promiscuous mode
Wang Ying A :
> When device promiscuous mode has already been enabled,
> if user re-enables the promisc mode, he/she should be
> prompted with "Promisc has already been enabled"
> rather than "Failed to enable promisc".
>
> Fixes: c945e4bf9063 ("net/ice: support promiscuous mode")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Wang Ying A
> ---
>
Reviewed-by: Rami Rosen
[dpdk-dev] [PATCH v5 1/2] timer: allow timer management in shared memory
Currently, the timer library uses a per-process table of structures to
manage skiplists of timers presumably because timers contain arbitrary
function pointers whose value may not resolve properly in other
processes.
However, if the same callback is used handle all timers, and that
callback is only invoked in one process, then it woud be safe to allow
the data structures to be allocated in shared memory, and to allow
secondary processes to modify the timer lists. This would let timers be
used in more multi-process scenarios.
The library's global variables are wrapped with a struct, and an array
of these structures is created in shared memory. The original APIs
are updated to reference the zeroth entry in the array. This maintains
the original behavior for both primary and secondary processes since
the set intersection of their coremasks should be empty [1]. New APIs
are introduced to enable the allocation/deallocation of other entries
in the array.
New variants of the APIs used to start and stop timers are introduced;
they allow a caller to specify which array entry should be used to
locate the timer list to insert into or delete from.
Finally, a new variant of rte_timer_manage() is introduced, which
allows a caller to specify which array entry should be used to locate
the timer lists to process; it can also process multiple timer lists per
invocation.
[1]
https://doc.dpdk.org/guides/prog_guide/multi_proc_support.html#multi-process-limitations
Signed-off-by: Erik Gabriel Carrillo
---
lib/librte_timer/Makefile | 1 +
lib/librte_timer/rte_timer.c | 519 ++---
lib/librte_timer/rte_timer.h | 226 +-
lib/librte_timer/rte_timer_version.map | 22 ++
4 files changed, 723 insertions(+), 45 deletions(-)
diff --git a/lib/librte_timer/Makefile b/lib/librte_timer/Makefile
index 4ebd528..8ec63f4 100644
--- a/lib/librte_timer/Makefile
+++ b/lib/librte_timer/Makefile
@@ -6,6 +6,7 @@ include $(RTE_SDK)/mk/rte.vars.mk
# library name
LIB = librte_timer.a
+CFLAGS += -DALLOW_EXPERIMENTAL_API
CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) -O3
LDLIBS += -lrte_eal
diff --git a/lib/librte_timer/rte_timer.c b/lib/librte_timer/rte_timer.c
index 30c7b0a..511d902 100644
--- a/lib/librte_timer/rte_timer.c
+++ b/lib/librte_timer/rte_timer.c
@@ -5,6 +5,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -21,11 +22,15 @@
#include
#include
#include
+#include
+#include
+#include
#include "rte_timer.h"
-LIST_HEAD(rte_timer_list, rte_timer);
-
+/**
+ * Per-lcore info for timers.
+ */
struct priv_timer {
struct rte_timer pending_head; /**< dummy timer instance to head up
list */
rte_spinlock_t list_lock; /**< lock to protect list access */
@@ -48,25 +53,84 @@ struct priv_timer {
#endif
} __rte_cache_aligned;
-/** per-lcore private info for timers */
-static struct priv_timer priv_timer[RTE_MAX_LCORE];
+#define FL_ALLOCATED (1 << 0)
+struct rte_timer_data {
+ struct priv_timer priv_timer[RTE_MAX_LCORE];
+ uint8_t internal_flags;
+};
+
+#define RTE_MAX_DATA_ELS 64
+static struct rte_timer_data *rte_timer_data_arr;
+static const uint32_t default_data_id;
+static uint32_t rte_timer_subsystem_initialized;
+
+/* For maintaining older interfaces for a period */
+static struct rte_timer_data default_timer_data;
/* when debug is enabled, store some statistics */
#ifdef RTE_LIBRTE_TIMER_DEBUG
-#define __TIMER_STAT_ADD(name, n) do { \
+#define __TIMER_STAT_ADD(priv_timer, name, n) do { \
unsigned __lcore_id = rte_lcore_id(); \
if (__lcore_id < RTE_MAX_LCORE) \
priv_timer[__lcore_id].stats.name += (n); \
} while(0)
#else
-#define __TIMER_STAT_ADD(name, n) do {} while(0)
+#define __TIMER_STAT_ADD(priv_timer, name, n) do {} while (0)
#endif
-/* Init the timer library. */
+static inline int
+timer_data_valid(uint32_t id)
+{
+ return !!(rte_timer_data_arr[id].internal_flags & FL_ALLOCATED);
+}
+
+/* validate ID and retrieve timer data pointer, or return error value */
+#define TIMER_DATA_VALID_GET_OR_ERR_RET(id, timer_data, retval) do { \
+ if (id >= RTE_MAX_DATA_ELS || !timer_data_valid(id))\
+ return retval; \
+ timer_data = &rte_timer_data_arr[id]; \
+} while (0)
+
+int __rte_experimental
+rte_timer_data_alloc(uint32_t *id_ptr)
+{
+ int i;
+ struct rte_timer_data *data;
+
+ if (!rte_timer_subsystem_initialized)
+ return -ENOMEM;
+
+ for (i = 0; i < RTE_MAX_DATA_ELS; i++) {
+ data = &rte_timer_data_arr[i];
+ if (!(data->internal_flags & FL_ALLOCATED)) {
+ data->internal_flags |= FL_ALLOCATED;
+
+
[dpdk-dev] [PATCH v5 0/2] Timer library changes
This patch series modifies the timer library in such a way that structures that used to be statically allocated in a process's data segment are now allocated in shared memory. As these structures contain lists of timers, new APIs are introduced that allow a caller to specify the particular structure instance into which a timer should be inserted or from which a timer should be removed. This enables primary and secondary processes to modify the same timer list, which enables some multi-process use cases that were not previously possible; e.g. a secondary process can start a timer whose expiration is detected in a primary process running a new flavor of timer_manage(). The original library API is mostly unchanged, though implementations are updated to call into newly added functions with a default structure instance ID that provides the original behavior. New functions are introduced to enable applications to allocate structure instances to house timer lists, and to reference them with an identifier when starting and stopping timers, and finally, to manage the timer lists referenced with an identifier. My initial performance testing with the "timer_perf_autotest" test shows no performance regression or improvement, and inspection of the generated optimized code shows that the extra function call gets inlined in the functions that now have an extra function call. Changes in v5: - define default_data_id as const (Robert) - modify for-loop control in rte_timer_alt_manage and rte_timer_stop_all (Robert) - change parameter type in rte_timer_alt_manage_cb_t from "void *" to "struct rte_timer *" (Robert) Changes in v4: - Updated versioned symbols so that they correspond to the next release. Checked ABI compatibility again with validate-abi.sh. Changes in v3: - remove C++ style comment in first patch in series (Stephen) Changes in v2: - split these changes out into their own series - version the symbols where the existing ABI was updated, and provide alternate implementation with behavior equivalent to original behavior. Validated ABI compatibility with validate-abi.sh - refactor changes to simplify patches Erik Gabriel Carrillo (2): timer: allow timer management in shared memory timer: add function to stop all timers in a list lib/librte_timer/Makefile | 1 + lib/librte_timer/rte_timer.c | 557 ++--- lib/librte_timer/rte_timer.h | 258 ++- lib/librte_timer/rte_timer_version.map | 23 ++ 4 files changed, 794 insertions(+), 45 deletions(-) -- 2.6.4
[dpdk-dev] [PATCH v5 2/2] timer: add function to stop all timers in a list
Add a function to the timer API that allows a caller to traverse a
specified set of timer lists, stopping each timer in each list,
and invoking a callback function.
Signed-off-by: Erik Gabriel Carrillo
---
lib/librte_timer/rte_timer.c | 38 ++
lib/librte_timer/rte_timer.h | 32
lib/librte_timer/rte_timer_version.map | 1 +
3 files changed, 71 insertions(+)
diff --git a/lib/librte_timer/rte_timer.c b/lib/librte_timer/rte_timer.c
index 511d902..ae5d236 100644
--- a/lib/librte_timer/rte_timer.c
+++ b/lib/librte_timer/rte_timer.c
@@ -999,6 +999,44 @@ rte_timer_alt_manage(uint32_t timer_data_id,
return 0;
}
+/* Walk pending lists, stopping timers and calling user-specified function */
+int __rte_experimental
+rte_timer_stop_all(uint32_t timer_data_id, unsigned int *walk_lcores,
+ int nb_walk_lcores,
+ rte_timer_stop_all_cb_t f, void *f_arg)
+{
+ int i;
+ struct priv_timer *priv_timer;
+ uint32_t walk_lcore;
+ struct rte_timer *tim, *next_tim;
+ struct rte_timer_data *timer_data;
+
+ TIMER_DATA_VALID_GET_OR_ERR_RET(timer_data_id, timer_data, -EINVAL);
+
+ for (i = 0; i < nb_walk_lcores; i++) {
+ walk_lcore = walk_lcores[i];
+ priv_timer = &timer_data->priv_timer[walk_lcore];
+
+ rte_spinlock_lock(&priv_timer->list_lock);
+
+ for (tim = priv_timer->pending_head.sl_next[0];
+tim != NULL;
+tim = next_tim) {
+ next_tim = tim->sl_next[0];
+
+ /* Call timer_stop with lock held */
+ __rte_timer_stop(tim, 1, timer_data);
+
+ if (f)
+ f(tim, f_arg);
+ }
+
+ rte_spinlock_unlock(&priv_timer->list_lock);
+ }
+
+ return 0;
+}
+
/* dump statistics about timers */
static void
__rte_timer_dump_stats(struct rte_timer_data *timer_data __rte_unused, FILE *f)
diff --git a/lib/librte_timer/rte_timer.h b/lib/librte_timer/rte_timer.h
index 6a9c499..b502f8c 100644
--- a/lib/librte_timer/rte_timer.h
+++ b/lib/librte_timer/rte_timer.h
@@ -500,6 +500,38 @@ rte_timer_alt_manage(uint32_t timer_data_id, unsigned int
*poll_lcores,
int n_poll_lcores, rte_timer_alt_manage_cb_t f);
/**
+ * Callback function type for rte_timer_stop_all().
+ */
+typedef void (*rte_timer_stop_all_cb_t)(struct rte_timer *tim, void *arg);
+
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice
+ *
+ * Walk the pending timer lists for the specified lcore IDs, and for each timer
+ * that is encountered, stop it and call the specified callback function to
+ * process it further.
+ *
+ * @param timer_data_id
+ * An identifier indicating which instance of timer data should be used for
+ * this operation.
+ * @param walk_lcores
+ * An array of lcore ids identifying the timer lists that should be
processed.
+ * @param nb_walk_lcores
+ * The size of the walk_lcores array.
+ * @param f
+ * The callback function which should be called for each timers. Can be NULL.
+ * @param f_arg
+ * An arbitrary argument that will be passed to f, if it is called.
+ * @return
+ * - 0: success
+ * - EINVAL: invalid timer_data_id
+ */
+int __rte_experimental
+rte_timer_stop_all(uint32_t timer_data_id, unsigned int *walk_lcores,
+ int nb_walk_lcores, rte_timer_stop_all_cb_t f, void *f_arg);
+
+/**
* @warning
* @b EXPERIMENTAL: this API may change without prior notice
*
diff --git a/lib/librte_timer/rte_timer_version.map
b/lib/librte_timer/rte_timer_version.map
index c2e5836..72f75c8 100644
--- a/lib/librte_timer/rte_timer_version.map
+++ b/lib/librte_timer/rte_timer_version.map
@@ -33,5 +33,6 @@ EXPERIMENTAL {
rte_timer_alt_stop;
rte_timer_data_alloc;
rte_timer_data_dealloc;
+ rte_timer_stop_all;
rte_timer_subsystem_finalize;
};
--
2.6.4
Re: [dpdk-dev] [PATCH v4 1/2] timer: allow timer management in shared memory
Hi Robert,
I'm back in the office now; I just submitted an updated patch series to
address some of the points you made below. I'll add responses in-line:
> -Original Message-
> From: Sanford, Robert [mailto:rsanf...@akamai.com]
> Sent: Wednesday, March 20, 2019 8:53 AM
> To: Carrillo, Erik G ; tho...@monjalon.net;
> dev@dpdk.org
> Cc: nhor...@tuxdriver.com
> Subject: Re: [PATCH v4 1/2] timer: allow timer management in shared
> memory
>
> Hi Erik,
>
> I have a few questions and comments on this patch series.
>
> 1. Don't you think we need new tests (in test/test/) to verify the secondary-
> process APIs?
Yes, good idea. I'll work on a separate patch to add this.
> 2. I suggest we define default_data_id as const, and explicitly set it to 0.
I did change this to const, but ommitted the explicit initialization because
checkpatch
complains with the following: "ERROR:INITIALISED_STATIC: do not initialise
statics to 0".
> 3. The outer for-loop in rte_timer_alt_manage() touches beyond the end of
> poll_lcores[]. I suggest a change like this:
>
> - for (i = 0, poll_lcore = poll_lcores[i]; i < nb_poll_lcores;
> -poll_lcore = poll_lcores[++i]) {
> + for (i = 0; I < nb_poll_lcores; i++) {
> +poll_lcore = poll_lcores[i];
>
Change made.
> 4. Same problem (as #3) in the for-loop in rte_timer_stop_all(), in patch v4
> 2/2.
Change made.
> 5. There seems to be no difference between "typedef void
> (*rte_timer_cb_t)(struct rte_timer *, void *)" and "typedef void
> (*rte_timer_stop_all_cb_t)(struct rte_timer *tim, void *arg)", why add
> rte_timer_stop_all_cb_t?
Though they have the same signature, it seemed clearer to me to have a new
callback
type since one represents a function that gets called per timer, and the other
represents
a function that gets called for all timers.
> 6. Can you provide a use case or code snippet that shows how we will use
> rte_timer_alt_manage()?
Currently this function is used by an updated version of the software event
timer
adapter (http://patchwork.dpdk.org/patch/48944/); rte_timer_alt_manage() is
called in
the service function for an instance of the adapter. Since this function
allows timer_data_ids
to be specified, different instances of the adapter can manage their own
separate timer lists
independently.
> 7. Why not make the argument to rte_timer_alt_manage_cb_t a "struct
> rte_timer *", instead of a "void *", since we pass a pointer-to-timer when we
> invoke the function?
>
Change made.
> --
> Regards,
> Robert Sanford
>
Thanks,
Erik
Re: [dpdk-dev] [PATCH] doc: update ICE doc
Hi, In I40E DPDK nic guide, https://doc.dpdk.org/guides/nics/i40e.html, MDD does not appear. In IXGBE DPDK nic guide, https://doc.dpdk.org/guides/nics/ixgbe.html, MDD appears, but in the known issues section. I think MDD is supported on both. just wonder, for the sake of consistency, is it worth to add such a section also for these nics ? Other than that, Acked-by: Rami Rosen
Re: [dpdk-dev] [PATCH] devtools: accept experimental symbol promotion
05/04/2019 13:22, Neil Horman:
> On Fri, Apr 05, 2019 at 10:17:47AM +0200, David Marchand wrote:
> > Currently, when symbols get promoted from the EXPERIMENTAL section to a
> > stable ABI section, the script complains they should go to the
> > EXPERIMENTAL section.
> >
> > Example:
> > ERROR: symbol rte_devargs_add is added in the DPDK_19.05 section, but is
> > expected to be added in the EXPERIMENTAL section of the version map
> >
> > This is legit.
> > Moving from a stable ABI to another is also allowed, but must have gone
> > through the proper process.
> >
> > Fixes: 4bec48184e33 ("devtools: add checks for ABI symbol addition")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: David Marchand
> Acked-by: Neil Horman
Applied, thanks
Re: [dpdk-dev] [PATCH] devtools: add git log checks for TPID, LACP and RETA
08/04/2019 18:37, Ferruh Yigit: > Add case check to TPID, LACP and RETA abbreviations. > > Signed-off-by: Ferruh Yigit > --- > -e ':.*\' \ > -e ':.*\' \ > + -e ':.*\' \ > -e ':.*\' \ Applied with alphabetical order fixed, thanks
[dpdk-dev] [PATCH] fbarray: get fbarrays from containerized secondary
From: Yasufumi Ogawa
In secondary_msl_create_walk(), it creates a file for fbarrays with its
PID for reserving unique name among secondary processes. However, it
does not work as expected if secondary is run as app container becuase
each of containerized secondary has PID 1. To reserve unique name, use
hostname instead of PID if the value is 1.
Cc: sta...@dpdk.org
Signed-off-by: Yasufumi Ogawa
---
lib/librte_eal/linux/eal/eal_memalloc.c | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/lib/librte_eal/linux/eal/eal_memalloc.c
b/lib/librte_eal/linux/eal/eal_memalloc.c
index 1e9ebb86d..beec03648 100644
--- a/lib/librte_eal/linux/eal/eal_memalloc.c
+++ b/lib/librte_eal/linux/eal/eal_memalloc.c
@@ -1362,6 +1362,7 @@ secondary_msl_create_walk(const struct rte_memseg_list
*msl,
struct rte_memseg_list *primary_msl, *local_msl;
char name[PATH_MAX];
int msl_idx, ret;
+ char proc_id[16];
if (msl->external)
return 0;
@@ -1371,8 +1372,28 @@ secondary_msl_create_walk(const struct rte_memseg_list
*msl,
local_msl = &local_memsegs[msl_idx];
/* create distinct fbarrays for each secondary */
- snprintf(name, RTE_FBARRAY_NAME_LEN, "%s_%i",
- primary_msl->memseg_arr.name, getpid());
+ /* if run secondary in a container, the name of fbarray file cannot
+* be decided with pid because getpid() always returns 1, so use
+* hostname as a unique identifier among containers instead.
+*/
+ if (getpid() == 1) {
+ FILE *hn_fp;
+ hn_fp = fopen("/etc/hostname", "r");
+ if (hn_fp == NULL) {
+ RTE_LOG(ERR, EAL,
+ "Cannot open '/etc/hostname' for secondary\n");
+ return -1;
+ }
+
+ /* with docker, /etc/hostname just has one entry of hostname */
+ if (fscanf(hn_fp, "%s", proc_id) == EOF)
+ return -1;
+ fclose(hn_fp);
+ } else
+ sprintf(proc_id, "%d", (int)getpid());
+
+ snprintf(name, RTE_FBARRAY_NAME_LEN, "%s_%s",
+ primary_msl->memseg_arr.name, proc_id);
ret = rte_fbarray_init(&local_msl->memseg_arr, name,
primary_msl->memseg_arr.len,
--
2.17.1
Re: [dpdk-dev] [PATCH] net/i40e: fix crash when calling i40e_vsi_delete_mac
> > That is not specific to i40e or macvlan filter. > If inside your app several threads concurrently access/modify NIC config, > then you need to provide some synchronization mechanism for them. > DPDK ethdev API (as most others) on itself doesn't provide any > synchronization, leaving it up to the upper layer to choose the most > appropriate one. > Konstantin Thanks. Now the lsc thread isn't controled by the upper layer. Do you have any idea to fix it? Thanks, Yunjian
Re: [dpdk-dev] [PATCH v8 02/14] bus/ifpga: add function for AFU search by name
> -Original Message-
> From: Yigit, Ferruh
> Sent: Monday, April 15, 2019 20:28
> To: Xu, Rosen ; dev@dpdk.org
> Cc: Zhang, Tianfei ; Wei, Dan
> ; Pei, Andy ; Yang, Qiming
> ; Wang, Haiyue ; Chen,
> Santos ; Zhang, Zhang ;
> Lomartire, David ; Hu, Jia ;
> Thomas Monjalon
> Subject: Re: [PATCH v8 02/14] bus/ifpga: add function for AFU search by
> name
>
> On 4/15/2019 6:06 AM, Rosen Xu wrote:
> > In many scenarios, AFU is needed searched by name, this function add
> > the feature.
> >
> > Signed-off-by: Rosen Xu
> > Signed-off-by: Andy Pei
> > ---
> > drivers/bus/ifpga/ifpga_bus.c | 13 +
> > drivers/bus/ifpga/rte_bus_ifpga.h | 9 +
> > drivers/bus/ifpga/rte_bus_ifpga_version.map | 6 ++
> > 3 files changed, 28 insertions(+)
> >
> > diff --git a/drivers/bus/ifpga/ifpga_bus.c
> > b/drivers/bus/ifpga/ifpga_bus.c index 55d3abf..8bfae29 100644
> > --- a/drivers/bus/ifpga/ifpga_bus.c
> > +++ b/drivers/bus/ifpga/ifpga_bus.c
> > @@ -73,6 +73,19 @@ void rte_ifpga_driver_unregister(struct
> rte_afu_driver *driver)
> > return NULL;
> > }
> >
> > +struct rte_afu_device *__rte_experimental
> > +rte_ifpga_find_afu_by_name(const char *name) {
> > + struct rte_afu_device *afu_dev = NULL;
> > +
> > + TAILQ_FOREACH(afu_dev, &ifpga_afu_dev_list, next) {
> > + if (afu_dev &&
> > + !strcmp(afu_dev->device.name, name))
> > + return afu_dev;
> > + }
> > + return NULL;
> > +}
> > +
> > static const char * const valid_args[] = {
> > #define IFPGA_ARG_NAME "ifpga"
> > IFPGA_ARG_NAME,
> > diff --git a/drivers/bus/ifpga/rte_bus_ifpga.h
> > b/drivers/bus/ifpga/rte_bus_ifpga.h
> > index 820eeaa..c00f60e 100644
> > --- a/drivers/bus/ifpga/rte_bus_ifpga.h
> > +++ b/drivers/bus/ifpga/rte_bus_ifpga.h
> > @@ -120,6 +120,15 @@ struct rte_afu_driver { }
> >
> > /**
> > + * Find AFU by AFU name.
> > + *
> > + * @param name
> > + * A pointer to AFU name string.
> > + */
> > +struct rte_afu_device *__rte_experimental
> > +rte_ifpga_find_afu_by_name(const char *name);
> > +
>
>
> Hi Rosen,
>
> This is the bus code, and only drivers will call it right? I think there is no
> intention to make this run by application code, the functions need to be
> exported because driver and bus are different libraries.
> If above correct, there is no point of making the function experimental, can
> drop the __rte_experimental tag, and update .map file to not use
> EXPERIMENTAL.
Hi Ferruh,
Just double confirm with you, if I follow this modification, there is one
checkpatch error.
>
> > +/**
> > * Register a ifpga afu device driver.
> > *
> > * @param driver
> > diff --git a/drivers/bus/ifpga/rte_bus_ifpga_version.map
> > b/drivers/bus/ifpga/rte_bus_ifpga_version.map
> > index a027979..247ccfe 100644
> > --- a/drivers/bus/ifpga/rte_bus_ifpga_version.map
> > +++ b/drivers/bus/ifpga/rte_bus_ifpga_version.map
> > @@ -8,3 +8,9 @@ DPDK_18.05 {
> >
> > local: *;
> > };
> > +
> > +EXPERIMENTAL {
> > +global:
> > +
> > +rte_ifpga_find_afu_by_name;
> > +};
> > \ No newline at end of file
> >
[dpdk-dev] [PATCH v9 01/14] bus/ifpga: add AFU shared data
AFU can be implemented into many different acceleration
devices, these devices need shared data to store private
information when they are handled by users.
Signed-off-by: Rosen Xu
Signed-off-by: Andy Pei
---
drivers/bus/ifpga/rte_bus_ifpga.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/bus/ifpga/rte_bus_ifpga.h
b/drivers/bus/ifpga/rte_bus_ifpga.h
index 0bf43ba..820eeaa 100644
--- a/drivers/bus/ifpga/rte_bus_ifpga.h
+++ b/drivers/bus/ifpga/rte_bus_ifpga.h
@@ -17,6 +17,7 @@
#include
#include
+#include
/** Name of Intel FPGA Bus */
#define IFPGA_BUS_NAME ifpga
@@ -60,6 +61,11 @@ struct rte_afu_pr_conf {
#define AFU_PRI_STR_SIZE (PCI_PRI_STR_SIZE + 8)
+struct rte_afu_shared {
+ rte_spinlock_t lock;
+ void *data;
+};
+
/**
* A structure describing a AFU device.
*/
@@ -71,6 +77,7 @@ struct rte_afu_device {
uint32_t num_region; /**< number of regions found */
struct rte_mem_resource mem_resource[PCI_MAX_RESOURCE];
/**< AFU Memory Resource */
+ struct rte_afu_shared shared;
struct rte_intr_handle intr_handle; /**< Interrupt handle */
struct rte_afu_driver *driver; /**< Associated driver */
char path[IFPGA_BUS_BITSTREAM_PATH_MAX_LEN];
--
1.8.3.1
[dpdk-dev] [PATCH v9 02/14] bus/ifpga: add function for AFU search by name
In many scenarios, AFU is needed searched by name, this
function add the feature.
Signed-off-by: Rosen Xu
Signed-off-by: Andy Pei
---
drivers/bus/ifpga/ifpga_bus.c | 13 +
drivers/bus/ifpga/rte_bus_ifpga.h | 9 +
drivers/bus/ifpga/rte_bus_ifpga_version.map | 9 +
3 files changed, 31 insertions(+)
diff --git a/drivers/bus/ifpga/ifpga_bus.c b/drivers/bus/ifpga/ifpga_bus.c
index 55d3abf..dfd6b1f 100644
--- a/drivers/bus/ifpga/ifpga_bus.c
+++ b/drivers/bus/ifpga/ifpga_bus.c
@@ -73,6 +73,19 @@ void rte_ifpga_driver_unregister(struct rte_afu_driver
*driver)
return NULL;
}
+struct rte_afu_device *
+rte_ifpga_find_afu_by_name(const char *name)
+{
+ struct rte_afu_device *afu_dev = NULL;
+
+ TAILQ_FOREACH(afu_dev, &ifpga_afu_dev_list, next) {
+ if (afu_dev &&
+ !strcmp(afu_dev->device.name, name))
+ return afu_dev;
+ }
+ return NULL;
+}
+
static const char * const valid_args[] = {
#define IFPGA_ARG_NAME "ifpga"
IFPGA_ARG_NAME,
diff --git a/drivers/bus/ifpga/rte_bus_ifpga.h
b/drivers/bus/ifpga/rte_bus_ifpga.h
index 820eeaa..88a6289 100644
--- a/drivers/bus/ifpga/rte_bus_ifpga.h
+++ b/drivers/bus/ifpga/rte_bus_ifpga.h
@@ -120,6 +120,15 @@ struct rte_afu_driver {
}
/**
+ * Find AFU by AFU name.
+ *
+ * @param name
+ * A pointer to AFU name string.
+ */
+struct rte_afu_device *
+rte_ifpga_find_afu_by_name(const char *name);
+
+/**
* Register a ifpga afu device driver.
*
* @param driver
diff --git a/drivers/bus/ifpga/rte_bus_ifpga_version.map
b/drivers/bus/ifpga/rte_bus_ifpga_version.map
index a027979..51b1353 100644
--- a/drivers/bus/ifpga/rte_bus_ifpga_version.map
+++ b/drivers/bus/ifpga/rte_bus_ifpga_version.map
@@ -8,3 +8,12 @@ DPDK_18.05 {
local: *;
};
+
+DPDK_19.05 {
+ global:
+
+ rte_ifpga_find_afu_by_name;
+
+ local: *;
+};
+
--
1.8.3.1
[dpdk-dev] [PATCH v9 00/14] Add patch set for IPN3KE
v9 updates: = - Fix v8 comments - 02/14 patch check error, just follow Ferruh's v8 comments v8 updates: = - Fix meter color definition replacement v7 updates: = - Fix Stephen comments v6 updates: == - Fix v5 comments - Fix TM Shaper rate issue v5 updates: == - Fix EXPERIMENTAL symbol definition issue v4 updates: == - Fix coding style issues v3 updates: == - Fix v2 comments - Update MAC BAR of AFU index get ops - Remove OPAE share code dependency of libfdt v2 updates: == - Fix v1 comments - Add support for 10G Base Line Design Bitstream - Add support for 25G Base Line Design Bitstream This patch set adds the support of a new net PMD, Intel?? FPGA Programmable Acceleration Card N3000, also called ipn3ke. The ipn3ke PMD (librte_pmd_ipn3ke) provides poll mode driver support for Intel?? FPGA PAC(Programmable Acceleration Card) N3000 based on the Intel Ethernet Controller X710/XXV710 and Intel Arria 10 FPGA. In this card, FPGA is an acceleration bridge between network interface and the Intel Ethernet Controller. Although both FPGA and Ethernet Controllers are connected to CPU with PCIe Gen3x16 Switch, all the packet RX/TX is handled by Intel Ethernet Controller. So from application point of view the data path is still the legacy Intel Ethernet Controller X710/XXV710 PMD. Besides this, users can enable more acceleration Rosen Xu (7): bus/ifpga: add AFU shared data bus/ifpga: add function for AFU search by name net/ipn3ke: add IPN3KE ethdev PMD driver net/ipn3ke: add IPN3KE representor of PMD driver net/ipn3ke: add IPN3KE TM of PMD driver net/ipn3ke: add IPN3KE Flow of PMD driver raw/ifpga_rawdev: add IPN3KE support for IFPGA Rawdev Tianfei zhang (7): raw/ifpga_rawdev: clean up code for ifpga share code raw/ifpga_rawdev: store private features in FME and Port raw/ifpga_rawdev: add SPI and MAX10 device driver raw/ifpga_rawdev: add I2C and at24 EEPROM driver raw/ifpga_rawdev: add eth group driver raw/ifpga_rawdev: add version description on README raw/ifpga_rawdev: using prefix name for feature and its ops MAINTAINERS|7 + config/common_base |4 + doc/guides/nics/features/ipn3ke.ini| 55 + doc/guides/nics/index.rst |1 + doc/guides/nics/ipn3ke.rst | 107 + drivers/bus/ifpga/ifpga_bus.c | 13 + drivers/bus/ifpga/rte_bus_ifpga.h | 16 + drivers/bus/ifpga/rte_bus_ifpga_version.map|9 + drivers/net/Makefile |1 + drivers/net/ipn3ke/Makefile| 40 + drivers/net/ipn3ke/ipn3ke_ethdev.c | 653 ++ drivers/net/ipn3ke/ipn3ke_ethdev.h | 975 + drivers/net/ipn3ke/ipn3ke_flow.c | 1374 + drivers/net/ipn3ke/ipn3ke_flow.h | 106 + drivers/net/ipn3ke/ipn3ke_logs.h | 30 + drivers/net/ipn3ke/ipn3ke_rawdev_api.h | 62 + drivers/net/ipn3ke/ipn3ke_representor.c| 893 + drivers/net/ipn3ke/ipn3ke_tm.c | 2069 drivers/net/ipn3ke/meson.build | 17 + drivers/net/ipn3ke/rte_pmd_ipn3ke_version.map |4 + drivers/net/meson.build|1 + drivers/raw/ifpga_rawdev/Makefile |1 + drivers/raw/ifpga_rawdev/base/Makefile |6 + drivers/raw/ifpga_rawdev/base/README | 15 + drivers/raw/ifpga_rawdev/base/ifpga_api.c | 98 +- drivers/raw/ifpga_rawdev/base/ifpga_api.h |1 + drivers/raw/ifpga_rawdev/base/ifpga_defines.h | 93 +- drivers/raw/ifpga_rawdev/base/ifpga_enumerate.c| 357 ++-- drivers/raw/ifpga_rawdev/base/ifpga_feature_dev.c | 174 +- drivers/raw/ifpga_rawdev/base/ifpga_feature_dev.h | 99 +- drivers/raw/ifpga_rawdev/base/ifpga_fme.c | 602 +- drivers/raw/ifpga_rawdev/base/ifpga_fme_dperf.c| 16 +- drivers/raw/ifpga_rawdev/base/ifpga_fme_error.c| 18 +- drivers/raw/ifpga_rawdev/base/ifpga_fme_iperf.c| 28 +- drivers/raw/ifpga_rawdev/base/ifpga_fme_pr.c |8 +- drivers/raw/ifpga_rawdev/base/ifpga_hw.h | 44 +- drivers/raw/ifpga_rawdev/base/ifpga_port.c | 51 +- drivers/raw/ifpga_rawdev/base/ifpga_port_error.c | 10 +- drivers/raw/ifpga_rawdev/base/meson.build |8 +- drivers/raw/ifpga_rawdev/base/opae_at24_eeprom.c | 88 + drivers/raw/ifpga_rawdev/base/opae_at24_eeprom.h | 14 + drivers/raw/ifpga_rawdev/base/opae_debug.c | 16 +- drivers/raw/ifpga_rawdev/base/opae_eth_group.c | 145 ++ drivers/raw/ifpga_rawdev/base/opae_eth_group.h | 96 + drivers/raw/ifpga_rawdev/base/opae_hw_api.c| 200 +- drivers/raw/ifpga_rawdev/b
[dpdk-dev] [PATCH v9 04/14] net/ipn3ke: add IPN3KE representor of PMD driver
Add Intel FPGA Acceleration NIC IPN3KE representor of PMD driver.
Signed-off-by: Rosen Xu
Signed-off-by: Andy Pei
Signed-off-by: Dan Wei
---
drivers/net/ipn3ke/Makefile | 2 +
drivers/net/ipn3ke/ipn3ke_ethdev.c | 4 +-
drivers/net/ipn3ke/ipn3ke_ethdev.h | 25 +
drivers/net/ipn3ke/ipn3ke_representor.c | 887
drivers/net/ipn3ke/meson.build | 3 +-
5 files changed, 918 insertions(+), 3 deletions(-)
create mode 100644 drivers/net/ipn3ke/ipn3ke_representor.c
diff --git a/drivers/net/ipn3ke/Makefile b/drivers/net/ipn3ke/Makefile
index d7aa79b..221567d 100644
--- a/drivers/net/ipn3ke/Makefile
+++ b/drivers/net/ipn3ke/Makefile
@@ -23,6 +23,7 @@ LDLIBS += -lrte_eal -lrte_mbuf -lrte_mempool -lrte_ring
LDLIBS += -lrte_ethdev -lrte_net -lrte_kvargs
LDLIBS += -lrte_bus_ifpga
LDLIBS += -lrte_bus_vdev
+LDLIBS += -lpthread
EXPORT_MAP := rte_pmd_ipn3ke_version.map
@@ -32,5 +33,6 @@ LIBABIVER := 1
# all source are stored in SRCS-y
#
SRCS-$(CONFIG_RTE_LIBRTE_IPN3KE_PMD) += ipn3ke_ethdev.c
+SRCS-$(CONFIG_RTE_LIBRTE_IPN3KE_PMD) += ipn3ke_representor.c
include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/drivers/net/ipn3ke/ipn3ke_ethdev.c
b/drivers/net/ipn3ke/ipn3ke_ethdev.c
index d5fee6f..58c8ce4 100644
--- a/drivers/net/ipn3ke/ipn3ke_ethdev.c
+++ b/drivers/net/ipn3ke/ipn3ke_ethdev.c
@@ -339,7 +339,7 @@ static int ipn3ke_vswitch_probe(struct rte_afu_device
*afu_dev)
retval = rte_eth_dev_create(&afu_dev->device, name,
sizeof(struct ipn3ke_rpst), NULL, NULL,
- NULL, &rpst);
+ ipn3ke_rpst_init, &rpst);
if (retval)
IPN3KE_AFU_PMD_ERR("failed to create ipn3ke representor
%s.",
@@ -368,7 +368,7 @@ static int ipn3ke_vswitch_remove(struct rte_afu_device
*afu_dev)
if (!ethdev)
return -ENODEV;
- rte_eth_dev_destroy(ethdev, NULL);
+ rte_eth_dev_destroy(ethdev, ipn3ke_rpst_uninit);
}
ret = rte_eth_switch_domain_free(hw->switch_domain_id);
diff --git a/drivers/net/ipn3ke/ipn3ke_ethdev.h
b/drivers/net/ipn3ke/ipn3ke_ethdev.h
index 09d085c..d2c73e5 100644
--- a/drivers/net/ipn3ke/ipn3ke_ethdev.h
+++ b/drivers/net/ipn3ke/ipn3ke_ethdev.h
@@ -527,6 +527,31 @@ static inline void _ipn3ke_indrct_write(struct ipn3ke_hw
*hw,
#define IPN3KE_CLF_MHL_RES_MASK0x
#define IPN3KE_CLF_MHL_RES (IPN3KE_CLASSIFY_OFFSET + 0x5 + 0x2000)
+int
+ipn3ke_rpst_dev_set_link_up(struct rte_eth_dev *dev);
+int
+ipn3ke_rpst_dev_set_link_down(struct rte_eth_dev *dev);
+int
+ipn3ke_rpst_link_update(struct rte_eth_dev *ethdev,
+ __rte_unused int wait_to_complete);
+void
+ipn3ke_rpst_promiscuous_enable(struct rte_eth_dev *ethdev);
+void
+ipn3ke_rpst_promiscuous_disable(struct rte_eth_dev *ethdev);
+void
+ipn3ke_rpst_allmulticast_enable(struct rte_eth_dev *ethdev);
+void
+ipn3ke_rpst_allmulticast_disable(struct rte_eth_dev *ethdev);
+int
+ipn3ke_rpst_mac_addr_set(struct rte_eth_dev *ethdev,
+ struct ether_addr *mac_addr);
+int
+ipn3ke_rpst_mtu_set(struct rte_eth_dev *ethdev, uint16_t mtu);
+
+int
+ipn3ke_rpst_init(struct rte_eth_dev *ethdev, void *init_params);
+int
+ipn3ke_rpst_uninit(struct rte_eth_dev *ethdev);
/* IPN3KE_MASK is a macro used on 32 bit registers */
diff --git a/drivers/net/ipn3ke/ipn3ke_representor.c
b/drivers/net/ipn3ke/ipn3ke_representor.c
new file mode 100644
index 000..3831982
--- /dev/null
+++ b/drivers/net/ipn3ke/ipn3ke_representor.c
@@ -0,0 +1,887 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2019 Intel Corporation
+ */
+
+#include
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include "ipn3ke_rawdev_api.h"
+#include "ipn3ke_logs.h"
+#include "ipn3ke_ethdev.h"
+
+static int ipn3ke_rpst_scan_num;
+static pthread_t ipn3ke_rpst_scan_thread;
+
+/** Double linked list of representor port. */
+TAILQ_HEAD(ipn3ke_rpst_list, ipn3ke_rpst);
+
+static struct ipn3ke_rpst_list ipn3ke_rpst_list =
+ TAILQ_HEAD_INITIALIZER(ipn3ke_rpst_list);
+
+static rte_spinlock_t ipn3ke_link_notify_list_lk = RTE_SPINLOCK_INITIALIZER;
+
+static int
+ipn3ke_rpst_link_check(struct ipn3ke_rpst *rpst);
+
+static void
+ipn3ke_rpst_dev_infos_get(struct rte_eth_dev *ethdev,
+ struct rte_eth_dev_info *dev_info)
+{
+ struct ipn3ke_rpst *rpst = IPN3KE_DEV_PRIVATE_TO_RPST(ethdev);
+ struct ipn3ke_hw *hw = IPN3KE_DEV_PRIVATE_TO_HW(ethdev);
+
+ dev_info->speed_capa =
+ (hw->retimer.mac_type ==
+ IFPGA_RAWDEV_RETIMER_MAC_TYPE_10GE_XFI) ?
+ ETH_LINK_SPEED_10G :
+ ((hw->retimer.mac_type ==
+ IFPGA_RAWDEV_RETIMER_MAC_TYPE_25GE_25GAUI) ?
+ ETH_LINK_SPEED_25G :
+ ETH_LINK_SPEED_AUTON
[dpdk-dev] [PATCH v9 05/14] net/ipn3ke: add IPN3KE TM of PMD driver
Add Intel FPGA Acceleration NIC IPN3KE TM of PMD driver.
Signed-off-by: Rosen Xu
Signed-off-by: Andy Pei
Signed-off-by: Dan Wei
---
drivers/net/ipn3ke/Makefile |1 +
drivers/net/ipn3ke/ipn3ke_ethdev.c |3 +
drivers/net/ipn3ke/ipn3ke_ethdev.h |7 +
drivers/net/ipn3ke/ipn3ke_representor.c |5 +
drivers/net/ipn3ke/ipn3ke_tm.c | 2068 +++
drivers/net/ipn3ke/meson.build |3 +-
6 files changed, 2086 insertions(+), 1 deletion(-)
create mode 100644 drivers/net/ipn3ke/ipn3ke_tm.c
diff --git a/drivers/net/ipn3ke/Makefile b/drivers/net/ipn3ke/Makefile
index 221567d..38d9384 100644
--- a/drivers/net/ipn3ke/Makefile
+++ b/drivers/net/ipn3ke/Makefile
@@ -34,5 +34,6 @@ LIBABIVER := 1
#
SRCS-$(CONFIG_RTE_LIBRTE_IPN3KE_PMD) += ipn3ke_ethdev.c
SRCS-$(CONFIG_RTE_LIBRTE_IPN3KE_PMD) += ipn3ke_representor.c
+SRCS-$(CONFIG_RTE_LIBRTE_IPN3KE_PMD) += ipn3ke_tm.c
include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/drivers/net/ipn3ke/ipn3ke_ethdev.c
b/drivers/net/ipn3ke/ipn3ke_ethdev.c
index 58c8ce4..508ea01 100644
--- a/drivers/net/ipn3ke/ipn3ke_ethdev.c
+++ b/drivers/net/ipn3ke/ipn3ke_ethdev.c
@@ -262,6 +262,9 @@
hw->flow_hw_enable = 0;
if (afu_dev->id.uuid.uuid_low == IPN3KE_UUID_VBNG_LOW &&
afu_dev->id.uuid.uuid_high == IPN3KE_UUID_VBNG_HIGH) {
+ ret = ipn3ke_hw_tm_init(hw);
+ if (ret)
+ return ret;
hw->tm_hw_enable = 1;
hw->flow_hw_enable = 1;
}
diff --git a/drivers/net/ipn3ke/ipn3ke_ethdev.h
b/drivers/net/ipn3ke/ipn3ke_ethdev.h
index d2c73e5..36ff2f8 100644
--- a/drivers/net/ipn3ke/ipn3ke_ethdev.h
+++ b/drivers/net/ipn3ke/ipn3ke_ethdev.h
@@ -552,6 +552,13 @@ static inline void _ipn3ke_indrct_write(struct ipn3ke_hw
*hw,
ipn3ke_rpst_init(struct rte_eth_dev *ethdev, void *init_params);
int
ipn3ke_rpst_uninit(struct rte_eth_dev *ethdev);
+int
+ipn3ke_hw_tm_init(struct ipn3ke_hw *hw);
+void
+ipn3ke_tm_init(struct ipn3ke_rpst *rpst);
+int
+ipn3ke_tm_ops_get(struct rte_eth_dev *ethdev,
+ void *arg);
/* IPN3KE_MASK is a macro used on 32 bit registers */
diff --git a/drivers/net/ipn3ke/ipn3ke_representor.c
b/drivers/net/ipn3ke/ipn3ke_representor.c
index 3831982..63098bf 100644
--- a/drivers/net/ipn3ke/ipn3ke_representor.c
+++ b/drivers/net/ipn3ke/ipn3ke_representor.c
@@ -801,6 +801,8 @@
.allmulticast_disable = ipn3ke_rpst_allmulticast_disable,
.mac_addr_set = ipn3ke_rpst_mac_addr_set,
.mtu_set = ipn3ke_rpst_mtu_set,
+
+ .tm_ops_get = ipn3ke_tm_ops_get,
};
static uint16_t ipn3ke_rpst_recv_pkts(__rte_unused void *rx_q,
@@ -840,6 +842,9 @@ static uint16_t ipn3ke_rpst_recv_pkts(__rte_unused void
*rx_q,
return -ENODEV;
}
+ if (rpst->hw->tm_hw_enable)
+ ipn3ke_tm_init(rpst);
+
/* Set representor device ops */
ethdev->dev_ops = &ipn3ke_rpst_dev_ops;
diff --git a/drivers/net/ipn3ke/ipn3ke_tm.c b/drivers/net/ipn3ke/ipn3ke_tm.c
new file mode 100644
index 000..8baa2fb
--- /dev/null
+++ b/drivers/net/ipn3ke/ipn3ke_tm.c
@@ -0,0 +1,2068 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2019 Intel Corporation
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include "ipn3ke_rawdev_api.h"
+#include "ipn3ke_logs.h"
+#include "ipn3ke_ethdev.h"
+
+#define BYTES_IN_MBPS (1000 * 1000 / 8)
+#define SUBPORT_TC_PERIOD 10
+#define PIPE_TC_PERIOD40
+
+struct ipn3ke_tm_shaper_params_range_type {
+ uint32_t m1;
+ uint32_t m2;
+ uint32_t exp;
+ uint32_t exp2;
+ uint32_t low;
+ uint32_t high;
+};
+struct ipn3ke_tm_shaper_params_range_type ipn3ke_tm_shaper_params_rang[] = {
+ { 0, 1, 0,1, 0,4},
+ { 2, 3, 0,1, 8, 12},
+ { 4, 7, 0,1, 16, 28},
+ { 8, 15, 0,1, 32, 60},
+ { 16, 31, 0,1, 64, 124},
+ { 32, 63, 0,1, 128, 252},
+ { 64, 127, 0,1, 256, 508},
+ {128, 255, 0,1, 512, 1020},
+ {256, 511, 0,1,1024, 2044},
+ {512,1023, 0,1,2048, 4092},
+ {512,1023, 1,2,4096, 8184},
+ {512,1023, 2,4,8192,16368},
+ {512,1023, 3,8, 16384,32736},
+ {512,1023, 4, 16, 32768,65472},
+ {512,1023, 5, 32, 65536, 130944},
+ {512,1023,
[dpdk-dev] [PATCH v9 07/14] raw/ifpga_rawdev: clean up code for ifpga share code
From: Tianfei zhang
clean up code:
1. use opae_memcpy instead of memcpy
2. use opae_memset instead of memset
3. disable opae_adapter_dump by default
Signed-off-by: Tianfei Zhang
---
drivers/raw/ifpga_rawdev/base/ifpga_api.c | 2 +-
drivers/raw/ifpga_rawdev/base/ifpga_feature_dev.c | 4 ++--
drivers/raw/ifpga_rawdev/base/ifpga_fme_pr.c| 2 +-
drivers/raw/ifpga_rawdev/base/opae_debug.c | 16
drivers/raw/ifpga_rawdev/base/opae_hw_api.c | 2 +-
drivers/raw/ifpga_rawdev/base/opae_osdep.h | 1 +
drivers/raw/ifpga_rawdev/base/osdep_raw/osdep_generic.h | 1 +
drivers/raw/ifpga_rawdev/base/osdep_rte/osdep_generic.h | 2 ++
8 files changed, 17 insertions(+), 13 deletions(-)
diff --git a/drivers/raw/ifpga_rawdev/base/ifpga_api.c
b/drivers/raw/ifpga_rawdev/base/ifpga_api.c
index 540e171..77d9471 100644
--- a/drivers/raw/ifpga_rawdev/base/ifpga_api.c
+++ b/drivers/raw/ifpga_rawdev/base/ifpga_api.c
@@ -202,7 +202,7 @@ static int ifpga_adapter_enumerate(struct opae_adapter
*adapter)
struct ifpga_hw *hw = malloc(sizeof(*hw));
if (hw) {
- memset(hw, 0, sizeof(*hw));
+ opae_memset(hw, 0, sizeof(*hw));
hw->pci_data = adapter->data;
hw->adapter = adapter;
if (ifpga_bus_enumerate(hw))
diff --git a/drivers/raw/ifpga_rawdev/base/ifpga_feature_dev.c
b/drivers/raw/ifpga_rawdev/base/ifpga_feature_dev.c
index be7ac9e..0a27c38 100644
--- a/drivers/raw/ifpga_rawdev/base/ifpga_feature_dev.c
+++ b/drivers/raw/ifpga_rawdev/base/ifpga_feature_dev.c
@@ -77,8 +77,8 @@ int fpga_get_afu_uuid(struct ifpga_port_hw *port, struct uuid
*uuid)
guidh = readq(&port_hdr->afu_header.guid.b[8]);
spinlock_unlock(&port->lock);
- memcpy(uuid->b, &guidl, sizeof(u64));
- memcpy(uuid->b + 8, &guidh, sizeof(u64));
+ opae_memcpy(uuid->b, &guidl, sizeof(u64));
+ opae_memcpy(uuid->b + 8, &guidh, sizeof(u64));
return 0;
}
diff --git a/drivers/raw/ifpga_rawdev/base/ifpga_fme_pr.c
b/drivers/raw/ifpga_rawdev/base/ifpga_fme_pr.c
index ec0beeb..8890f4b 100644
--- a/drivers/raw/ifpga_rawdev/base/ifpga_fme_pr.c
+++ b/drivers/raw/ifpga_rawdev/base/ifpga_fme_pr.c
@@ -257,7 +257,7 @@ static int fme_pr(struct ifpga_hw *hw, u32 port_id, void
*buffer, u32 size,
return -EINVAL;
}
- memset(&info, 0, sizeof(struct fpga_pr_info));
+ opae_memset(&info, 0, sizeof(struct fpga_pr_info));
info.flags = FPGA_MGR_PARTIAL_RECONFIG;
info.port_id = port_id;
diff --git a/drivers/raw/ifpga_rawdev/base/opae_debug.c
b/drivers/raw/ifpga_rawdev/base/opae_debug.c
index 024d7d2..88f2d5c 100644
--- a/drivers/raw/ifpga_rawdev/base/opae_debug.c
+++ b/drivers/raw/ifpga_rawdev/base/opae_debug.c
@@ -78,13 +78,13 @@ void opae_adapter_dump(struct opae_adapter *adapter, int
verbose)
{
struct opae_accelerator *acc;
- opae_log("=%s=\n", __func__);
- opae_log("OPAE Adapter %s\n", adapter->name);
- opae_log("OPAE Adapter OPs = %p\n", adapter->ops);
- opae_log("OPAE Adapter Private Data = %p\n", adapter->data);
- opae_log("OPAE Manager (downstream) = %p\n", adapter->mgr);
-
if (verbose) {
+ opae_log("=%s=\n", __func__);
+ opae_log("OPAE Adapter %s\n", adapter->name);
+ opae_log("OPAE Adapter OPs = %p\n", adapter->ops);
+ opae_log("OPAE Adapter Private Data = %p\n", adapter->data);
+ opae_log("OPAE Manager (downstream) = %p\n", adapter->mgr);
+
if (adapter->mgr)
opae_manager_dump(adapter->mgr);
@@ -93,7 +93,7 @@ void opae_adapter_dump(struct opae_adapter *adapter, int
verbose)
if (adapter->data)
opae_adapter_data_dump(adapter->data);
- }
- opae_log("==\n");
+ opae_log("==\n");
+ }
}
diff --git a/drivers/raw/ifpga_rawdev/base/opae_hw_api.c
b/drivers/raw/ifpga_rawdev/base/opae_hw_api.c
index 1541b67..41c5903 100644
--- a/drivers/raw/ifpga_rawdev/base/opae_hw_api.c
+++ b/drivers/raw/ifpga_rawdev/base/opae_hw_api.c
@@ -341,7 +341,7 @@ int opae_adapter_enumerate(struct opae_adapter *adapter)
ret = adapter->ops->enumerate(adapter);
if (!ret)
- opae_adapter_dump(adapter, 1);
+ opae_adapter_dump(adapter, 0);
return ret;
}
diff --git a/drivers/raw/ifpga_rawdev/base/opae_osdep.h
b/drivers/raw/ifpga_rawdev/base/opae_osdep.h
index 90f54f7..78fec50 100644
--- a/drivers/raw/ifpga_rawdev/base/opae_osdep.h
+++ b/drivers/raw/ifpga_rawdev/base/opae_osdep.h
@@ -76,4 +76,5 @@ struct uuid {
#define msleep(x) opae_udelay(1000 * (x))
#define usleep_range(min, max) msleep(DIV_ROUND_UP(min, 1000))
+#define opae_memset(a, b, c)memset((a), (b), (c))
#endif
diff --
[dpdk-dev] [PATCH v9 06/14] net/ipn3ke: add IPN3KE Flow of PMD driver
Add Intel FPGA Acceleration NIC IPN3KE Flow of PMD driver.
Signed-off-by: Rosen Xu
Signed-off-by: Andy Pei
Signed-off-by: Dan Wei
---
drivers/net/ipn3ke/Makefile |1 +
drivers/net/ipn3ke/ipn3ke_ethdev.c |5 +
drivers/net/ipn3ke/ipn3ke_ethdev.h |1 +
drivers/net/ipn3ke/ipn3ke_flow.c| 1374 +++
drivers/net/ipn3ke/ipn3ke_flow.h| 106 +++
drivers/net/ipn3ke/ipn3ke_representor.c |3 +-
drivers/net/ipn3ke/ipn3ke_tm.c |1 +
drivers/net/ipn3ke/meson.build |3 +-
8 files changed, 1492 insertions(+), 2 deletions(-)
create mode 100644 drivers/net/ipn3ke/ipn3ke_flow.c
create mode 100644 drivers/net/ipn3ke/ipn3ke_flow.h
diff --git a/drivers/net/ipn3ke/Makefile b/drivers/net/ipn3ke/Makefile
index 38d9384..8c3ae37 100644
--- a/drivers/net/ipn3ke/Makefile
+++ b/drivers/net/ipn3ke/Makefile
@@ -35,5 +35,6 @@ LIBABIVER := 1
SRCS-$(CONFIG_RTE_LIBRTE_IPN3KE_PMD) += ipn3ke_ethdev.c
SRCS-$(CONFIG_RTE_LIBRTE_IPN3KE_PMD) += ipn3ke_representor.c
SRCS-$(CONFIG_RTE_LIBRTE_IPN3KE_PMD) += ipn3ke_tm.c
+SRCS-$(CONFIG_RTE_LIBRTE_IPN3KE_PMD) += ipn3ke_flow.c
include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/drivers/net/ipn3ke/ipn3ke_ethdev.c
b/drivers/net/ipn3ke/ipn3ke_ethdev.c
index 508ea01..9079b57 100644
--- a/drivers/net/ipn3ke/ipn3ke_ethdev.c
+++ b/drivers/net/ipn3ke/ipn3ke_ethdev.c
@@ -21,6 +21,7 @@
#include
#include "ipn3ke_rawdev_api.h"
+#include "ipn3ke_flow.h"
#include "ipn3ke_logs.h"
#include "ipn3ke_ethdev.h"
@@ -266,6 +267,10 @@
if (ret)
return ret;
hw->tm_hw_enable = 1;
+
+ ret = ipn3ke_flow_init(hw);
+ if (ret)
+ return ret;
hw->flow_hw_enable = 1;
}
diff --git a/drivers/net/ipn3ke/ipn3ke_ethdev.h
b/drivers/net/ipn3ke/ipn3ke_ethdev.h
index 36ff2f8..bfda9d5 100644
--- a/drivers/net/ipn3ke/ipn3ke_ethdev.h
+++ b/drivers/net/ipn3ke/ipn3ke_ethdev.h
@@ -291,6 +291,7 @@ struct ipn3ke_hw {
uint32_t acc_tm;
uint32_t acc_flow;
+ struct ipn3ke_flow_list flow_list;
uint32_t flow_max_entries;
uint32_t flow_num_entries;
diff --git a/drivers/net/ipn3ke/ipn3ke_flow.c b/drivers/net/ipn3ke/ipn3ke_flow.c
new file mode 100644
index 000..e5937df
--- /dev/null
+++ b/drivers/net/ipn3ke/ipn3ke_flow.c
@@ -0,0 +1,1374 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2019 Intel Corporation
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "ipn3ke_rawdev_api.h"
+#include "ipn3ke_flow.h"
+#include "ipn3ke_logs.h"
+#include "ipn3ke_ethdev.h"
+
+/** Static initializer for items. */
+#define FLOW_PATTERNS(...) \
+ ((const enum rte_flow_item_type []) { \
+ __VA_ARGS__, RTE_FLOW_ITEM_TYPE_END, \
+ })
+
+enum IPN3KE_HASH_KEY_TYPE {
+ IPN3KE_HASH_KEY_VXLAN,
+ IPN3KE_HASH_KEY_MAC,
+ IPN3KE_HASH_KEY_QINQ,
+ IPN3KE_HASH_KEY_MPLS,
+ IPN3KE_HASH_KEY_IP_TCP,
+ IPN3KE_HASH_KEY_IP_UDP,
+ IPN3KE_HASH_KEY_IP_NVGRE,
+ IPN3KE_HASH_KEY_VXLAN_IP_UDP,
+};
+
+struct ipn3ke_flow_parse {
+ uint32_t mark:1; /**< Set if the flow is marked. */
+ uint32_t drop:1; /**< ACL drop. */
+ uint32_t key_type:IPN3KE_FLOW_KEY_ID_BITS;
+ uint32_t mark_id:IPN3KE_FLOW_RESULT_UID_BITS; /**< Mark identifier. */
+ uint8_t key_len; /**< Length in bit. */
+ uint8_t key[BITS_TO_BYTES(IPN3KE_FLOW_KEY_DATA_BITS)];
+ /**< key1, key2 */
+};
+
+typedef int (*pattern_filter_t)(const struct rte_flow_item patterns[],
+ struct rte_flow_error *error, struct ipn3ke_flow_parse *parser);
+
+
+struct ipn3ke_flow_pattern {
+ const enum rte_flow_item_type *const items;
+
+ pattern_filter_t filter;
+};
+
+/*
+ * @ RTL definition:
+ * typedef struct packed {
+ * logic [47:0]vxlan_inner_mac;
+ * logic [23:0]vxlan_vni;
+ * } Hash_Key_Vxlan_t;
+ *
+ * @ flow items:
+ * RTE_FLOW_ITEM_TYPE_VXLAN
+ * RTE_FLOW_ITEM_TYPE_ETH
+ */
+static int
+ipn3ke_pattern_vxlan(const struct rte_flow_item patterns[],
+ struct rte_flow_error *error, struct ipn3ke_flow_parse *parser)
+{
+ const struct rte_flow_item_vxlan *vxlan = NULL;
+ const struct rte_flow_item_eth *eth = NULL;
+ const struct rte_flow_item *item;
+
+ for (item = patterns; item->type != RTE_FLOW_ITEM_TYPE_END; item++) {
+ if (/*!item->spec || item->mask || */item->last) {
+ rte_flow_error_set(error,
+ EINVAL,
+ RTE_FLOW_ERROR_TYPE_ITEM,
+ item,
+ "Only support item with 'spec'");
+ return -rte_errno;
+ }
+
+ switch (
[dpdk-dev] [PATCH v9 03/14] net/ipn3ke: add IPN3KE ethdev PMD driver
Add Intel FPGA Acceleration NIC IPN3KE ethdev PMD driver. Signed-off-by: Rosen Xu Signed-off-by: Andy Pei Signed-off-by: Dan Wei --- MAINTAINERS | 7 + config/common_base| 4 + doc/guides/nics/features/ipn3ke.ini | 55 ++ doc/guides/nics/index.rst | 1 + doc/guides/nics/ipn3ke.rst| 107 +++ drivers/net/Makefile | 1 + drivers/net/ipn3ke/Makefile | 36 + drivers/net/ipn3ke/ipn3ke_ethdev.c| 645 ++ drivers/net/ipn3ke/ipn3ke_ethdev.h| 942 ++ drivers/net/ipn3ke/ipn3ke_logs.h | 30 + drivers/net/ipn3ke/ipn3ke_rawdev_api.h| 62 ++ drivers/net/ipn3ke/meson.build| 14 + drivers/net/ipn3ke/rte_pmd_ipn3ke_version.map | 4 + drivers/net/meson.build | 1 + mk/rte.app.mk | 1 + usertools/dpdk-devbind.py | 4 +- 16 files changed, 1913 insertions(+), 1 deletion(-) create mode 100644 doc/guides/nics/features/ipn3ke.ini create mode 100644 doc/guides/nics/ipn3ke.rst create mode 100644 drivers/net/ipn3ke/Makefile create mode 100644 drivers/net/ipn3ke/ipn3ke_ethdev.c create mode 100644 drivers/net/ipn3ke/ipn3ke_ethdev.h create mode 100644 drivers/net/ipn3ke/ipn3ke_logs.h create mode 100644 drivers/net/ipn3ke/ipn3ke_rawdev_api.h create mode 100644 drivers/net/ipn3ke/meson.build create mode 100644 drivers/net/ipn3ke/rte_pmd_ipn3ke_version.map diff --git a/MAINTAINERS b/MAINTAINERS index a085834..0d7cd71 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -633,6 +633,13 @@ F: drivers/net/ice/ F: doc/guides/nics/ice.rst F: doc/guides/nics/features/ice.ini +Intel ipn3ke +M: Rosen Xu +T: git://dpdk.org/next/dpdk-next-net-intel +F: drivers/net/ipn3ke/ +F: doc/guides/nics/ipn3ke.rst +F: doc/guides/nics/features/ipn3ke.ini + Marvell mvpp2 M: Tomasz Duszynski M: Liron Himi diff --git a/config/common_base b/config/common_base index 7fb0ded..4236c2a 100644 --- a/config/common_base +++ b/config/common_base @@ -328,6 +328,10 @@ CONFIG_RTE_LIBRTE_IAVF_DEBUG_TX=n CONFIG_RTE_LIBRTE_IAVF_DEBUG_TX_FREE=n CONFIG_RTE_LIBRTE_IAVF_DEBUG_RX=n CONFIG_RTE_LIBRTE_IAVF_16BYTE_RX_DESC=n +# +# Compile burst-oriented IPN3KE PMD driver +# +CONFIG_RTE_LIBRTE_IPN3KE_PMD=y # # Compile burst-oriented Mellanox ConnectX-3 (MLX4) PMD diff --git a/doc/guides/nics/features/ipn3ke.ini b/doc/guides/nics/features/ipn3ke.ini new file mode 100644 index 000..a194e35 --- /dev/null +++ b/doc/guides/nics/features/ipn3ke.ini @@ -0,0 +1,55 @@ +; +; Supported features of the 'ipn3ke' network poll mode driver. +; +; Refer to default.ini for the full list of available PMD features. +; +[Features] +Speed capabilities = Y +Link status = Y +Link status event= Y +Rx interrupt = Y +Queue start/stop = Y +Runtime Rx queue setup = Y +Runtime Tx queue setup = Y +Jumbo frame = Y +Scattered Rx = Y +TSO = Y +Promiscuous mode = Y +Allmulticast mode= Y +Unicast MAC filter = Y +Multicast MAC filter = Y +RSS hash = Y +RSS key update = Y +RSS reta update = Y +VMDq = Y +SR-IOV = Y +DCB = Y +VLAN filter = Y +Ethertype filter = Y +Tunnel filter= Y +Hash filter = Y +Flow director= Y +Flow control = Y +Flow API = Y +Traffic mirroring= Y +CRC offload = Y +VLAN offload = Y +QinQ offload = Y +L3 checksum offload = Y +L4 checksum offload = Y +Inner L3 checksum= Y +Inner L4 checksum= Y +Packet type parsing = Y +Timesync = Y +Rx descriptor status = Y +Tx descriptor status = Y +Basic stats = Y +Extended stats = Y +FW version = Y +Module EEPROM dump = Y +Multiprocess aware = Y +BSD nic_uio = Y +Linux UIO= Y +Linux VFIO = Y +x86-32 = Y +x86-64 = Y diff --git a/doc/guides/nics/index.rst b/doc/guides/nics/index.rst index 8a4e145..2221c35 100644 --- a/doc/guides/nics/index.rst +++ b/doc/guides/nics/index.rst @@ -31,6 +31,7 @@ Network Interface Controller Drivers ice ifc igb +ipn3ke ixgbe intel_vf kni diff --git a/doc/guides/nics/ipn3ke.rst b/doc/guides/nics/ipn3ke.rst new file mode 100644 index 000..c6c1552 --- /dev/null +++ b/doc/guides/nics/ipn3ke.rst @@ -0,0 +1,107 @@ +.. SPDX-License-Identifier: BSD-3-Clause +Copyright(c) 2019 Intel Corporation. + +IPN3KE Poll Mode Driver +=== + +The ipn3ke PMD (librte_pmd_ipn3ke) provides poll mode driver support +for Intel?? FPGA PAC(Programmable Acceleration Card) N3000 based on +the Intel Ethernet Controller X710/XXV710 and Intel Arria 10 FPGA. + +In this card, FPGA is an acceleration bridge between ne
[dpdk-dev] [PATCH v9 08/14] raw/ifpga_rawdev: store private features in FME and Port
From: Tianfei zhang
Get private features attrubite like size, id, address after
enumeration, and insert into FEM or Port dedicate list.
when initial the private feature driver, we just compare the
private feature id between the list and feature drivers array
to match the proper drivers.
This patch avoid the hardcore in feature_info array in previous
implementation. and the same time we can use one driver for mulitple
devices which the id is the same.
Signed-off-by: Tianfei Zhang
---
drivers/raw/ifpga_rawdev/base/ifpga_defines.h | 46 ++-
drivers/raw/ifpga_rawdev/base/ifpga_enumerate.c | 347 --
drivers/raw/ifpga_rawdev/base/ifpga_feature_dev.c | 160 +++---
drivers/raw/ifpga_rawdev/base/ifpga_feature_dev.h | 46 ++-
drivers/raw/ifpga_rawdev/base/ifpga_fme.c | 32 ++
drivers/raw/ifpga_rawdev/base/ifpga_hw.h | 16 +-
drivers/raw/ifpga_rawdev/base/ifpga_port.c| 21 ++
7 files changed, 363 insertions(+), 305 deletions(-)
diff --git a/drivers/raw/ifpga_rawdev/base/ifpga_defines.h
b/drivers/raw/ifpga_rawdev/base/ifpga_defines.h
index aa02527..217d0b1 100644
--- a/drivers/raw/ifpga_rawdev/base/ifpga_defines.h
+++ b/drivers/raw/ifpga_rawdev/base/ifpga_defines.h
@@ -15,6 +15,7 @@
#define FME_FEATURE_GLOBAL_IPERF"fme_iperf"
#define FME_FEATURE_GLOBAL_ERR "fme_error"
#define FME_FEATURE_PR_MGMT "fme_pr"
+#define FME_FEATURE_EMIF_MGMT "fme_emif"
#define FME_FEATURE_HSSI_ETH"fme_hssi"
#define FME_FEATURE_GLOBAL_DPERF"fme_dperf"
#define FME_FEATURE_QSPI_FLASH "fme_qspi_flash"
@@ -59,7 +60,8 @@
#define FEATURE_FIU_ID_FME 0x0
#define FEATURE_FIU_ID_PORT0x1
-#define FEATURE_ID_HEADER 0x0
+/* Reserved 0xfe for Header, 0xff for AFU*/
+#define FEATURE_ID_FIU_HEADER 0xfe
#define FEATURE_ID_AFU 0xff
enum fpga_id_type {
@@ -68,31 +70,23 @@ enum fpga_id_type {
FPGA_ID_MAX,
};
-enum fme_feature_id {
- FME_FEATURE_ID_HEADER = 0x0,
-
- FME_FEATURE_ID_THERMAL_MGMT = 0x1,
- FME_FEATURE_ID_POWER_MGMT = 0x2,
- FME_FEATURE_ID_GLOBAL_IPERF = 0x3,
- FME_FEATURE_ID_GLOBAL_ERR = 0x4,
- FME_FEATURE_ID_PR_MGMT = 0x5,
- FME_FEATURE_ID_HSSI_ETH = 0x6,
- FME_FEATURE_ID_GLOBAL_DPERF = 0x7,
- FME_FEATURE_ID_QSPI_FLASH = 0x8,
-
- /* one for fme header. */
- FME_FEATURE_ID_MAX = 0x9,
-};
-
-enum port_feature_id {
- PORT_FEATURE_ID_HEADER = 0x0,
- PORT_FEATURE_ID_ERROR = 0x1,
- PORT_FEATURE_ID_UMSG = 0x2,
- PORT_FEATURE_ID_UINT = 0x3,
- PORT_FEATURE_ID_STP = 0x4,
- PORT_FEATURE_ID_UAFU = 0x5,
- PORT_FEATURE_ID_MAX = 0x6,
-};
+#define FME_FEATURE_ID_HEADER FEATURE_ID_FIU_HEADER
+#define FME_FEATURE_ID_THERMAL_MGMT 0x1
+#define FME_FEATURE_ID_POWER_MGMT 0x2
+#define FME_FEATURE_ID_GLOBAL_IPERF 0x3
+#define FME_FEATURE_ID_GLOBAL_ERR 0x4
+#define FME_FEATURE_ID_PR_MGMT 0x5
+#define FME_FEATURE_ID_HSSI_ETH 0x6
+#define FME_FEATURE_ID_GLOBAL_DPERF 0x7
+#define FME_FEATURE_ID_QSPI_FLASH 0x8
+#define FME_FEATURE_ID_EMIF_MGMT 0x9
+
+#define PORT_FEATURE_ID_HEADER FEATURE_ID_FIU_HEADER
+#define PORT_FEATURE_ID_ERROR 0x10
+#define PORT_FEATURE_ID_UMSG 0x12
+#define PORT_FEATURE_ID_UINT 0x13
+#define PORT_FEATURE_ID_STP 0x14
+#define PORT_FEATURE_ID_UAFU FEATURE_ID_AFU
/*
* All headers and structures must be byte-packed to match the spec.
diff --git a/drivers/raw/ifpga_rawdev/base/ifpga_enumerate.c
b/drivers/raw/ifpga_rawdev/base/ifpga_enumerate.c
index 848e518..c779e0c 100644
--- a/drivers/raw/ifpga_rawdev/base/ifpga_enumerate.c
+++ b/drivers/raw/ifpga_rawdev/base/ifpga_enumerate.c
@@ -28,121 +28,24 @@ struct build_feature_devs_info {
struct ifpga_hw *hw;
};
-struct feature_info {
- const char *name;
- u32 resource_size;
- int feature_index;
- int revision_id;
- unsigned int vec_start;
- unsigned int vec_cnt;
-
- struct feature_ops *ops;
-};
+static int feature_revision(void __iomem *start)
+{
+ struct feature_header header;
-/* indexed by fme feature IDs which are defined in 'enum fme_feature_id'. */
-static struct feature_info fme_features[] = {
- {
- .name = FME_FEATURE_HEADER,
- .resource_size = sizeof(struct feature_fme_header),
- .feature_index = FME_FEATURE_ID_HEADER,
- .revision_id = FME_HEADER_REVISION,
- .ops = &fme_hdr_ops,
- },
- {
- .name = FME_FEATURE_THERMAL_MGMT,
- .resource_size = sizeof(struct feature_fme_thermal),
- .feature_index = FME_FEATURE_ID_THERMAL_MGMT,
- .revision_id = FME_THERMAL_MGMT_REVISION,
- .ops = &fme_thermal_mgmt_ops,
- },
- {
- .name = FME_FEATURE_POWER_MGMT,
- .resource_size = sizeof(struct feature_fme_power),
- .feature_index = FME_FEATURE_ID_POWER_MGMT,
- .revision_id = F
[dpdk-dev] [PATCH v9 11/14] raw/ifpga_rawdev: add eth group driver
From: Tianfei zhang
There is two eth group devices in PAC N3000 card,
each eth group include PHY device and MAC device. Exposing
APIs for DPDK PMD driver to access those devices.
Signed-off-by: Tianfei Zhang
---
drivers/raw/ifpga_rawdev/base/Makefile| 1 +
drivers/raw/ifpga_rawdev/base/ifpga_api.c | 74 ++-
drivers/raw/ifpga_rawdev/base/ifpga_defines.h | 39
drivers/raw/ifpga_rawdev/base/ifpga_enumerate.c | 6 +
drivers/raw/ifpga_rawdev/base/ifpga_feature_dev.c | 2 +
drivers/raw/ifpga_rawdev/base/ifpga_feature_dev.h | 12 ++
drivers/raw/ifpga_rawdev/base/ifpga_fme.c | 250 ++
drivers/raw/ifpga_rawdev/base/ifpga_hw.h | 7 +
drivers/raw/ifpga_rawdev/base/meson.build | 1 +
drivers/raw/ifpga_rawdev/base/opae_eth_group.c| 145 +
drivers/raw/ifpga_rawdev/base/opae_eth_group.h| 96 +
drivers/raw/ifpga_rawdev/base/opae_hw_api.c | 149 +
drivers/raw/ifpga_rawdev/base/opae_hw_api.h | 27 +++
drivers/raw/ifpga_rawdev/base/opae_intel_max10.h | 42 +++-
drivers/raw/ifpga_rawdev/base/opae_osdep.h| 16 +-
15 files changed, 858 insertions(+), 9 deletions(-)
create mode 100644 drivers/raw/ifpga_rawdev/base/opae_eth_group.c
create mode 100644 drivers/raw/ifpga_rawdev/base/opae_eth_group.h
diff --git a/drivers/raw/ifpga_rawdev/base/Makefile
b/drivers/raw/ifpga_rawdev/base/Makefile
index edb538f..c5bbcbd 100644
--- a/drivers/raw/ifpga_rawdev/base/Makefile
+++ b/drivers/raw/ifpga_rawdev/base/Makefile
@@ -27,5 +27,6 @@ SRCS-y += opae_spi_transaction.c
SRCS-y += opae_intel_max10.c
SRCS-y += opae_i2c.c
SRCS-y += opae_at24_eeprom.c
+SRCS-y += opae_eth_group.c
SRCS-y += $(wildcard $(SRCDIR)/base/$(OSDEP)/*.c)
diff --git a/drivers/raw/ifpga_rawdev/base/ifpga_api.c
b/drivers/raw/ifpga_rawdev/base/ifpga_api.c
index c447b3c..3ddbcdc 100644
--- a/drivers/raw/ifpga_rawdev/base/ifpga_api.c
+++ b/drivers/raw/ifpga_rawdev/base/ifpga_api.c
@@ -170,7 +170,6 @@ struct opae_accelerator_ops ifpga_acc_ops = {
};
/* Bridge APIs */
-
static int ifpga_br_reset(struct opae_bridge *br)
{
struct ifpga_port_hw *port = br->data;
@@ -192,8 +191,26 @@ static int ifpga_mgr_flash(struct opae_manager *mgr, int
id, void *buf,
return ifpga_pr(hw, id, buf, size, status);
}
+static int ifpga_mgr_get_eth_group_region_info(struct opae_manager *mgr,
+ struct opae_eth_group_region_info *info)
+{
+ struct ifpga_fme_hw *fme = mgr->data;
+
+ if (info->group_id >= MAX_ETH_GROUP_DEVICES)
+ return -EINVAL;
+
+ info->phys_addr = fme->eth_group_region[info->group_id].phys_addr;
+ info->addr = fme->eth_group_region[info->group_id].addr;
+ info->len = fme->eth_group_region[info->group_id].len;
+
+ info->mem_idx = fme->nums_acc_region + info->group_id;
+
+ return 0;
+}
+
struct opae_manager_ops ifpga_mgr_ops = {
.flash = ifpga_mgr_flash,
+ .get_eth_group_region_info = ifpga_mgr_get_eth_group_region_info,
};
static int ifpga_mgr_read_mac_rom(struct opae_manager *mgr, int offset,
@@ -212,10 +229,65 @@ static int ifpga_mgr_write_mac_rom(struct opae_manager
*mgr, int offset,
return fme_mgr_write_mac_rom(fme, offset, buf, size);
}
+static int ifpga_mgr_get_eth_group_nums(struct opae_manager *mgr)
+{
+ struct ifpga_fme_hw *fme = mgr->data;
+
+ return fme_mgr_get_eth_group_nums(fme);
+}
+
+static int ifpga_mgr_get_eth_group_info(struct opae_manager *mgr,
+ u8 group_id, struct opae_eth_group_info *info)
+{
+ struct ifpga_fme_hw *fme = mgr->data;
+
+ return fme_mgr_get_eth_group_info(fme, group_id, info);
+}
+
+static int ifpga_mgr_eth_group_reg_read(struct opae_manager *mgr, u8 group_id,
+ u8 type, u8 index, u16 addr, u32 *data)
+{
+ struct ifpga_fme_hw *fme = mgr->data;
+
+ return fme_mgr_eth_group_read_reg(fme, group_id,
+ type, index, addr, data);
+}
+
+static int ifpga_mgr_eth_group_reg_write(struct opae_manager *mgr, u8 group_id,
+ u8 type, u8 index, u16 addr, u32 data)
+{
+ struct ifpga_fme_hw *fme = mgr->data;
+
+ return fme_mgr_eth_group_write_reg(fme, group_id,
+ type, index, addr, data);
+}
+
+static int ifpga_mgr_get_retimer_info(struct opae_manager *mgr,
+ struct opae_retimer_info *info)
+{
+ struct ifpga_fme_hw *fme = mgr->data;
+
+ return fme_mgr_get_retimer_info(fme, info);
+}
+
+static int ifpga_mgr_get_retimer_status(struct opae_manager *mgr,
+ struct opae_retimer_status *status)
+{
+ struct ifpga_fme_hw *fme = mgr->data;
+
+ return fme_mgr_get_retimer_status(fme, status);
+}
+
/* Network APIs in FME */
struct opae_manager_networking_ops ifpga_mgr_network_ops = {
.read_mac_rom = ifpga_mgr_read_mac_rom,
.write_mac_rom = ifpga_mgr_write_mac_rom,
+ .get_eth_group_nums
