Re: [dpdk-dev] [PATCH v4 4/4] vhost: destroy unused virtqueues when multiqueue not negotiated
On 12/13/2017 04:16 AM, Tiwei Bie wrote:
On Mon, Dec 11, 2017 at 04:15:03PM +0100, Maxime Coquelin wrote:
QEMU sends VHOST_USER_SET_VRING_CALL requests for all queues
declared in QEMU command line before the guest is started.
It has the effect in DPDK vhost-user backend to allocate vrings
for all queues declared by QEMU.
If the first driver being used does not support multiqueue,
the device never changes to VIRTIO_DEV_RUNNING state as only
the first queue pair is initialized. One driver impacted by
this bug is virtio-net's iPXE driver which does not support
VIRTIO_NET_F_MQ feature.
It is safe to destroy unused virtqueues in SET_FEATURES request
handler, as it is ensured the device is not in running state
at this stage, so virtqueues aren't being processed.
Signed-off-by: Maxime Coquelin
---
lib/librte_vhost/vhost_user.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c
index 471b1612c..d5ca1ac90 100644
--- a/lib/librte_vhost/vhost_user.c
+++ b/lib/librte_vhost/vhost_user.c
@@ -216,6 +216,24 @@ vhost_user_set_features(struct virtio_net *dev, uint64_t
features)
(dev->features & (1 << VIRTIO_NET_F_MRG_RXBUF)) ? "on" : "off",
(dev->features & (1ULL << VIRTIO_F_VERSION_1)) ? "on" : "off");
+ if (!(dev->features & (1ULL << VIRTIO_NET_F_MQ))) {
+ /*
+* Remove all but first queue pair if MQ hasn't been
+* negotiated. This is safe because the device is not
+* running at this stage.
+*/
+ while (dev->nr_vring > 2) {
+ struct vhost_virtqueue *vq;
+
+ vq = dev->virtqueue[--dev->nr_vring];
+ if (!vq)
+ continue;
+
+ cleanup_vq(vq, 1);
+ free_vq(vq);
Hi,
Sorry, I didn't look into this patch in last version.
Don't be sorry, thanks for catching this bug.
The freed dev->virtqueue[$idx] also needs to be zeroed.
Otherwise, it won't be allocated in the future due to the
below check in vhost_user_check_and_alloc_queue_pair(),
and the freed memory will be used again.
/*
* Allocate a queue pair if it hasn't been allocated yet
*/
static int
vhost_user_check_and_alloc_queue_pair(struct virtio_net *dev, VhostUserMsg *msg)
{
if (dev->virtqueue[vring_idx])
return 0;
return alloc_vring_queue(dev, vring_idx);
}
You are right, I'll post v5 setting dev->virtqueue[$idx] to NULL after
free_vq() call.
Thanks for the review,
Maxime
Best regards,
Tiwei Bie
+ }
+ }
+
return 0;
}
--
2.14.3
Re: [dpdk-dev] [PATCH v3 3/4] net/bond: dedicated hw queues for LACP control traffic
Hi, What is the purpose of this patch? fix problem or improve performance? 在 2017/7/5 0:46, Declan Doherty 写道: > From: Tomasz Kulasek > > Add support for hardware flow classification of LACP control plane > traffic to be redirect to a dedicated receive queue on each slave which > is not visible to application. Also enables a dedicate transmit queue > for LACP traffic which allows complete decoupling of control and data > paths.
[dpdk-dev] [PATCH v5 0/4] Vhost: fix mq=on but VIRTIO_NET_F_MQ not negotiated
Hi, This fifth revision fixes bug reported by Tiwei, dev->virtqueue[$idx] wasn't reset to NULL at vq freeing time. Having QEMU started with mq=on but guest driver not negotiating VIRTIO_NET_F_MQ feature ends up in the vhost device to never start. Indeed, more queues are created in the vhost backend than configured. Guest drivers known to not advertise the VIRTIO_NET_F_MQ feature are iPXE and OVMF Virtio-net drivers. Queues are created because before starting the guest, QEMU sends VHOST_USER_SET_VRING_CALL requests for all queues declared in QEMU command line. Also, once Virtio features negotiated, QEMU sends VHOST_USER_SET_VRING_ENABLE requests to disable all but the first queue pair. This series fixes this by destroying all but first queue pair in the backend if VIRTIO_NET_F_MQ isn't negotiated. First patches makes sure that VHOST_USER_SET_FEATURES request doesn't change Virtio features while the device is running, which should never happen as per the Virtio spec. This helps to make sure vitqueues aren't destroyed while being processed, but also protect from other illegal features changes (e.g. VIRTIO_NET_F_MRG_RXBUF). Changes since v4: = - Fix dev->virtqueue[$ixd] not reset to NULL at VQ free time (Tiwei) Changes since v3: = - Fix Virtio features = 0 case (Tiwei) Changes since v2: = - Patch 2: Rework & fix VQs destruction loop (Laszlo) Changes since v1: = - Patch 1: shift bits in the right direction (Ladi) Maxime Coquelin (4): vhost: prevent features to be changed while device is running vhost: propagate VHOST_USER_SET_FEATURES handling error vhost: extract virtqueue cleaning and freeing functions vhost: destroy unused virtqueues when multiqueue not negotiated lib/librte_vhost/vhost.c | 22 -- lib/librte_vhost/vhost.h | 3 +++ lib/librte_vhost/vhost_user.c | 40 ++-- 3 files changed, 53 insertions(+), 12 deletions(-) -- 2.14.3
[dpdk-dev] [PATCH v5 1/4] vhost: prevent features to be changed while device is running
As section 2.2 of the Virtio spec states about features
negotiation:
"During device initialization, the driver reads this and tells
the device the subset that it accepts. The only way to
renegotiate is to reset the device."
This patch implements a check to prevent illegal features change
while the device is running.
One exception is the VHOST_F_LOG_ALL feature bit, which is enabled
when live-migration is initiated. But this feature is not negotiated
with the Virtio driver, but directly with the Vhost master.
Signed-off-by: Maxime Coquelin
---
lib/librte_vhost/vhost_user.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c
index f4c7ce462..545dbcb2b 100644
--- a/lib/librte_vhost/vhost_user.c
+++ b/lib/librte_vhost/vhost_user.c
@@ -183,7 +183,22 @@ vhost_user_set_features(struct virtio_net *dev, uint64_t
features)
return -1;
}
- if ((dev->flags & VIRTIO_DEV_RUNNING) && dev->features != features) {
+ if (dev->flags & VIRTIO_DEV_RUNNING) {
+ if (dev->features == features)
+ return 0;
+
+ /*
+* Error out if master tries to change features while device is
+* in running state. The exception being VHOST_F_LOG_ALL, which
+* is enabled when the live-migration starts.
+*/
+ if ((dev->features ^ features) & ~(1ULL << VHOST_F_LOG_ALL)) {
+ RTE_LOG(ERR, VHOST_CONFIG,
+ "(%d) features changed while device is
running.\n",
+ dev->vid);
+ return -1;
+ }
+
if (dev->notify_ops->features_changed)
dev->notify_ops->features_changed(dev->vid, features);
}
--
2.14.3
[dpdk-dev] [PATCH v5 2/4] vhost: propagate VHOST_USER_SET_FEATURES handling error
Not propagating VHOST_USER_SET_FEATURES request handling error may result in unpredictable behavior, as host and guests features may no more be synchronized. This patch fixes this by reporting the error to the upper layer, which would result in the device being destroyed and the connection with the master to be closed. Signed-off-by: Maxime Coquelin --- lib/librte_vhost/vhost_user.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c index 545dbcb2b..471b1612c 100644 --- a/lib/librte_vhost/vhost_user.c +++ b/lib/librte_vhost/vhost_user.c @@ -1263,7 +1263,9 @@ vhost_user_msg_handler(int vid, int fd) send_vhost_reply(fd, &msg); break; case VHOST_USER_SET_FEATURES: - vhost_user_set_features(dev, msg.payload.u64); + ret = vhost_user_set_features(dev, msg.payload.u64); + if (ret) + return -1; break; case VHOST_USER_GET_PROTOCOL_FEATURES: -- 2.14.3
[dpdk-dev] [PATCH v5 4/4] vhost: destroy unused virtqueues when multiqueue not negotiated
QEMU sends VHOST_USER_SET_VRING_CALL requests for all queues
declared in QEMU command line before the guest is started.
It has the effect in DPDK vhost-user backend to allocate vrings
for all queues declared by QEMU.
If the first driver being used does not support multiqueue,
the device never changes to VIRTIO_DEV_RUNNING state as only
the first queue pair is initialized. One driver impacted by
this bug is virtio-net's iPXE driver which does not support
VIRTIO_NET_F_MQ feature.
It is safe to destroy unused virtqueues in SET_FEATURES request
handler, as it is ensured the device is not in running state
at this stage, so virtqueues aren't being processed.
Signed-off-by: Maxime Coquelin
---
lib/librte_vhost/vhost_user.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c
index 471b1612c..1848c8de9 100644
--- a/lib/librte_vhost/vhost_user.c
+++ b/lib/librte_vhost/vhost_user.c
@@ -216,6 +216,25 @@ vhost_user_set_features(struct virtio_net *dev, uint64_t
features)
(dev->features & (1 << VIRTIO_NET_F_MRG_RXBUF)) ? "on" : "off",
(dev->features & (1ULL << VIRTIO_F_VERSION_1)) ? "on" : "off");
+ if (!(dev->features & (1ULL << VIRTIO_NET_F_MQ))) {
+ /*
+* Remove all but first queue pair if MQ hasn't been
+* negotiated. This is safe because the device is not
+* running at this stage.
+*/
+ while (dev->nr_vring > 2) {
+ struct vhost_virtqueue *vq;
+
+ vq = dev->virtqueue[--dev->nr_vring];
+ if (!vq)
+ continue;
+
+ dev->virtqueue[dev->nr_vring] = NULL;
+ cleanup_vq(vq, 1);
+ free_vq(vq);
+ }
+ }
+
return 0;
}
--
2.14.3
[dpdk-dev] [PATCH v5 3/4] vhost: extract virtqueue cleaning and freeing functions
This patch extracts needed code for vhost_user.c to be able
to clean and free virtqueues unitary.
Signed-off-by: Maxime Coquelin
---
lib/librte_vhost/vhost.c | 22 --
lib/librte_vhost/vhost.h | 3 +++
2 files changed, 15 insertions(+), 10 deletions(-)
diff --git a/lib/librte_vhost/vhost.c b/lib/librte_vhost/vhost.c
index 4f8b73a09..df528a4ea 100644
--- a/lib/librte_vhost/vhost.c
+++ b/lib/librte_vhost/vhost.c
@@ -103,7 +103,7 @@ get_device(int vid)
return dev;
}
-static void
+void
cleanup_vq(struct vhost_virtqueue *vq, int destroy)
{
if ((vq->callfd >= 0) && (destroy != 0))
@@ -127,6 +127,15 @@ cleanup_device(struct virtio_net *dev, int destroy)
cleanup_vq(dev->virtqueue[i], destroy);
}
+void
+free_vq(struct vhost_virtqueue *vq)
+{
+ rte_free(vq->shadow_used_ring);
+ rte_free(vq->batch_copy_elems);
+ rte_mempool_free(vq->iotlb_pool);
+ rte_free(vq);
+}
+
/*
* Release virtqueues and device memory.
*/
@@ -134,16 +143,9 @@ static void
free_device(struct virtio_net *dev)
{
uint32_t i;
- struct vhost_virtqueue *vq;
-
- for (i = 0; i < dev->nr_vring; i++) {
- vq = dev->virtqueue[i];
- rte_free(vq->shadow_used_ring);
- rte_free(vq->batch_copy_elems);
- rte_mempool_free(vq->iotlb_pool);
- rte_free(vq);
- }
+ for (i = 0; i < dev->nr_vring; i++)
+ free_vq(dev->virtqueue[i]);
rte_free(dev);
}
diff --git a/lib/librte_vhost/vhost.h b/lib/librte_vhost/vhost.h
index 1cc81c17c..9cad1bb3c 100644
--- a/lib/librte_vhost/vhost.h
+++ b/lib/librte_vhost/vhost.h
@@ -364,6 +364,9 @@ void cleanup_device(struct virtio_net *dev, int destroy);
void reset_device(struct virtio_net *dev);
void vhost_destroy_device(int);
+void cleanup_vq(struct vhost_virtqueue *vq, int destroy);
+void free_vq(struct vhost_virtqueue *vq);
+
int alloc_vring_queue(struct virtio_net *dev, uint32_t vring_idx);
void vhost_set_ifname(int, const char *if_name, unsigned int if_len);
--
2.14.3
Re: [dpdk-dev] [dpdk-techboard] [PATCH] doc: update contribution guideline for dependent work
On Tue, Dec 12, 2017 at 10:57:48AM -0800, Ferruh Yigit wrote: > On 12/12/2017 7:54 AM, Olivier MATZ wrote: > > Hi, > > > > On Mon, Dec 11, 2017 at 02:26:34PM +, Mcnamara, John wrote: > >> From: Yigit, Ferruh > >>> Changing some part of the libraries but not updating all dependent code > >>> cause maintenance problems. > >>> > >>> ... > >>> > >>> Signed-off-by: Ferruh Yigit > >>> > >> > >> > >> integration testing. > >>> > >>> +* If changes effect other parts of the project, update all those parts as > >>> well unless updating requires special knowledge. > > > > I feel that "requiring special knowledge" is a bit blury. > > Yes it is, but hard to define where to put the line. My point is if author has > enough knowledge to go and update dependent part, please do so. > > > Shouldn't we add some > > examples? Typically, I'm thinking about changes in ethdev that imply > > updating > > the PMDs. Any opinion for this use case? > > Overall many libraries to PMDs fit into this. eal/mbuf/ethdev -> PMD changes. > > I think, the dynamic logging update in the other libraries and PMDs should be > done with the original patch, adding dynamic logging to any library doesn't > require library specific information, but agree this is more work. Being the author of this patchset, I can give my feeling in this particular case. That's right adding dynamic logging to all libraries may not require to know the specifics or the library. I did these changes to help me while debugging the i40e driver. Once done, it was worth doing clean EAL upstreamable patches to lay the foundations for a generic dynamic logging system in DPDK. If I had to do the work for all the libraries, I would not have done it, because it was really out of scope of my task. So the choice was between having nothing, or having something which is not much used at first, but can be more widely adopted over time. That said, I understand that the problem with the second approach is to stay for too long in a situation where the old system is used. > For new ethdev offload method, I believe it fits into more gray area, it may > be > possible to update PMDs to use new offloading method but some part PMDs can be > challenging. > > Converting flow director filtering to the rte_flow filtering is something I > believe fair to expect from PMD owner instead of rte_flow author. Yes, agree for these 2 examples.
[dpdk-dev] [PATCH] vhost: fix dequeue zero copy not work with virtio1
This fix dequeue zero copy can not work with Qemu
version >= 2.7. Since from Qemu 2.7 virtio device
use virtio-1 protocol, the zero copy code path
forget to add offset to buffer address.
Signed-off-by: Junjie Chen
---
lib/librte_vhost/virtio_net.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/librte_vhost/virtio_net.c b/lib/librte_vhost/virtio_net.c
index 6fee16e..79d80f7 100644
--- a/lib/librte_vhost/virtio_net.c
+++ b/lib/librte_vhost/virtio_net.c
@@ -977,7 +977,8 @@ copy_desc_to_mbuf(struct virtio_net *dev, struct
vhost_virtqueue *vq,
desc->addr + desc_offset, cpy_len {
cur->data_len = cpy_len;
cur->data_off = 0;
- cur->buf_addr = (void *)(uintptr_t)desc_addr;
+ cur->buf_addr = (void *)(uintptr_t)(desc_addr
+ + desc_offset);
cur->buf_iova = hpa;
/*
--
2.0.1
Re: [dpdk-dev] [PATCH v5 0/4] Vhost: fix mq=on but VIRTIO_NET_F_MQ not negotiated
On 13/12/2017 09:51, Maxime Coquelin wrote: > This series fixes this by destroying all but first queue pair in > the backend if VIRTIO_NET_F_MQ isn't negotiated. First patches > makes sure that VHOST_USER_SET_FEATURES request doesn't change > Virtio features while the device is running, which should never > happen as per the Virtio spec. This helps to make sure vitqueues > aren't destroyed while being processed, but also protect from > other illegal features changes (e.g. VIRTIO_NET_F_MRG_RXBUF). Hi Maxime, I think this series is wrong from the virtio spec's point of view. If the driver requests VIRTIO_NET_F_MQ, that does not mean "the driver knows about multiqueue", it only means that "the driver wants to read max_virtqueue_pairs" from configuration space. Just like it's perfectly fine for a device to propose VIRTIO_NET_F_MQ and set max_virtqueue_pairs=1, a driver can negotiate VIRTIO_NET_F_MQ and then skip initialization of some virtqueues. In fact, for virtio-net there is an explicit way to say how many virtqueue pairs are available; the virtio spec's section 5.1.5 (Network device, Device Initialization) mentions that Even with VIRTIO_NET_F_MQ, only receiveq1, transmitq1 and controlq are used by default. The driver would send the VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET command specifying the number of the transmit and receive queues to use. Thanks, Paolo
Re: [dpdk-dev] Minutes of technical board meeting 2017-12-06
On Tue, Dec 12, 2017 at 12:30:11PM -0600, Jay Rolette wrote: > On Tue, Dec 12, 2017 at 11:26 AM, Richardson, Bruce < > bruce.richard...@intel.com> wrote: > > > > Topic: Management of old patches in patchwork * Unanimous agreement > > that old patches should be rejected in patchwork after a reasonable > > period, set initially at 3 releases (9 months). * After a release, > > all patches dated older than 3 releases previously, e.g. after > > 17.11, any patches submitted before the release of 17.02, will be > > marked as rejected and a mail reply sent to the appropriate mailing > > list thread informing people of the same. * To have patches > > reconsidered for future inclusion, a new version of the patches > > should be submitted to the mailing list. > > > > Does this mean there is a commitment to act on submitted patches in a > timely manner? Maybe this is better now, but at least in the past, > even small patches to fix bugs would sit around with no action on them > for 6+ months. > > It's been a while since I submitted any patches, so if this isn't an > issue now, then nevermind :-) > Being honest, I don't think we could ever say it's not a problem, and I also don't believe we could ever make a committment to always respond to patches in a timely manner. Each maintainer is responsible for reviewing and "managing" patches in their area of responsibility and some maintainers will be faster to respond than others. We have, however, a documented procedure for having patches merged once acked by the maintainer, so that should have improved things. Up to getting maintainer ack, it is still up to the submitter to ping the maintainer to review if no response is forthcoming on the patch submission. /Bruce
Re: [dpdk-dev] [PATCH] net/ixgbe: removed ipsec keys from private data
On 22/11/17 11:19, Radu Nicolau wrote: Signed-off-by: Radu Nicolau --- ... Acked-by: Declan Doherty
Re: [dpdk-dev] [RFC 2/2] net/tap: add eBPF instructions
Any eBPF program must be GPL compatible to use GPL-ed functions.
Please see kernel code snippet
http://elixir.free-electrons.com/linux/latest/source/kernel/bpf/syscall.c
/* eBPF programs must be GPL compatible to use GPL-ed functions */
is_gpl = license_is_gpl_compatible(license);
where you can find in
http://elixir.free-electrons.com/linux/latest/source/include/linux/license.h#L4
the implementation of licensing checking:
static inline int license_is_gpl_compatible(const char *license)
{
return (strcmp(license, "GPL") == 0
|| strcmp(license, "GPL v2") == 0
|| strcmp(license, "GPL and additional rights") == 0
|| strcmp(license, "Dual BSD/GPL") == 0
|| strcmp(license, "Dual MIT/GPL") == 0
|| strcmp(license, "Dual MPL/GPL") == 0);
}
Calling BPF system call to download an eBPF program will require using any one
of the GPL strings listed above.
Is "Dual BSD/GPL" acceptable?
Please advise.
> -Original Message-
> From: Pascal Mazon [mailto:pascal.ma...@6wind.com]
> Sent: Tuesday, December 05, 2017 9:59 AM
> To: Thomas Monjalon ; Stephen Hemminger
>
> Cc: dev@dpdk.org; Ophir Munk ; Olga Shern
>
> Subject: Re: [dpdk-dev] [RFC 2/2] net/tap: add eBPF instructions
>
> Indeed, the spirit of the initial work was to publish source code, compiled
> BPF bytecode, and Makefile for re-generating the latter.
> I have no clue regarding licensing, I'll trust you guys on that.
>
> On 30/11/2017 18:39, Thomas Monjalon wrote:
> > 30/11/2017 18:20, Stephen Hemminger:
> >> On Thu, 30 Nov 2017 18:05:22 +0100
> >> Thomas Monjalon wrote:
> >>
> >>> 30/11/2017 17:54, Stephen Hemminger:
> Loading BPF is a could solution to doing dynamic flow matching.
> It needs to be done differently to be accepted.
>
> Putting raw machine instructions in source code is as bad as binary
> blobs. You need to provide original source of program and then have
> build instructions to create any needed code.
> >>> The source program is provided in this patch: tap_bpf_program.c It
> >>> is pre-compiled to avoid requiring too many dependencies when building
> DPDK.
> >> But the "freedom to modify" comes into play here. If a *evil* vendor
> >> builds an application based on DPDK and does not provide source. Then
> >> user still deserves the right to modify the eBPF program that it
> >> loads as GPL. The best solution is to make the TAP PMD loader routine
> load the program from a file.
> >> Although I am certainly not a FSF legal scholar, putting GPL'd object
> >> code in TAP PMD risks accusations of being a derived or combined work.
> > Good point.
> > The compiled BPF may be provided as a plugin file.
> > So we would be free to not package this GPL file.
Re: [dpdk-dev] [PATCH v3 2/2] examples/ipsec-secgw: add target queues in flow actions
Hi Anoob,
On Wed, Dec 13, 2017 at 12:11:18PM +0530, Anoob Joseph wrote:
> Hi Nelio,
>
>
> On 12/12/2017 08:08 PM, Nelio Laranjeiro wrote:
> > Hi Anoob,
> >
> > On Tue, Dec 12, 2017 at 07:34:31PM +0530, Anoob Joseph wrote:
> > > Hi Nelio,
> > >
> > >
> > > On 12/12/2017 07:14 PM, Nelio Laranjeiro wrote:
> > > > Hi Anoob,
> > > >
> > > > On Tue, Dec 12, 2017 at 06:13:08PM +0530, Anoob Joseph wrote:
> > > > > Hi Nelio,
> > > > >
> > > > >
> > > > > On 12/11/2017 07:34 PM, Nelio Laranjeiro wrote:
> > > > > > Mellanox INNOVA NIC needs to have final target queue actions to
> > > > > > perform
> > > > > > inline crypto.
> > > > > >
> > > > > > Signed-off-by: Nelio Laranjeiro
> > > > > >
> > > > > > ---
> > > > > >
> > > > > > Changes in v3:
> > > > > >
> > > > > > * removed PASSTHRU test for ingress.
> > > > > > * removed check on configured queues for the queue action.
> > > > > >
> > > > > > Changes in v2:
> > > > > >
> > > > > > * Test the rule by PASSTHRU/RSS/QUEUE and apply the first one
> > > > > > validated.
> > > > > > ---
> > > > > > examples/ipsec-secgw/ipsec.c | 57
> > > > > > ++--
> > > > > > examples/ipsec-secgw/ipsec.h | 2 +-
> > > > > > 2 files changed, 56 insertions(+), 3 deletions(-)
> > > > > >
> > > > > > diff --git a/examples/ipsec-secgw/ipsec.c
> > > > > > b/examples/ipsec-secgw/ipsec.c
> > > > > > index 17bd7620d..1b8b251c8 100644
> > > > > > --- a/examples/ipsec-secgw/ipsec.c
> > > > > > +++ b/examples/ipsec-secgw/ipsec.c
> > > > > > @@ -142,6 +142,7 @@ create_session(struct ipsec_ctx *ipsec_ctx,
> > > > > > struct ipsec_sa *sa)
> > > > > >
> > > > > > rte_eth_dev_get_sec_ctx(
> > > > > >
> > > > > > sa->portid);
> > > > > > const struct rte_security_capability
> > > > > > *sec_cap;
> > > > > > + int ret = 0;
> > > > > > sa->sec_session =
> > > > > > rte_security_session_create(ctx,
> > > > > > &sess_conf,
> > > > > > ipsec_ctx->session_pool);
> > > > > > @@ -201,15 +202,67 @@ create_session(struct ipsec_ctx *ipsec_ctx,
> > > > > > struct ipsec_sa *sa)
> > > > > > sa->action[0].type =
> > > > > > RTE_FLOW_ACTION_TYPE_SECURITY;
> > > > > > sa->action[0].conf = sa->sec_session;
> > > > > > - sa->action[1].type = RTE_FLOW_ACTION_TYPE_END;
> > > > > > -
> > > > > > sa->attr.egress = (sa->direction ==
> > > > > >
> > > > > > RTE_SECURITY_IPSEC_SA_DIR_EGRESS);
> > > > > > sa->attr.ingress = (sa->direction ==
> > > > > >
> > > > > > RTE_SECURITY_IPSEC_SA_DIR_INGRESS);
> > > > > > + if (sa->attr.ingress) {
> > > > > > + uint8_t rss_key[40];
> > > > > > + struct rte_eth_rss_conf rss_conf = {
> > > > > > + .rss_key = rss_key,
> > > > > > + .rss_key_len = 40,
> > > > > > + };
> > > > > > + struct rte_eth_dev *eth_dev;
> > > > > > + union {
> > > > > > + struct rte_flow_action_rss rss;
> > > > > > + struct {
> > > > > > + const struct rte_eth_rss_conf
> > > > > > *rss_conf;
> > > > > > + uint16_t num;
> > > > > > + uint16_t
> > > > > > queue[RTE_MAX_QUEUES_PER_PORT];
> > > > > > + } local;
> > > > > > + } action_rss;
> > > > > > + unsigned int i;
> > > > > > + unsigned int j;
> > > > > > +
> > > > > > + sa->action[2].type =
> > > > > > RTE_FLOW_ACTION_TYPE_END;
> > > > > > + /* Try RSS. */
> > > > > > + sa->action[1].type =
> > > > > > RTE_FLOW_ACTION_TYPE_RSS;
> > > > > > + sa->action[1].conf = &action_rss;
> > > > > > + eth_dev = ctx->device;
> > > > > > +
> > > > > > rte_eth_dev_rss_hash_conf_get(sa->portid,
> > > > > > +
> > > > > > &rss_conf);
> > > > > > + for (i = 0, j = 0;
> > > > > > +i < eth_dev->data->nb_rx_queues;
> > > > > > ++i)
> > > > > > + if (eth_dev->data->rx_queues[i])
> > > > > > +
> > > > > > action_rss.
Re: [dpdk-dev] [PATCH v2 18/18] doc: remove devargs deprecation notices
Hello Gaetan, On Thursday 12 October 2017 01:51 PM, Gaetan Rivet wrote: These actions have been enacted. Signed-off-by: Gaetan Rivet --- doc/guides/rel_notes/deprecation.rst | 13 - 1 file changed, 13 deletions(-) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index ef2264f..23faa19 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -16,19 +16,6 @@ Deprecation Notices - ``rte_set_log_type``, replaced by ``rte_log_set_level`` - ``rte_get_log_type``, replaced by ``rte_log_get_level`` -* eal: several API and ABI changes are planned for ``rte_devargs`` in v17.11. - The format of device command line parameters will change. The bus will need - to be explicitly stated in the device declaration. The enum ``rte_devtype`` - was used to identify a bus and will disappear. - The structure ``rte_devargs`` will change. - The ``rte_devargs_list`` will be made private. - The following functions are deprecated starting from 17.08 and will either be - modified or removed in 17.11: - - - ``rte_eal_devargs_add`` - - ``rte_eal_devargs_type_count`` - - ``rte_eal_parse_devargs_str``, replaced by ``rte_eal_devargs_parse`` - * eal: An ABI change is planned for 17.11 to make DPDK aware of IOVA address translation scheme. Reference to phys address in EAL data-structure or functions may change to Once this patch is formalized, the documentation reference for rte_devargs.h also needs to be changed as it still refers to RTE devargs as: "...These devices can be PCI devices or virtual devices". Similarly, the rte_devargs_parse too has PCI traces. Next step would be to remove the "pci"/"vdev" reference from rte_eal_dev_attach. Former can be part of this series, but the later needs to be a separate patch, I think. Let me know if you want me to work on these (or later). Other than that, I think I am OK with overall patch. If you can push the final series (I am not sure it would be with or without bus control), I can give it a spin (to vaildate if non-PCI like FSLMC bus can work fine).
Re: [dpdk-dev] [PATCH v5 0/4] Vhost: fix mq=on but VIRTIO_NET_F_MQ not negotiated
Hi Paolo, On 12/13/2017 10:15 AM, Paolo Bonzini wrote: On 13/12/2017 09:51, Maxime Coquelin wrote: This series fixes this by destroying all but first queue pair in the backend if VIRTIO_NET_F_MQ isn't negotiated. First patches makes sure that VHOST_USER_SET_FEATURES request doesn't change Virtio features while the device is running, which should never happen as per the Virtio spec. This helps to make sure vitqueues aren't destroyed while being processed, but also protect from other illegal features changes (e.g. VIRTIO_NET_F_MRG_RXBUF). Hi Maxime, I think this series is wrong from the virtio spec's point of view. If the driver requests VIRTIO_NET_F_MQ, that does not mean "the driver knows about multiqueue", it only means that "the driver wants to read max_virtqueue_pairs" from configuration space. Actually, my series fixes half of the problem, the case where driver does not know about multiqueue. In this case, there is no point in the backend to wait for the initialization of queues that does not exist. So I think my series is not enough, but not wrong. Just like it's perfectly fine for a device to propose VIRTIO_NET_F_MQ and set max_virtqueue_pairs=1, a driver can negotiate VIRTIO_NET_F_MQ and then skip initialization of some virtqueues. In fact, for virtio-net there is an explicit way to say how many virtqueue pairs are available; the virtio spec's section 5.1.5 (Network device, Device Initialization) mentions that Even with VIRTIO_NET_F_MQ, only receiveq1, transmitq1 and controlq are used by default. The driver would send the VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET command specifying the number of the transmit and receive queues to use. Yes, I agree. I was planning to send a vhost-user protocol spec update to forward this information to the backend with a new request. Currently, DPDK will increment the queue counter each time it receives a request for a new queue. Then it waits for all queues to be initialized (but not necessarily enabled) to start the vhost device. The problem is that QEMU, when receiving the VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET command, will send VHOST_USER_SET_VRING_ENABLE request to the backend to enable first queue pair, and disable all others. We cannot destroy a queue on disable, because it could happen in other cases, where it would be re-enabled without being re-initialized. So on DPDK side, my understanding is that we cannot deduce the number of queues that we have to wait to be initialized before starting the device. DPDK currently assume a queue to be initialized if rings addresses are set and if it has received both call and kick fds. I only fixed half of the problem as a first step because current Kernel & DPDK virtio-net drivers always allocate the maximum number of queues exposed by QEMU, even if it does use them all. But it is not compliant with the Virtio spec, which does not imply this (and the spec is right). Thanks, Maxime Thanks, Paolo
Re: [dpdk-dev] [PATCH 1/7] event/octeontx: move eventdev octeontx test to driver
> -Original Message- > From: Pavan Nikhilesh [mailto:pbhagavat...@caviumnetworks.com] > Sent: Tuesday, December 12, 2017 7:27 PM > To: jerin.ja...@caviumnetworks.com; Richardson, Bruce > ; Van Haaren, Harry > ; Eads, Gage ; > hemant.agra...@nxp.com; nipun.gu...@nxp.com; Ma, Liang J > > Cc: dev@dpdk.org; Pavan Nikhilesh > Subject: [dpdk-dev] [PATCH 1/7] event/octeontx: move eventdev octeontx test > to driver > > Move octeontx eventdev specific test (test_eventdev_octeontx.c) to > driver/event/octeontx. Replying to 1st patch, as no cover letter; Summary of patchset: - Move tests for a specific Eventdev PMD into the PMD dir: drivers/event/x/x_selftest.c - Enable self tests to run when passed the vdev arg "self-test=1" A few comments on this change; 1) We should not lose the capability to run tests as part of the existing unit testing infrastructure. We should not fragment the testing tool - requiring multiple binaries to test a single component. >From discussion on #IRC, it seems reasonable to call rte_eal_vdev_init() >with "self-test=1" from the test/test/ code, and then we can continue to use >the existing test infrastructure despite that the actual tests are now part of >each PMD. 2) We should not copy/paste TEST_ASSERT macros into new test files. Abstracting the TEST_ASSERT and other macros out to a header file would solve this duplication. Specific comments will be sent as replies to the patches. Cheers, -Harry
Re: [dpdk-dev] [PATCH 4/7] event/sw: move eventdev sw test to driver
> From: Pavan Nikhilesh [mailto:pbhagavat...@caviumnetworks.com] > Sent: Tuesday, December 12, 2017 7:27 PM > To: jerin.ja...@caviumnetworks.com; Richardson, Bruce > ; Van Haaren, Harry > ; Eads, Gage ; > hemant.agra...@nxp.com; nipun.gu...@nxp.com; Ma, Liang J > > Cc: dev@dpdk.org; Pavan Nikhilesh > Subject: [dpdk-dev] [PATCH 4/7] event/sw: move eventdev sw test to driver > > Move software eventdev specific test (test_eventdev_sw) to > driver/event/sw. > > Signed-off-by: Pavan Nikhilesh > --- > test/test/test_eventdev_sw.c => drivers/event/sw/selftest_sw.c | 0 > test/test/Makefile | 1 - > 2 files changed, 1 deletion(-) > rename test/test/test_eventdev_sw.c => drivers/event/sw/selftest_sw.c > (100%) > > diff --git a/test/test/test_eventdev_sw.c b/drivers/event/sw/selftest_sw.c > similarity index 100% > rename from test/test/test_eventdev_sw.c > rename to drivers/event/sw/selftest_sw.c Rename to sw_evdev_selftest.c for consistency with other filenames With that Acked-by: Harry van Haaren > diff --git a/test/test/Makefile b/test/test/Makefile > index 87e3169d2..c551ad964 100644 > --- a/test/test/Makefile > +++ b/test/test/Makefile > @@ -210,7 +210,6 @@ ifeq ($(CONFIG_RTE_LIBRTE_EVENTDEV),y) > SRCS-y += test_eventdev.c > SRCS-y += test_event_ring.c > SRCS-y += test_event_eth_rx_adapter.c > -SRCS-$(CONFIG_RTE_LIBRTE_PMD_SW_EVENTDEV) += test_eventdev_sw.c > endif > > SRCS-$(CONFIG_RTE_LIBRTE_KVARGS) += test_kvargs.c > -- > 2.14.1
Re: [dpdk-dev] [PATCH v5 0/4] Vhost: fix mq=on but VIRTIO_NET_F_MQ not negotiated
On 13/12/2017 11:11, Maxime Coquelin wrote: >> Hi Maxime, >> >> I think this series is wrong from the virtio spec's point of view. If >> the driver requests VIRTIO_NET_F_MQ, that does not mean "the driver >> knows about multiqueue", it only means that "the driver wants to read >> max_virtqueue_pairs" from configuration space. > > Actually, my series fixes half of the problem, the case where driver > does not know about multiqueue. > > In this case, there is no point in the backend to wait for the > initialization of queues that does not exist. > > So I think my series is not enough, but not wrong. You're right; what I meant by "wrong" is that it becomes unnecessary if you do VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET. But since this requires a vhost-user update, doing both makes sense. Thanks! Paolo
Re: [dpdk-dev] [PATCH] security: fix enum start value
On 12/13/2017 7:15 AM, Akhil Goyal wrote:
enum should be initialized with 1 so that unitialized(memset)
memory may not be treated as a valid enum value.
Fixes: c261d1431bd8 ("security: introduce security API and framework")
Signed-off-by: Akhil Goyal
---
Acked-by: Radu Nicolau
Re: [dpdk-dev] [PATCH v2 18/18] doc: remove devargs deprecation notices
Hello Shreyansh, On Wed, Dec 13, 2017 at 03:47:04PM +0530, Shreyansh Jain wrote: > Hello Gaetan, > > On Thursday 12 October 2017 01:51 PM, Gaetan Rivet wrote: > > These actions have been enacted. > > > > Signed-off-by: Gaetan Rivet > > --- > > doc/guides/rel_notes/deprecation.rst | 13 - > > 1 file changed, 13 deletions(-) > > > > diff --git a/doc/guides/rel_notes/deprecation.rst > > b/doc/guides/rel_notes/deprecation.rst > > index ef2264f..23faa19 100644 > > --- a/doc/guides/rel_notes/deprecation.rst > > +++ b/doc/guides/rel_notes/deprecation.rst > > @@ -16,19 +16,6 @@ Deprecation Notices > > - ``rte_set_log_type``, replaced by ``rte_log_set_level`` > > - ``rte_get_log_type``, replaced by ``rte_log_get_level`` > > -* eal: several API and ABI changes are planned for ``rte_devargs`` in > > v17.11. > > - The format of device command line parameters will change. The bus will > > need > > - to be explicitly stated in the device declaration. The enum > > ``rte_devtype`` > > - was used to identify a bus and will disappear. > > - The structure ``rte_devargs`` will change. > > - The ``rte_devargs_list`` will be made private. > > - The following functions are deprecated starting from 17.08 and will > > either be > > - modified or removed in 17.11: > > - > > - - ``rte_eal_devargs_add`` > > - - ``rte_eal_devargs_type_count`` > > - - ``rte_eal_parse_devargs_str``, replaced by ``rte_eal_devargs_parse`` > > - > > * eal: An ABI change is planned for 17.11 to make DPDK aware of IOVA > > address > > translation scheme. > > Reference to phys address in EAL data-structure or functions may change > > to > > > > Once this patch is formalized, the documentation reference for rte_devargs.h > also needs to be changed as it still refers to RTE devargs as: > > "...These devices can be PCI devices or virtual devices". > > Similarly, the rte_devargs_parse too has PCI traces. > > Next step would be to remove the "pci"/"vdev" reference from > rte_eal_dev_attach. > Noted, thanks. > Former can be part of this series, but the later needs to be a separate > patch, I think. Let me know if you want me to work on these (or later). > > Other than that, I think I am OK with overall patch. If you can push the > final series (I am not sure it would be with or without bus control), I can > give it a spin (to vaildate if non-PCI like FSLMC bus can work fine). Indeed, I also think everything should be settled first. I have mostly finished working on this series yesterday, I will integrate your above remarks which will be short. (Well, by finished I mean I finished the first 90%. The other 90% is still in progress...) I removed the rte_devargs unit test and am not too happy about it. There are parsing functions there, which are extremely error-prone and would like to have at least the basis for some tests, that we could populate as we go. If I have the courage I will try to write it and send it with this series. I would certainly appreciate if you are able to fix the pci / vdev limitation in rte_eal_dev_attach, as I am starting to be overwhelmed with work (trying to finish a lot of things before the holidays). Thanks for the review! -- Gaëtan Rivet 6WIND
Re: [dpdk-dev] [PATCH 1/7] event/octeontx: move eventdev octeontx test to driver
On Wed, Dec 13, 2017 at 10:19:51AM +, Van Haaren, Harry wrote: > > -Original Message- > > From: Pavan Nikhilesh [mailto:pbhagavat...@caviumnetworks.com] > > Sent: Tuesday, December 12, 2017 7:27 PM > > To: jerin.ja...@caviumnetworks.com; Richardson, Bruce > > ; Van Haaren, Harry > > ; Eads, Gage ; > > hemant.agra...@nxp.com; nipun.gu...@nxp.com; Ma, Liang J > > > > Cc: dev@dpdk.org; Pavan Nikhilesh > > Subject: [dpdk-dev] [PATCH 1/7] event/octeontx: move eventdev octeontx test > > to driver > > > > Move octeontx eventdev specific test (test_eventdev_octeontx.c) to > > driver/event/octeontx. > > > > Replying to 1st patch, as no cover letter; > > Summary of patchset: > - Move tests for a specific Eventdev PMD into the PMD dir: > drivers/event/x/x_selftest.c > - Enable self tests to run when passed the vdev arg "self-test=1" > > > A few comments on this change; > > 1) We should not lose the capability to run tests as part of the existing > unit testing infrastructure. We should not fragment the testing tool - > requiring multiple binaries to test a single component. > > From discussion on #IRC, it seems reasonable to call rte_eal_vdev_init() > with "self-test=1" from the test/test/ code, and then we can continue to use > the existing test infrastructure despite that the actual tests are now part > of each PMD. > > 2) We should not copy/paste TEST_ASSERT macros into new test files. > Abstracting the TEST_ASSERT and other macros out to a header file would solve > this duplication. > > > Specific comments will be sent as replies to the patches. Cheers, -Harry What I gather from a cursory glance at this set is that the self tests are designed to be triggered via devargs to the device driver, correct? I'm not sure I like this approach, though I do agree with having the tests inside the individual drivers. What I think I would prefer to see is the self-tests being called via an API rather than via devargs. I think we should add a "rte_event_dev_self_test()" API to the eventdev library, and have that then call into the driver-provided tests. This means that self-tests can only be called by applications which are set up to allow the tests to be called, e.g. the autotest binary, while also avoiding the issue of having lots of driver specifics clutter up test binaries. Regards, /Bruce
Re: [dpdk-dev] [PATCH v3 1/4] Introducing SPDX License Identifiers
Hi Hemant, Some comments below 08/12/2017 08:41, Hemant Agrawal: > --- /dev/null > +++ b/Licenses/Exceptions.txt Please use lowercase for file and directory. By the way, the text is referring to exceptions.txt. > @@ -0,0 +1,12 @@ > +This file will record any exceptions in DPDK Project with respect to DPDK > +IP License policy as defined in DPDK Charter available at: > + > +http://dpdk.org/about/charter#ip This link might be indented. I think we should make clear that - BSD-3-Clause - GPL-2.0 - dual BSD-3-Clause/GPL-2.0 - dual BSD-3-Clause/LGPL-2.1 are not exceptions. > +-- > +License Name SPDX Identifier TB Approval Date GB > Approval Date File name > +-- The table is large, and file names will be long. Can we remove "License Name" as it is redundant with SPDX id? > --- /dev/null > +++ b/Licenses/README Good idea to add a README here. > @@ -0,0 +1,82 @@ > +The DPDK uses the Open Source BSD-3-Clause license for the core libraries and > +drivers. The kernel components are naturally GPLv2 licensed. You should use SPDX GPL-2.0 > +Including big blocks of License headers in all files blows up the > +source code with mostly redundant information. An additional problem > +is that even the same licenses are referred to by a number of > +slightly varying text blocks (full, abbreviated, different > +indentation, line wrapping and/or white space, with obsolete address > +information, ...) which makes validation and automatic processing a > nightmare. > + > +To make this easier, DPDK is adpoting the use of a single line reference to Please do not use this tense in the README. We could say "DPDK uses" instead of "DPDK is adpoting the use". > +Unique License Identifiers in source files as defined by the Linux > Foundation's > +SPDX project [1]. My preference is to insert URLs inline to make reading flow easier. > +Adding license information in this fashion, rather than adding full license > +text, can be more efficient for developers; decreases errors; and improves > +automated detection of licenses. The current set of valid, predefined SPDX > +identifiers is set forth on the SPDX License List[2] > +at https://spdx.org/licenses/. Here you are mixing inline and reference :) > +For example, to label a file as subject to the BSD-3-Clause license, > +the following text would be used: > + > +Copyright (C) [YEAR] NAME-OF-COPYRIGHT-HOLDER I think (C) is useless. About the YEAR, we should explicit what it is. I think it is only the first year, and we do not need to update the last year of update. We should also explicit why it is there and why it is not required to add more copyrights. The copyright is required to express who is allowed to declare the license of the code. It is a common practice to add a Copyright line when doing a big update. I think it is fair, but for small changes, it is really not required as we implicitly comply with the current copyright holder and license. > +SPDX-License-Identifier:BSD-3-Clause Why adding these spaces in the middle of the line? [...] > +Note: DPDK currently adhere to it's IP policies[3]. Any exception to this > shall This sentence is strange. To me, it is obvious that DPDK adheres to its policies. Suggested rewording: Any exception to the DPDK IP policies shall... > +be approved by DPDK tech board and DPDK Governing Board. Steps for any > exception > +approval: [...] > +Projects like U-boot have been been using SPDX License Idenfiers successfully > +[2]. They have been referered in implementing SPDX based guidelines in DPDK. I think you can remove this paragraph from the README. [...] > +DPDK project supported licenses are: > + > +Full nameSPDX Identifier OSI Approved > File name URI > +=== This table is large. I suggest to format it as a list: SPDX identifier full name file name URL > +GNU General Public License v2.0 only GPL-2.0 Y > gpl-2.0.txt http://spdx.org/licenses/GPL-2.0.html#licenseText > +GNU Lesser General Public License v2.1 or later LGPL-2.1+ Y > lgpl-2.1.txt > http://spdx.org/licenses/LGPL-2.1.html#licenseText Later than LGPL-2.1 is not specified in the charter. Better to remove the "+". > +BSD 3-clause "New" or "Revised" License BSD-3-ClauseY > bsd-3-clause.txt > http://spdx.org/licenses/BSD-3-Clause#licenseText [...] > --- a/README > +++ b/README > @@ -1,8 +1,9 @@ > DPDK is a set of libraries and drivers for fast packet processing. > It supports many processor arc
Re: [dpdk-dev] [PATCH v2 18/18] doc: remove devargs deprecation notices
Hello Gaetan, > -Original Message- > From: Gaëtan Rivet [mailto:gaetan.ri...@6wind.com] > Sent: Wednesday, December 13, 2017 3:56 PM > To: Shreyansh Jain > Cc: dev@dpdk.org > Subject: Re: [PATCH v2 18/18] doc: remove devargs deprecation notices > > Hello Shreyansh, > > On Wed, Dec 13, 2017 at 03:47:04PM +0530, Shreyansh Jain wrote: > > Hello Gaetan, > > > > On Thursday 12 October 2017 01:51 PM, Gaetan Rivet wrote: > > > These actions have been enacted. > > > > > > Signed-off-by: Gaetan Rivet > > > --- > > > doc/guides/rel_notes/deprecation.rst | 13 - > > > 1 file changed, 13 deletions(-) > > > > > > diff --git a/doc/guides/rel_notes/deprecation.rst > b/doc/guides/rel_notes/deprecation.rst > > > index ef2264f..23faa19 100644 > > > --- a/doc/guides/rel_notes/deprecation.rst > > > +++ b/doc/guides/rel_notes/deprecation.rst > > > @@ -16,19 +16,6 @@ Deprecation Notices > > > - ``rte_set_log_type``, replaced by ``rte_log_set_level`` > > > - ``rte_get_log_type``, replaced by ``rte_log_get_level`` > > > -* eal: several API and ABI changes are planned for ``rte_devargs`` in > v17.11. > > > - The format of device command line parameters will change. The bus will > need > > > - to be explicitly stated in the device declaration. The enum > ``rte_devtype`` > > > - was used to identify a bus and will disappear. > > > - The structure ``rte_devargs`` will change. > > > - The ``rte_devargs_list`` will be made private. > > > - The following functions are deprecated starting from 17.08 and will > either be > > > - modified or removed in 17.11: > > > - > > > - - ``rte_eal_devargs_add`` > > > - - ``rte_eal_devargs_type_count`` > > > - - ``rte_eal_parse_devargs_str``, replaced by ``rte_eal_devargs_parse`` > > > - > > > * eal: An ABI change is planned for 17.11 to make DPDK aware of IOVA > address > > > translation scheme. > > > Reference to phys address in EAL data-structure or functions may > change to > > > > > > > Once this patch is formalized, the documentation reference for > rte_devargs.h > > also needs to be changed as it still refers to RTE devargs as: > > > > "...These devices can be PCI devices or virtual devices". > > > > Similarly, the rte_devargs_parse too has PCI traces. > > > > Next step would be to remove the "pci"/"vdev" reference from > > rte_eal_dev_attach. > > > > Noted, thanks. > > > Former can be part of this series, but the later needs to be a separate > > patch, I think. Let me know if you want me to work on these (or later). > > > > Other than that, I think I am OK with overall patch. If you can push the > > final series (I am not sure it would be with or without bus control), I can > > give it a spin (to vaildate if non-PCI like FSLMC bus can work fine). > > Indeed, I also think everything should be settled first. > I have mostly finished working on this series yesterday, > I will integrate your above remarks which will be short. > > (Well, by finished I mean I finished the first 90%. The other 90% is > still in progress...) > > I removed the rte_devargs unit test and am not too happy about it. There > are parsing functions there, which are extremely error-prone and would > like to have at least the basis for some tests, that we could populate > as we go. If I have the courage I will try to write it and send it with > this series. While reading through the code, I also had the same feeling - there can be corner cases in the parsing functions which I can't imagine. Anyways, those need to be runtime-verified - static reviews may not suffice. > > I would certainly appreciate if you are able to fix the pci / vdev > limitation in rte_eal_dev_attach, as I am starting to be overwhelmed > with work (trying to finish a lot of things before the holidays). OK. Once you give the devargs a push, I will start work on the PCI removal from rte_eal_dev_attach. Before that, I just want to be sure of devargs with non-PCI bus (non hotplug case). And, thanks for tons of work you are handling. I saw the patches and really appreciate how you have split things up in sequential manner per-patch. It is difficult. > > Thanks for the review! > > -- > Gaëtan Rivet > 6WIND
Re: [dpdk-dev] [RFC] eventdev: add crypto adapter API header
On 29/11/2017 11:41 AM, Jerin Jacob wrote:
-Original Message-
...
Adding Declan and Hemant.
> IMO, RTE_EVENT_CRYPTO_ENQ_MULTI_EVENTQ may not be very useful
from application perceptive as the scope is very limited.
In real world use cases, we will be attaching destination event queue
information
to the session, not to the queue pair.
IMO, RTE_EVENT_CRYPTO_ENQ_MBUF_MULTI_EVENTQ scheme may not very
convenient for application writers as
# it relies on mbuf private area memory. So it has additional memory alloc/free
requirements.
# additional overhead for application/PMD to write/read the event queue metadata
information per packet.
Since we already have meta data structure in the crypto
area, How about adding the destination event queue attributes
in the PMD crypto session area and for, _session less_, we can add it
in rte_crypto_op stricture? This will help in:
# Offloading HW specific meta data generation for event queue attributes
to slow path.
# From the application perspective, most likely the event queue parameters
will be different for each session not per packet nor per event queue
pair.
Hey Jerin,
given my limited experience with eventdev, your proposed approach in
general makes sense to me, in that a packet flow having crypto
processing done will always be forwarded the same next stage event
queue. So storing this state in the crypto session, or crypto op in the
case of sessionless ops, seems sensible.
Something like below to share my view. Exact details may be we can work it out.
I terms of your proposed changes below, my main concern would be
introducing dependencies on the eventdev library into cryptodev, as with
this new crypto adpater you will have a dependency on cryptodev in
eventdev.
I think the best approach would be to support opaque metadata in both
the crypto op and crypto session structures, as this would allow other
uses cases to be supported which aren't specific to eventdev to also
store metadata across cryptodev processing.
➜ [master][dpdk.org] $ git diff
diff --git a/lib/librte_cryptodev/rte_crypto.h
b/lib/librte_cryptodev/rte_crypto.h
index 3d672fe7d..b44ef673b 100644
--- a/lib/librte_cryptodev/rte_crypto.h
+++ b/lib/librte_cryptodev/rte_crypto.h
@@ -115,6 +115,9 @@ struct rte_crypto_op {
uint8_t reserved[5];
/**< Reserved bytes to fill 64 bits for future additions */
+#if 0
+ Crypto completion event attribute. For _session less_ crypto enqueue
operation,
+ The will field shall be used by application to post the crypto completion
event
+ upon the crypto enqueue operation complete.
+ Note: In the case of session based crypto operation, SW based crypto adapter
can use
+ this memory to store crypto event completion attributes from the PMD
+ specific session area.
+
+ Note: ev.event_ptr will point to struct rte_crypto_op *op, So
+ that core can free the ops memory on event_dequeue().
+#endif
+
+ struct rte_event ev;
struct rte_mempool *mempool;
/**< crypto operation mempool which operation is allocated from
* */
diff --git a/lib/librte_cryptodev/rte_cryptodev.h
b/lib/librte_cryptodev/rte_cryptodev.h
index dade5548f..540b29e66 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -945,6 +945,13 @@ rte_cryptodev_sym_session_init(uint8_t dev_id,
struct rte_crypto_sym_xform *xforms,
struct rte_mempool *mempool);
+#if 0
+ Create PMD specific session meta data for the destination event queue
+ attribute to post the crypto completion event on crypto work complete.
+#endif
+int
+rte_cryptodev_sym_session_event_init(uint8_t dev_id,
+ struct rte_cryptodev_sym_session *sess,
+ struct rte_crypto_sym_xform *xforms,
+ struct rte_mempool *mempool,
+ struct rte_event ev);
+
/**
* Frees private data for the device id, based on its device type,
* returning it to its mempool.
+ *
+ * The metadata offset is used to configure the location of the
+ * rte_event_crypto_metadata structure within the mbuf's private metadata area.
+ *
+ * When the application sends crypto operations to the adapter,
+ * the crypto queue pair identifier needs to be specified, similarly eventdev
+ * parameters such as the flow id, scheduling type etc are needed by the
+ * adapter when it enqueues mbufs from completed crypto operations to eventdev.
+ */
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include
+#include
+
+#include "rte_eventdev.h"
+
+#define RTE_EVENT_CRYPTO_ADAPTER_MAX_INSTANCE 32
+
+ /**
+ * @warning
+ * @b EXPERIMENTAL: this enum may change without prior notice
+ *
+ * Crypto event queue conf type
+ */
+enum rte_event_crypto_conf_type {
+ RTE_EVENT_CRYPTO_CONF_TYPE_EVENT = 1,
+ /**< Refer RTE_EVENT_CRYPTO_ADAPTER_CAP_MULTI_EVENTQ */
+ RTE_EVENT_CRYPTO_CONF_TYPE_MBUF,
+ /**< Refer RTE_EVENT_CRYPTO_AD
Re: [dpdk-dev] [PATCH] vhost: fix dequeue zero copy not work with virtio1
Hi Junjie,
On 12/13/2017 05:50 PM, Junjie Chen wrote:
This fix dequeue zero copy can not work with Qemu
version >= 2.7. Since from Qemu 2.7 virtio device
use virtio-1 protocol, the zero copy code path
forget to add offset to buffer address.
Signed-off-by: Junjie Chen
---
lib/librte_vhost/virtio_net.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/librte_vhost/virtio_net.c b/lib/librte_vhost/virtio_net.c
index 6fee16e..79d80f7 100644
--- a/lib/librte_vhost/virtio_net.c
+++ b/lib/librte_vhost/virtio_net.c
@@ -977,7 +977,8 @@ copy_desc_to_mbuf(struct virtio_net *dev, struct
vhost_virtqueue *vq,
desc->addr + desc_offset, cpy_len {
cur->data_len = cpy_len;
cur->data_off = 0;
- cur->buf_addr = (void *)(uintptr_t)desc_addr;
+ cur->buf_addr = (void *)(uintptr_t)(desc_addr
+ + desc_offset);
cur->buf_iova = hpa;
/*
Thanks for fixing this.
Reviewed-by: Maxime Coquelin
Maxime
Re: [dpdk-dev] [PATCH 1/7] event/octeontx: move eventdev octeontx test to driver
On Wed, Dec 13, 2017 at 10:19:51AM +, Van Haaren, Harry wrote: > > -Original Message- > > From: Pavan Nikhilesh [mailto:pbhagavat...@caviumnetworks.com] > > Sent: Tuesday, December 12, 2017 7:27 PM > > To: jerin.ja...@caviumnetworks.com; Richardson, Bruce > > ; Van Haaren, Harry > > ; Eads, Gage ; > > hemant.agra...@nxp.com; nipun.gu...@nxp.com; Ma, Liang J > > > > Cc: dev@dpdk.org; Pavan Nikhilesh > > Subject: [dpdk-dev] [PATCH 1/7] event/octeontx: move eventdev octeontx test > > to driver > > > > Move octeontx eventdev specific test (test_eventdev_octeontx.c) to > > driver/event/octeontx. > > > > Replying to 1st patch, as no cover letter; > > Summary of patchset: > - Move tests for a specific Eventdev PMD into the PMD dir: > drivers/event/x/x_selftest.c > - Enable self tests to run when passed the vdev arg "self-test=1" > > > A few comments on this change; > > 1) We should not lose the capability to run tests as part of the existing > unit testing infrastructure. We should not fragment the testing tool - > requiring multiple binaries to test a single component. > > From discussion on #IRC, it seems reasonable to call rte_eal_vdev_init() > with "self-test=1" from the test/test/ code, and then we can continue to use > the existing test infrastructure despite that the actual tests are now part > of each PMD. > > 2) We should not copy/paste TEST_ASSERT macros into new test files. > Abstracting the TEST_ASSERT and other macros out to a header file would solve > this duplication. > I initially thought of abstracting the macros but couldnt find a suitable file to place them in we have two options here, one is to use CFLAGS and include test.h directly (dirty) or have rte_assert/test in eal/common/inlcude. Thoughts? > > Specific comments will be sent as replies to the patches. Cheers, -Harry
Re: [dpdk-dev] [PATCH v5 0/4] Vhost: fix mq=on but VIRTIO_NET_F_MQ not negotiated
On 12/13/17 11:24, Paolo Bonzini wrote: > On 13/12/2017 11:11, Maxime Coquelin wrote: >>> Hi Maxime, >>> >>> I think this series is wrong from the virtio spec's point of view. If >>> the driver requests VIRTIO_NET_F_MQ, that does not mean "the driver >>> knows about multiqueue", it only means that "the driver wants to read >>> max_virtqueue_pairs" from configuration space. >> >> Actually, my series fixes half of the problem, the case where driver >> does not know about multiqueue. >> >> In this case, there is no point in the backend to wait for the >> initialization of queues that does not exist. >> >> So I think my series is not enough, but not wrong. > > You're right; what I meant by "wrong" is that it becomes unnecessary if > you do VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET. But since this requires a > vhost-user update, doing both makes sense. Based on this, plus reviewing patch #4 for: + vq = dev->virtqueue[--dev->nr_vring]; + if (!vq) + continue; + + dev->virtqueue[dev->nr_vring] = NULL; Acked-by: Laszlo Ersek Thanks Laszlo
Re: [dpdk-dev] [PATCH 1/7] event/octeontx: move eventdev octeontx test to driver
On Wed, Dec 13, 2017 at 10:34:28AM +, Bruce Richardson wrote: > On Wed, Dec 13, 2017 at 10:19:51AM +, Van Haaren, Harry wrote: > > > -Original Message- > > > From: Pavan Nikhilesh [mailto:pbhagavat...@caviumnetworks.com] > > > Sent: Tuesday, December 12, 2017 7:27 PM > > > To: jerin.ja...@caviumnetworks.com; Richardson, Bruce > > > ; Van Haaren, Harry > > > ; Eads, Gage ; > > > hemant.agra...@nxp.com; nipun.gu...@nxp.com; Ma, Liang J > > > > > > Cc: dev@dpdk.org; Pavan Nikhilesh > > > Subject: [dpdk-dev] [PATCH 1/7] event/octeontx: move eventdev octeontx > > > test > > > to driver > > > > > > Move octeontx eventdev specific test (test_eventdev_octeontx.c) to > > > driver/event/octeontx. > > > > > > > > Replying to 1st patch, as no cover letter; > > > > Summary of patchset: > > - Move tests for a specific Eventdev PMD into the PMD dir: > > drivers/event/x/x_selftest.c > > - Enable self tests to run when passed the vdev arg "self-test=1" > > > > > > A few comments on this change; > > > > 1) We should not lose the capability to run tests as part of the existing > > unit testing infrastructure. We should not fragment the testing tool - > > requiring multiple binaries to test a single component. > > > > From discussion on #IRC, it seems reasonable to call rte_eal_vdev_init() > > with "self-test=1" from the test/test/ code, and then we can continue to > > use the existing test infrastructure despite that the actual tests are now > > part of each PMD. > > > > 2) We should not copy/paste TEST_ASSERT macros into new test files. > > Abstracting the TEST_ASSERT and other macros out to a header file would > > solve this duplication. > > > > > > Specific comments will be sent as replies to the patches. Cheers, -Harry > > What I gather from a cursory glance at this set is that the self tests > are designed to be triggered via devargs to the device driver, correct? > I'm not sure I like this approach, though I do agree with having the > tests inside the individual drivers. > > What I think I would prefer to see is the self-tests being called via an > API rather than via devargs. I think we should add a > "rte_event_dev_self_test()" API to the eventdev library, and have that > then call into the driver-provided tests. This means that self-tests can > only be called by applications which are set up to allow the tests to be > called, e.g. the autotest binary, while also avoiding the issue of > having lots of driver specifics clutter up test binaries. Agreed, will modify it to ops based scheme so that application can call driver specific `event_dev_self_test` and register selftest in test/test/test_eventdev.c. Although we would like to retain devargs selftest scheme for event_octeontx. I will remove it for event_sw. Does that sound good? > > Regards, > /Bruce Regards, Pavan
Re: [dpdk-dev] [RFC] eventdev: add crypto adapter API header
-Original Message-
> Date: Wed, 13 Dec 2017 11:03:06 +
> From: "Doherty, Declan"
> To: Jerin Jacob , Abhinandan Gujjar
>
> CC: dev@dpdk.org, narender.vang...@intel.com, Nikhil Rao
> , Gage Eads ,
> hemant.agra...@nxp.com, nidadavolu.mur...@cavium.com,
> nithin.dabilpu...@cavium.com, narayanaprasad.athr...@cavium.com
> Subject: Re: [RFC] eventdev: add crypto adapter API header
> User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
> Thunderbird/52.5.0
>
> On 29/11/2017 11:41 AM, Jerin Jacob wrote:
> > -Original Message-
>
> ...
>
> >
> > Adding Declan and Hemant.
> > > IMO, RTE_EVENT_CRYPTO_ENQ_MULTI_EVENTQ may not be very useful
> > from application perceptive as the scope is very limited.
> > In real world use cases, we will be attaching destination event queue
> > information
> > to the session, not to the queue pair.
> >
> >
> > IMO, RTE_EVENT_CRYPTO_ENQ_MBUF_MULTI_EVENTQ scheme may not very
> > convenient for application writers as
> > # it relies on mbuf private area memory. So it has additional memory
> > alloc/free
> > requirements.
> > # additional overhead for application/PMD to write/read the event queue
> > metadata
> > information per packet.
> >
> > Since we already have meta data structure in the crypto
> > area, How about adding the destination event queue attributes
> > in the PMD crypto session area and for, _session less_, we can add it
> > in rte_crypto_op stricture? This will help in:
> >
> > # Offloading HW specific meta data generation for event queue attributes
> > to slow path.
> > # From the application perspective, most likely the event queue parameters
> > will be different for each session not per packet nor per event queue
> > pair.
> >
>
> Hey Jerin,
Hey Declan,
>
> given my limited experience with eventdev, your proposed approach in general
> makes sense to me, in that a packet flow having crypto processing done will
> always be forwarded the same next stage event queue. So storing this state
> in the crypto session, or crypto op in the case of sessionless ops, seems
> sensible.
>
> > Something like below to share my view. Exact details may be we can work it
> > out.
> >
>
> I terms of your proposed changes below, my main concern would be introducing
> dependencies on the eventdev library into cryptodev, as with this new crypto
> adpater you will have a dependency on cryptodev in eventdev.
I agree with your dependency concern.
>
> I think the best approach would be to support opaque metadata in both the
> crypto op and crypto session structures, as this would allow other uses
> cases to be supported which aren't specific to eventdev to also store
> metadata across cryptodev processing.
Make sense. Just to add, adding a pointer would be overhead. I think, we
can reserve a few bytes as byte array and then later typecast with
eventdev api in eventdev library.
uint8_t eventdev_metadata[SOMEBYTES];
Thoughts?
>
> > ➜ [master][dpdk.org] $ git diff
> > diff --git a/lib/librte_cryptodev/rte_crypto.h
> > b/lib/librte_cryptodev/rte_crypto.h
> > index 3d672fe7d..b44ef673b 100644
> > --- a/lib/librte_cryptodev/rte_crypto.h
> > +++ b/lib/librte_cryptodev/rte_crypto.h
> > @@ -115,6 +115,9 @@ struct rte_crypto_op {
> > uint8_t reserved[5];
> > /**< Reserved bytes to fill 64 bits for future additions */
> >
> > +#if 0
> > + Crypto completion event attribute. For _session less_ crypto enqueue
> > operation,
> > + The will field shall be used by application to post the crypto completion
> > event
> > + upon the crypto enqueue operation complete.
> >
> > + Note: In the case of session based crypto operation, SW based crypto
> > adapter can use
> > + this memory to store crypto event completion attributes from the PMD
> > + specific session area.
> > +
> > + Note: ev.event_ptr will point to struct rte_crypto_op *op, So
> > + that core can free the ops memory on event_dequeue().
> > +#endif
> > +
> > + struct rte_event ev;
> >
> > struct rte_mempool *mempool;
> > /**< crypto operation mempool which operation is allocated from
> > * */
> > diff --git a/lib/librte_cryptodev/rte_cryptodev.h
> > b/lib/librte_cryptodev/rte_cryptodev.h
> > index dade5548f..540b29e66 100644
> > --- a/lib/librte_cryptodev/rte_cryptodev.h
> > +++ b/lib/librte_cryptodev/rte_cryptodev.h
> > @@ -945,6 +945,13 @@ rte_cryptodev_sym_session_init(uint8_t dev_id,
> > struct rte_crypto_sym_xform *xforms,
> > struct rte_mempool *mempool);
> >
> > +#if 0
> > + Create PMD specific session meta data for the destination event queue
> > + attribute to post the crypto completion event on crypto work complete.
> > +#endif
> > +int
> > +rte_cryptodev_sym_session_event_init(uint8_t dev_id,
> > + struct rte_cryptodev_sym_session *sess,
> > + struct rte_crypto_sym_xform *xforms,
> > + struct rte_mempool *m
[dpdk-dev] [PATCH v6 1/2] eal: add uevent monitor for hot plug
Hello Jeff, I've failed to apply the patch on latest DPDK (git://dpdk.org/dpdk), Due to missing eal_common_vdev.c file What am I doing wrong ? Moti $ patch -p1 < dpdk-dev-v6-1-2-eal-add-uevent-monitor-for-hot-plug.patch patching file drivers/bus/pci/bsd/pci.c Hunk #1 succeeded at 126 (offset -1 lines). patching file drivers/bus/pci/linux/pci.c patching file drivers/bus/pci/linux/pci_init.h patching file drivers/bus/pci/pci_common.c Hunk #1 succeeded at 282 (offset -1 lines). Hunk #2 succeeded at 482 (offset -1 lines). Hunk #3 succeeded at 504 (offset -1 lines). Hunk #4 succeeded at 568 (offset -1 lines). patching file drivers/bus/pci/pci_common_uio.c patching file drivers/bus/pci/private.h patching file drivers/bus/pci/rte_bus_pci.h patching file lib/librte_eal/bsdapp/eal/eal_dev.c patching file lib/librte_eal/bsdapp/eal/include/exec-env/rte_dev.h patching file lib/librte_eal/common/eal_common_bus.c patching file lib/librte_eal/common/eal_common_dev.c Hunk #2 succeeded at 258 (offset -10 lines). can't find file to patch at input line 746 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -- |diff --git a/lib/librte_eal/common/eal_common_vdev.c b/lib/librte_eal/common/eal_common_vdev.c |index f7e547a..2ad517c 100644 |--- a/lib/librte_eal/common/eal_common_vdev.c |+++ b/lib/librte_eal/common/eal_common_vdev.c -- File to patch: ^C
Re: [dpdk-dev] [PATCH v3 2/2] examples/ipsec-secgw: add target queues in flow actions
Hi Nelio,
On 12/13/2017 03:32 PM, Nelio Laranjeiro wrote:
Hi Anoob,
On Wed, Dec 13, 2017 at 12:11:18PM +0530, Anoob Joseph wrote:
Hi Nelio,
On 12/12/2017 08:08 PM, Nelio Laranjeiro wrote:
Hi Anoob,
On Tue, Dec 12, 2017 at 07:34:31PM +0530, Anoob Joseph wrote:
Hi Nelio,
On 12/12/2017 07:14 PM, Nelio Laranjeiro wrote:
Hi Anoob,
On Tue, Dec 12, 2017 at 06:13:08PM +0530, Anoob Joseph wrote:
Hi Nelio,
On 12/11/2017 07:34 PM, Nelio Laranjeiro wrote:
Mellanox INNOVA NIC needs to have final target queue actions to perform
inline crypto.
Signed-off-by: Nelio Laranjeiro
---
Changes in v3:
* removed PASSTHRU test for ingress.
* removed check on configured queues for the queue action.
Changes in v2:
* Test the rule by PASSTHRU/RSS/QUEUE and apply the first one validated.
---
examples/ipsec-secgw/ipsec.c | 57
++--
examples/ipsec-secgw/ipsec.h | 2 +-
2 files changed, 56 insertions(+), 3 deletions(-)
diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c
index 17bd7620d..1b8b251c8 100644
--- a/examples/ipsec-secgw/ipsec.c
+++ b/examples/ipsec-secgw/ipsec.c
@@ -142,6 +142,7 @@ create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa
*sa)
rte_eth_dev_get_sec_ctx(
sa->portid);
const struct rte_security_capability *sec_cap;
+ int ret = 0;
sa->sec_session = rte_security_session_create(ctx,
&sess_conf, ipsec_ctx->session_pool);
@@ -201,15 +202,67 @@ create_session(struct ipsec_ctx *ipsec_ctx, struct
ipsec_sa *sa)
sa->action[0].type = RTE_FLOW_ACTION_TYPE_SECURITY;
sa->action[0].conf = sa->sec_session;
- sa->action[1].type = RTE_FLOW_ACTION_TYPE_END;
-
sa->attr.egress = (sa->direction ==
RTE_SECURITY_IPSEC_SA_DIR_EGRESS);
sa->attr.ingress = (sa->direction ==
RTE_SECURITY_IPSEC_SA_DIR_INGRESS);
+ if (sa->attr.ingress) {
+ uint8_t rss_key[40];
+ struct rte_eth_rss_conf rss_conf = {
+ .rss_key = rss_key,
+ .rss_key_len = 40,
+ };
+ struct rte_eth_dev *eth_dev;
+ union {
+ struct rte_flow_action_rss rss;
+ struct {
+ const struct rte_eth_rss_conf *rss_conf;
+ uint16_t num;
+ uint16_t queue[RTE_MAX_QUEUES_PER_PORT];
+ } local;
+ } action_rss;
+ unsigned int i;
+ unsigned int j;
+
+ sa->action[2].type = RTE_FLOW_ACTION_TYPE_END;
+ /* Try RSS. */
+ sa->action[1].type = RTE_FLOW_ACTION_TYPE_RSS;
+ sa->action[1].conf = &action_rss;
+ eth_dev = ctx->device;
+ rte_eth_dev_rss_hash_conf_get(sa->portid,
+ &rss_conf);
+ for (i = 0, j = 0;
+i < eth_dev->data->nb_rx_queues; ++i)
+ if (eth_dev->data->rx_queues[i])
+ action_rss.local.queue[j++] = i;
+ action_rss.local.num = j;
+ action_rss.local.rss_conf = &rss_conf;
+ ret = rte_flow_validate(sa->portid, &sa->attr,
+ sa->pattern, sa->action,
+ &err);
+ if (!ret)
+ goto flow_create;
+ /* Try Queue. */
+ sa->action[1].type = RTE_FLOW_ACTION_TYPE_QUEUE;
+ sa->action[1].conf =
+ &(struct rte_flow_action_queue){
+ .index = 0,
+ };
+ ret = rte_flow_validate(sa->portid, &sa->attr,
+ sa->pattern, sa->action,
+ &err);
+
Re: [dpdk-dev] [PATCH v3 1/4] Introducing SPDX License Identifiers
On Wed, Dec 13, 2017 at 11:46:23AM +0100, Thomas Monjalon wrote: > Hi Hemant, > > Some comments below > > 08/12/2017 08:41, Hemant Agrawal: > > --- /dev/null > > +++ b/Licenses/Exceptions.txt > > Please use lowercase for file and directory. > By the way, the text is referring to exceptions.txt. > > > @@ -0,0 +1,12 @@ > > +This file will record any exceptions in DPDK Project with respect to DPDK > > +IP License policy as defined in DPDK Charter available at: > > + > > +http://dpdk.org/about/charter#ip > > This link might be indented. > > I think we should make clear that > - BSD-3-Clause > - GPL-2.0 > - dual BSD-3-Clause/GPL-2.0 > - dual BSD-3-Clause/LGPL-2.1 > are not exceptions. > > > +-- > > +License Name SPDX Identifier TB Approval Date GB > > Approval Date File name > > +-- > > The table is large, and file names will be long. > Can we remove "License Name" as it is redundant with SPDX id? > > > --- /dev/null > > +++ b/Licenses/README > > Good idea to add a README here. > > > @@ -0,0 +1,82 @@ > > +The DPDK uses the Open Source BSD-3-Clause license for the core libraries > > and > > +drivers. The kernel components are naturally GPLv2 licensed. > > You should use SPDX GPL-2.0 > > > +Including big blocks of License headers in all files blows up the > > +source code with mostly redundant information. An additional problem > > +is that even the same licenses are referred to by a number of > > +slightly varying text blocks (full, abbreviated, different > > +indentation, line wrapping and/or white space, with obsolete address > > +information, ...) which makes validation and automatic processing a > > nightmare. > > + > > +To make this easier, DPDK is adpoting the use of a single line reference to > > Please do not use this tense in the README. > We could say "DPDK uses" instead of "DPDK is adpoting the use". > > > +Unique License Identifiers in source files as defined by the Linux > > Foundation's > > +SPDX project [1]. > > My preference is to insert URLs inline to make reading flow easier. > > > +Adding license information in this fashion, rather than adding full license > > +text, can be more efficient for developers; decreases errors; and improves > > +automated detection of licenses. The current set of valid, predefined SPDX > > +identifiers is set forth on the SPDX License List[2] > > +at https://spdx.org/licenses/. > > Here you are mixing inline and reference :) > > > +For example, to label a file as subject to the BSD-3-Clause license, > > +the following text would be used: > > + > > +Copyright (C) [YEAR] NAME-OF-COPYRIGHT-HOLDER > > I think (C) is useless. It may be, I can't comment legally, but it is standard practice on all the current copyright lines inserted by the various contributing companies. > About the YEAR, we should explicit what it is. > I think it is only the first year, and we do not need to update > the last year of update. > We should also explicit why it is there and why it is not required > to add more copyrights. > The copyright is required to express who is allowed to declare the > license of the code. > It is a common practice to add a Copyright line when doing a big update. > I think it is fair, but for small changes, it is really not required > as we implicitly comply with the current copyright holder and license. > I'd be wary about starting to specify formats for the copyright lines, as such things are often specified in a particular format by those outside the actual development team. For now, let's just focus on the SPDX tags. /Bruce
Re: [dpdk-dev] [PATCH 1/7] event/octeontx: move eventdev octeontx test to driver
On Wed, Dec 13, 2017 at 04:54:29PM +0530, Pavan Nikhilesh Bhagavatula wrote: > On Wed, Dec 13, 2017 at 10:34:28AM +, Bruce Richardson wrote: > > On Wed, Dec 13, 2017 at 10:19:51AM +, Van Haaren, Harry wrote: > > > > -Original Message- > > > > From: Pavan Nikhilesh [mailto:pbhagavat...@caviumnetworks.com] > > > > Sent: Tuesday, December 12, 2017 7:27 PM > > > > To: jerin.ja...@caviumnetworks.com; Richardson, Bruce > > > > ; Van Haaren, Harry > > > > ; Eads, Gage ; > > > > hemant.agra...@nxp.com; nipun.gu...@nxp.com; Ma, Liang J > > > > > > > > Cc: dev@dpdk.org; Pavan Nikhilesh > > > > Subject: [dpdk-dev] [PATCH 1/7] event/octeontx: move eventdev octeontx > > > > test > > > > to driver > > > > > > > > Move octeontx eventdev specific test (test_eventdev_octeontx.c) to > > > > driver/event/octeontx. > > > > > > > > > > > > Replying to 1st patch, as no cover letter; > > > > > > Summary of patchset: > > > - Move tests for a specific Eventdev PMD into the PMD dir: > > > drivers/event/x/x_selftest.c > > > - Enable self tests to run when passed the vdev arg "self-test=1" > > > > > > > > > A few comments on this change; > > > > > > 1) We should not lose the capability to run tests as part of the existing > > > unit testing infrastructure. We should not fragment the testing tool - > > > requiring multiple binaries to test a single component. > > > > > > From discussion on #IRC, it seems reasonable to call rte_eal_vdev_init() > > > with "self-test=1" from the test/test/ code, and then we can continue to > > > use the existing test infrastructure despite that the actual tests are > > > now part of each PMD. > > > > > > 2) We should not copy/paste TEST_ASSERT macros into new test files. > > > Abstracting the TEST_ASSERT and other macros out to a header file would > > > solve this duplication. > > > > > > > > > Specific comments will be sent as replies to the patches. Cheers, -Harry > > > > What I gather from a cursory glance at this set is that the self tests > > are designed to be triggered via devargs to the device driver, correct? > > I'm not sure I like this approach, though I do agree with having the > > tests inside the individual drivers. > > > > What I think I would prefer to see is the self-tests being called via an > > API rather than via devargs. I think we should add a > > "rte_event_dev_self_test()" API to the eventdev library, and have that > > then call into the driver-provided tests. This means that self-tests can > > only be called by applications which are set up to allow the tests to be > > called, e.g. the autotest binary, while also avoiding the issue of > > having lots of driver specifics clutter up test binaries. > > Agreed, will modify it to ops based scheme so that application can call driver > specific `event_dev_self_test` and register selftest in > test/test/test_eventdev.c. > > Although we would like to retain devargs selftest scheme for event_octeontx. I > will remove it for event_sw. Does that sound good? > Sure, sounds good to me. Thanks, /Bruce
Re: [dpdk-dev] [PATCH 1/7] event/octeontx: move eventdev octeontx test to driver
On Wed, Dec 13, 2017 at 04:49:47PM +0530, Pavan Nikhilesh Bhagavatula wrote: > On Wed, Dec 13, 2017 at 10:19:51AM +, Van Haaren, Harry wrote: > > > -Original Message- > > > From: Pavan Nikhilesh [mailto:pbhagavat...@caviumnetworks.com] > > > Sent: Tuesday, December 12, 2017 7:27 PM > > > To: jerin.ja...@caviumnetworks.com; Richardson, Bruce > > > ; Van Haaren, Harry > > > ; Eads, Gage ; > > > hemant.agra...@nxp.com; nipun.gu...@nxp.com; Ma, Liang J > > > > > > Cc: dev@dpdk.org; Pavan Nikhilesh > > > Subject: [dpdk-dev] [PATCH 1/7] event/octeontx: move eventdev octeontx > > > test > > > to driver > > > > > > Move octeontx eventdev specific test (test_eventdev_octeontx.c) to > > > driver/event/octeontx. > > > > > > > > Replying to 1st patch, as no cover letter; > > > > Summary of patchset: > > - Move tests for a specific Eventdev PMD into the PMD dir: > > drivers/event/x/x_selftest.c > > - Enable self tests to run when passed the vdev arg "self-test=1" > > > > > > A few comments on this change; > > > > 1) We should not lose the capability to run tests as part of the existing > > unit testing infrastructure. We should not fragment the testing tool - > > requiring multiple binaries to test a single component. > > > > From discussion on #IRC, it seems reasonable to call rte_eal_vdev_init() > > with "self-test=1" from the test/test/ code, and then we can continue to > > use the existing test infrastructure despite that the actual tests are now > > part of each PMD. > > > > 2) We should not copy/paste TEST_ASSERT macros into new test files. > > Abstracting the TEST_ASSERT and other macros out to a header file would > > solve this duplication. > > > > I initially thought of abstracting the macros but couldnt find a suitable file > to place them in we have two options here, one is to use CFLAGS and include > test.h directly (dirty) or have rte_assert/test in eal/common/inlcude. > > Thoughts? > If other device types, e.g. ethdev or cryptodev, also take the approach of having a self_test API (something I think would be a good thing, and I actually hacked together when working on the i40e rx and tx code), I think we should look to have an rte_test.h header file for such macros to avoid duplication. At this point, moving them to an EAL include may not be worth it for just eventdev. /Bruce
Re: [dpdk-dev] [PATCH 1/5] pmdinfogen: fix cross compilation for ARM BE
Hi Neil/Bruce,
On 12/12/2017 12:28 AM, Neil Horman wrote:
On Mon, Dec 11, 2017 at 12:40:32PM +, Bruce Richardson wrote:
On Thu, Nov 02, 2017 at 03:38:51PM +0530, Hemant Agrawal wrote:
cross compiling DPDK for BE mode on ARM results into errors
"PMDINFO portal/dpaa2_hw_dpio.o.pmd.c No drivers registered"
Fixes: 98b0fdb0ffc6 ("pmdinfogen: add buildtools and pmdinfogen utility")
Cc: Neil Horman
Cc: sta...@dpdk.org
Signed-off-by: Jun Yang
Signed-off-by: Hemant Agrawal
---
buildtools/pmdinfogen/pmdinfogen.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comment could be a bit more specific about what the problem is and how
changing the hard-coded "32" fixes it.
Haven't tested the cross compilation part myself, but this causes no
errors for 32-bit or 64-bit builds on my system. So, with some more
detail on the specifics of the fix in the commit message:
Acked-by: Bruce Richardson
I'm with Bruce. I'd like to know exactly whats going on here. I dont have an
ARM system handy, so could you please post the errors that you are seeing here?
Is ADDR_SIZE not defined on BE for ARM or some such? That seems like it should
be fixed, rather than this change.
Neil
The original code hard codes the conversion for sh_size to 32, which is
incorrect.
The sh_size can be "Elf32_Wordsh_size" for 32 bit and "Elf64_Xword
sh_size" for 64 bit systems.
This causes the symtab_stop to have reduced size and thus find can fail.
info->symtab_stop = RTE_PTR_ADD(hdr, sechdrs[i].sh_offset +
sechdrs[i].sh_size);
we fixed it by replacing the hardcoded 32 with ADDR_SIZE is better.
I don't have access to Intel BE compiler, so could not check behavior
there. One of difference in my env is that I am doing cross compilation
on intel-x86-64 machine.
I used the following BE compiler
https://releases.linaro.org/components/toolchain/binaries/6.4-2017.11/aarch64_be-linux-gnu/gcc-linaro-6.4.1-2017.11-x86_64_aarch64_be-linux-gnu.tar.xz
diff --git a/buildtools/pmdinfogen/pmdinfogen.c
b/buildtools/pmdinfogen/pmdinfogen.c
index e73fc76..9119e52 100644
--- a/buildtools/pmdinfogen/pmdinfogen.c
+++ b/buildtools/pmdinfogen/pmdinfogen.c
@@ -181,7 +181,7 @@ static int parse_elf(struct elf_info *info, const char
*filename)
sechdrs[i].sh_offset=
TO_NATIVE(endian, ADDR_SIZE, sechdrs[i].sh_offset);
sechdrs[i].sh_size =
- TO_NATIVE(endian, 32, sechdrs[i].sh_size);
+ TO_NATIVE(endian, ADDR_SIZE, sechdrs[i].sh_size);
sechdrs[i].sh_link =
TO_NATIVE(endian, 32, sechdrs[i].sh_link);
sechdrs[i].sh_info =
--
2.7.4
Re: [dpdk-dev] [ovs-dev] [PATCH] netdev-dpdk: defer MTU set after interface start
> > The issue only arises with the qede PMD and 67fe6d635193
> > ("netdev-dpdk: use rte_eth_dev_set_mtu.")
>
> I had some more time to look at this today but this patch will break OVS DPDK
> for existing supported DPDK ports during testing.
>
> I tested with an XL710 and the MTU will fail to apply, the device must be
> stopped before configuration changes can be applied such as
> MTU. See log message below
>
> 2017-11-28T17:13:50Z|00086|dpdk|ERR|i40e_dev_mtu_set(): port 0 must be
> stopped before configuration
> 2017-11-28T17:13:50Z|00087|netdev_dpdk|ERR|Interface dpdk0 MTU (1500) setup
> error: Device or resource busy
>
> Did you come across it in your testing? I guess you didn’t see this for QEDE
> pmd. In my case the DPDK devices will simply fail to add to the
> bridge.
>
> As is, the patch would not be acceptable as its breaking existing
> functionality. It would have to be reworked to configure for device that
> cannot reconfigure when busy.
>
> Thanks
> Ian
I fully support the original decision to switch to using rte_dev_set_mtu() in
OVS. The prior approach setting max_rx_pkt_len in rte_eth_dev_configure() was
non-portable as that field has no well-defined semantics and its relation to
the MTU size is different for almost every PMD.
I had a look at the qede PMD implementation of rte_dev_set_mtu() in DPDK 17.05
and 17.11. It assumes that the device must be started because qede_set_mtu()
unconditionally stops the device before and restarts it after changing the MTU
value. Given that other PMDs like i40e don’t accept it after start, there is no
possible way OVS can use rte_dev_set_mtu() that will work with all drivers.
I think it is a weakness of the rte_ethdev API that it does not specify clearly
when API functions like rte_dev_set_mtu() may be called. From the documentation
of error -EBUSY one can guess that the intention was to optionally support it
when the device is started. Implicitly one could conclude that it MUST be
supported when the device stopped. That is logical and also what most PMDs do.
I would say the qede PMD should be fixed. It should accept the
rte_dev_set_mtu() at any time between rte_eth_dev_configure() and
rte_eth_dev_start() (and optionally also after start).
BR, Jan
[dpdk-dev] [PATCH 01/18] net/dpaa: fix coverity reported issues
Fixes: 05ba55bc2b1a ("net/dpaa: add packet dump for debugging")
Fixes: 37f9b54bd3cf ("net/dpaa: support Tx and Rx queue setup")
Cc: sta...@dpdk.org
Signed-off-by: Hemant Agrawal
---
drivers/net/dpaa/dpaa_ethdev.c | 6 +++---
drivers/net/dpaa/dpaa_rxtx.c | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/dpaa/dpaa_ethdev.c b/drivers/net/dpaa/dpaa_ethdev.c
index cf5a2ec..3023302 100644
--- a/drivers/net/dpaa/dpaa_ethdev.c
+++ b/drivers/net/dpaa/dpaa_ethdev.c
@@ -723,7 +723,7 @@ static int dpaa_fc_set_default(struct dpaa_if *dpaa_intf)
static int dpaa_rx_queue_init(struct qman_fq *fq,
uint32_t fqid)
{
- struct qm_mcc_initfq opts;
+ struct qm_mcc_initfq opts = {0};
int ret;
PMD_INIT_FUNC_TRACE();
@@ -769,7 +769,7 @@ static int dpaa_rx_queue_init(struct qman_fq *fq,
static int dpaa_tx_queue_init(struct qman_fq *fq,
struct fman_if *fman_intf)
{
- struct qm_mcc_initfq opts;
+ struct qm_mcc_initfq opts = {0};
int ret;
PMD_INIT_FUNC_TRACE();
@@ -800,7 +800,7 @@ static int dpaa_tx_queue_init(struct qman_fq *fq,
/* Initialise a DEBUG FQ ([rt]x_error, rx_default). */
static int dpaa_debug_queue_init(struct qman_fq *fq, uint32_t fqid)
{
- struct qm_mcc_initfq opts;
+ struct qm_mcc_initfq opts = {0};
int ret;
PMD_INIT_FUNC_TRACE();
diff --git a/drivers/net/dpaa/dpaa_rxtx.c b/drivers/net/dpaa/dpaa_rxtx.c
index 41e57f2..771e141 100644
--- a/drivers/net/dpaa/dpaa_rxtx.c
+++ b/drivers/net/dpaa/dpaa_rxtx.c
@@ -665,7 +665,7 @@ tx_on_external_pool(struct qman_fq *txq, struct rte_mbuf
*mbuf,
return 1;
}
- DPAA_MBUF_TO_CONTIG_FD(mbuf, fd_arr, dpaa_intf->bp_info->bpid);
+ DPAA_MBUF_TO_CONTIG_FD(dmable_mbuf, fd_arr, dpaa_intf->bp_info->bpid);
return 0;
}
--
2.7.4
[dpdk-dev] [PATCH 00/18] DPAA PMD improvements
This patch series add various improvement and performance related optimizations for DPAA PMD Ashish Jain (2): net/dpaa: fix the mbuf packet type if zero net/dpaa: set the correct frame size in device MTU Hemant Agrawal (11): net/dpaa: fix coverity reported issues net/dpaa: fix FW version code bus/dpaa: update platform soc value register routines net/dpaa: add frame count based tail drop with CGR bus/dpaa: add support to create dynamic HW portal bus/dpaa: query queue frame count support net/dpaa: add Rx queue count support net/dpaa: add support for loopback API app/testpmd: add support for loopback config for dpaa bus/dpaa: add support for static queues net/dpaa: integrate the support of push mode in PMD Nipun Gupta (5): bus/dpaa: optimize the qman HW stashing settings bus/dpaa: optimize the endianness conversions net/dpaa: change Tx HW budget to 7 net/dpaa: optimize the Tx burst net/dpaa: optimize Rx path app/test-pmd/Makefile | 4 + app/test-pmd/cmdline.c| 7 + doc/guides/nics/dpaa.rst | 11 ++ drivers/bus/dpaa/base/qbman/qman.c| 172 ++-- drivers/bus/dpaa/base/qbman/qman.h| 4 +- drivers/bus/dpaa/base/qbman/qman_driver.c | 153 +++--- drivers/bus/dpaa/base/qbman/qman_priv.h | 6 +- drivers/bus/dpaa/dpaa_bus.c | 43 - drivers/bus/dpaa/include/fsl_qman.h | 44 +++-- drivers/bus/dpaa/include/fsl_usd.h| 4 + drivers/bus/dpaa/include/process.h| 11 +- drivers/bus/dpaa/rte_bus_dpaa_version.map | 18 +++ drivers/bus/dpaa/rte_dpaa_bus.h | 15 ++ drivers/net/dpaa/Makefile | 3 + drivers/net/dpaa/dpaa_ethdev.c| 259 ++ drivers/net/dpaa/dpaa_ethdev.h| 21 ++- drivers/net/dpaa/dpaa_rxtx.c | 163 +-- drivers/net/dpaa/dpaa_rxtx.h | 7 +- drivers/net/dpaa/rte_pmd_dpaa.h | 37 + drivers/net/dpaa/rte_pmd_dpaa_version.map | 8 + 20 files changed, 837 insertions(+), 153 deletions(-) create mode 100644 drivers/net/dpaa/rte_pmd_dpaa.h -- 2.7.4
[dpdk-dev] [PATCH 03/18] net/dpaa: fix FW version code
fix the soc id path and missing fclose
Fixes: cf0fab1d2ca5 ("net/dpaa: support firmware version get API")
Cc: sta...@dpdk.org
Signed-off-by: Hemant Agrawal
---
drivers/net/dpaa/dpaa_ethdev.c | 14 +-
drivers/net/dpaa/dpaa_ethdev.h | 2 +-
2 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/net/dpaa/dpaa_ethdev.c b/drivers/net/dpaa/dpaa_ethdev.c
index 3023302..29678c5 100644
--- a/drivers/net/dpaa/dpaa_ethdev.c
+++ b/drivers/net/dpaa/dpaa_ethdev.c
@@ -212,19 +212,15 @@ dpaa_fw_version_get(struct rte_eth_dev *dev __rte_unused,
DPAA_PMD_ERR("Unable to open SoC device");
return -ENOTSUP; /* Not supported on this infra */
}
-
- ret = fscanf(svr_file, "svr:%x", &svr_ver);
- if (ret <= 0) {
+ if (fscanf(svr_file, "svr:%x", &svr_ver) <= 0)
DPAA_PMD_ERR("Unable to read SoC device");
- return -ENOTSUP; /* Not supported on this infra */
- }
- ret = snprintf(fw_version, fw_size,
- "svr:%x-fman-v%x",
- svr_ver,
- fman_ip_rev);
+ fclose(svr_file);
+ ret = snprintf(fw_version, fw_size, "SVR:%x-fman-v%x",
+ svr_ver, fman_ip_rev);
ret += 1; /* add the size of '\0' */
+
if (fw_size < (uint32_t)ret)
return ret;
else
diff --git a/drivers/net/dpaa/dpaa_ethdev.h b/drivers/net/dpaa/dpaa_ethdev.h
index 5457d61..ec5ae13 100644
--- a/drivers/net/dpaa/dpaa_ethdev.h
+++ b/drivers/net/dpaa/dpaa_ethdev.h
@@ -46,7 +46,7 @@
/* DPAA SoC identifier; If this is not available, it can be concluded
* that board is non-DPAA. Single slot is currently supported.
*/
-#define DPAA_SOC_ID_FILE "sys/devices/soc0/soc_id"
+#define DPAA_SOC_ID_FILE "/sys/devices/soc0/soc_id"
#define DPAA_MBUF_HW_ANNOTATION64
#define DPAA_FD_PTA_SIZE 64
--
2.7.4
[dpdk-dev] [PATCH 04/18] bus/dpaa: update platform soc value register routines
This patch update the logic and expose the soc value
register, so that it can be used by other modules as well.
Signed-off-by: Hemant Agrawal
---
drivers/bus/dpaa/dpaa_bus.c | 12
drivers/bus/dpaa/rte_bus_dpaa_version.map | 8
drivers/bus/dpaa/rte_dpaa_bus.h | 11 +++
drivers/net/dpaa/dpaa_ethdev.c| 4 +++-
drivers/net/dpaa/dpaa_ethdev.h| 5 -
5 files changed, 34 insertions(+), 6 deletions(-)
diff --git a/drivers/bus/dpaa/dpaa_bus.c b/drivers/bus/dpaa/dpaa_bus.c
index 1cc8c89..f1bc62a 100644
--- a/drivers/bus/dpaa/dpaa_bus.c
+++ b/drivers/bus/dpaa/dpaa_bus.c
@@ -77,6 +77,8 @@ struct netcfg_info *dpaa_netcfg;
/* define a variable to hold the portal_key, once created.*/
pthread_key_t dpaa_portal_key;
+unsigned int dpaa_svr_family;
+
RTE_DEFINE_PER_LCORE(bool, _dpaa_io);
static inline void
@@ -443,6 +445,8 @@ rte_dpaa_bus_probe(void)
int ret = -1;
struct rte_dpaa_device *dev;
struct rte_dpaa_driver *drv;
+ FILE *svr_file = NULL;
+ unsigned int svr_ver;
BUS_INIT_FUNC_TRACE();
@@ -462,6 +466,14 @@ rte_dpaa_bus_probe(void)
break;
}
}
+
+ svr_file = fopen(DPAA_SOC_ID_FILE, "r");
+ if (svr_file) {
+ if (fscanf(svr_file, "svr:%x", &svr_ver) > 0)
+ dpaa_svr_family = svr_ver & SVR_MASK;
+ fclose(svr_file);
+ }
+
return 0;
}
diff --git a/drivers/bus/dpaa/rte_bus_dpaa_version.map
b/drivers/bus/dpaa/rte_bus_dpaa_version.map
index fb9d532..eeeb458 100644
--- a/drivers/bus/dpaa/rte_bus_dpaa_version.map
+++ b/drivers/bus/dpaa/rte_bus_dpaa_version.map
@@ -64,3 +64,11 @@ DPDK_17.11 {
local: *;
};
+
+DPDK_18.02 {
+ global:
+
+ dpaa_svr_family;
+
+ local: *;
+} DPDK_17.11;
diff --git a/drivers/bus/dpaa/rte_dpaa_bus.h b/drivers/bus/dpaa/rte_dpaa_bus.h
index eafc944..40caf72 100644
--- a/drivers/bus/dpaa/rte_dpaa_bus.h
+++ b/drivers/bus/dpaa/rte_dpaa_bus.h
@@ -46,6 +46,17 @@
#define DEV_TO_DPAA_DEVICE(ptr)\
container_of(ptr, struct rte_dpaa_device, device)
+/* DPAA SoC identifier; If this is not available, it can be concluded
+ * that board is non-DPAA. Single slot is currently supported.
+ */
+#define DPAA_SOC_ID_FILE "/sys/devices/soc0/soc_id"
+
+#define SVR_LS1043A_FAMILY 0x8792
+#define SVR_LS1046A_FAMILY 0x8707
+#define SVR_MASK 0x
+
+extern unsigned int dpaa_svr_family;
+
struct rte_dpaa_device;
struct rte_dpaa_driver;
diff --git a/drivers/net/dpaa/dpaa_ethdev.c b/drivers/net/dpaa/dpaa_ethdev.c
index 29678c5..4ad9afc 100644
--- a/drivers/net/dpaa/dpaa_ethdev.c
+++ b/drivers/net/dpaa/dpaa_ethdev.c
@@ -212,7 +212,9 @@ dpaa_fw_version_get(struct rte_eth_dev *dev __rte_unused,
DPAA_PMD_ERR("Unable to open SoC device");
return -ENOTSUP; /* Not supported on this infra */
}
- if (fscanf(svr_file, "svr:%x", &svr_ver) <= 0)
+ if (fscanf(svr_file, "svr:%x", &svr_ver) > 0)
+ dpaa_svr_family = svr_ver & SVR_MASK;
+ else
DPAA_PMD_ERR("Unable to read SoC device");
fclose(svr_file);
diff --git a/drivers/net/dpaa/dpaa_ethdev.h b/drivers/net/dpaa/dpaa_ethdev.h
index ec5ae13..3f06d63 100644
--- a/drivers/net/dpaa/dpaa_ethdev.h
+++ b/drivers/net/dpaa/dpaa_ethdev.h
@@ -43,11 +43,6 @@
#include
#include
-/* DPAA SoC identifier; If this is not available, it can be concluded
- * that board is non-DPAA. Single slot is currently supported.
- */
-#define DPAA_SOC_ID_FILE "/sys/devices/soc0/soc_id"
-
#define DPAA_MBUF_HW_ANNOTATION64
#define DPAA_FD_PTA_SIZE 64
--
2.7.4
[dpdk-dev] [PATCH 05/18] net/dpaa: set the correct frame size in device MTU
From: Ashish Jain
Setting correct frame size in dpaa_dev_mtu_set
api call. Also setting correct max frame size in
hardware in dev_configure for jumbo frames
Signed-off-by: Ashish Jain
Acked-by: Hemant Agrawal
---
drivers/net/dpaa/dpaa_ethdev.c | 20 +---
drivers/net/dpaa/dpaa_ethdev.h | 4
2 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/net/dpaa/dpaa_ethdev.c b/drivers/net/dpaa/dpaa_ethdev.c
index 4ad9afc..adcc219 100644
--- a/drivers/net/dpaa/dpaa_ethdev.c
+++ b/drivers/net/dpaa/dpaa_ethdev.c
@@ -111,19 +111,21 @@ static int
dpaa_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
{
struct dpaa_if *dpaa_intf = dev->data->dev_private;
+ uint32_t frame_size = mtu + ETHER_HDR_LEN + ETHER_CRC_LEN
+ + VLAN_TAG_SIZE;
PMD_INIT_FUNC_TRACE();
- if (mtu < ETHER_MIN_MTU)
+ if ((mtu < ETHER_MIN_MTU) || (frame_size > DPAA_MAX_RX_PKT_LEN))
return -EINVAL;
- if (mtu > ETHER_MAX_LEN)
+ if (frame_size > ETHER_MAX_LEN)
dev->data->dev_conf.rxmode.jumbo_frame = 1;
else
dev->data->dev_conf.rxmode.jumbo_frame = 0;
- dev->data->dev_conf.rxmode.max_rx_pkt_len = mtu;
+ dev->data->dev_conf.rxmode.max_rx_pkt_len = frame_size;
- fman_if_set_maxfrm(dpaa_intf->fif, mtu);
+ fman_if_set_maxfrm(dpaa_intf->fif, frame_size);
return 0;
}
@@ -131,15 +133,19 @@ dpaa_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
static int
dpaa_eth_dev_configure(struct rte_eth_dev *dev __rte_unused)
{
+ struct dpaa_if *dpaa_intf = dev->data->dev_private;
+
PMD_INIT_FUNC_TRACE();
if (dev->data->dev_conf.rxmode.jumbo_frame == 1) {
if (dev->data->dev_conf.rxmode.max_rx_pkt_len <=
- DPAA_MAX_RX_PKT_LEN)
- return dpaa_mtu_set(dev,
+ DPAA_MAX_RX_PKT_LEN) {
+ fman_if_set_maxfrm(dpaa_intf->fif,
dev->data->dev_conf.rxmode.max_rx_pkt_len);
- else
+ return 0;
+ } else {
return -1;
+ }
}
return 0;
}
diff --git a/drivers/net/dpaa/dpaa_ethdev.h b/drivers/net/dpaa/dpaa_ethdev.h
index 3f06d63..ef726d3 100644
--- a/drivers/net/dpaa/dpaa_ethdev.h
+++ b/drivers/net/dpaa/dpaa_ethdev.h
@@ -71,6 +71,10 @@
/*Maximum number of slots available in TX ring*/
#define MAX_TX_RING_SLOTS 8
+#ifndef VLAN_TAG_SIZE
+#define VLAN_TAG_SIZE 4 /** < Vlan Header Length */
+#endif
+
/* PCD frame queues */
#define DPAA_PCD_FQID_START0x400
#define DPAA_PCD_FQID_MULTIPLIER 0x100
--
2.7.4
[dpdk-dev] [PATCH 02/18] net/dpaa: fix the mbuf packet type if zero
From: Ashish Jain
Populate the mbuf field packet_type which is required
for calculating checksum while transmitting frames
Fixes: 8cffdcbe85aa ("net/dpaa: support scattered Rx")
Cc: sta...@dpdk.org
Signed-off-by: Ashish Jain
Signed-off-by: Hemant Agrawal
---
drivers/net/dpaa/dpaa_rxtx.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/net/dpaa/dpaa_rxtx.c b/drivers/net/dpaa/dpaa_rxtx.c
index 771e141..c0cfec9 100644
--- a/drivers/net/dpaa/dpaa_rxtx.c
+++ b/drivers/net/dpaa/dpaa_rxtx.c
@@ -58,6 +58,7 @@
#include
#include
#include
+#include
#include "dpaa_ethdev.h"
#include "dpaa_rxtx.h"
@@ -504,6 +505,15 @@ dpaa_eth_mbuf_to_sg_fd(struct rte_mbuf *mbuf,
fd->opaque_addr = 0;
if (mbuf->ol_flags & DPAA_TX_CKSUM_OFFLOAD_MASK) {
+ if (!mbuf->packet_type) {
+ struct rte_net_hdr_lens hdr_lens;
+
+ mbuf->packet_type = rte_net_get_ptype(mbuf, &hdr_lens,
+ RTE_PTYPE_L2_MASK | RTE_PTYPE_L3_MASK
+ | RTE_PTYPE_L4_MASK);
+ mbuf->l2_len = hdr_lens.l2_len;
+ mbuf->l3_len = hdr_lens.l3_len;
+ }
if (temp->data_off < DEFAULT_TX_ICEOF
+ sizeof(struct dpaa_eth_parse_results_t))
temp->data_off = DEFAULT_TX_ICEOF
@@ -611,6 +621,15 @@ tx_on_dpaa_pool_unsegmented(struct rte_mbuf *mbuf,
}
if (mbuf->ol_flags & DPAA_TX_CKSUM_OFFLOAD_MASK) {
+ if (!mbuf->packet_type) {
+ struct rte_net_hdr_lens hdr_lens;
+
+ mbuf->packet_type = rte_net_get_ptype(mbuf, &hdr_lens,
+ RTE_PTYPE_L2_MASK | RTE_PTYPE_L3_MASK
+ | RTE_PTYPE_L4_MASK);
+ mbuf->l2_len = hdr_lens.l2_len;
+ mbuf->l3_len = hdr_lens.l3_len;
+ }
if (mbuf->data_off < (DEFAULT_TX_ICEOF +
sizeof(struct dpaa_eth_parse_results_t))) {
DPAA_DP_LOG(DEBUG, "Checksum offload Err: "
--
2.7.4
[dpdk-dev] [PATCH 06/18] net/dpaa: add frame count based tail drop with CGR
Replace the byte based tail queue congestion support
with frame count based congestion groups.
It can easily map to number of RX descriptors for a queue.
Signed-off-by: Hemant Agrawal
---
drivers/bus/dpaa/rte_bus_dpaa_version.map | 5 ++
drivers/net/dpaa/dpaa_ethdev.c| 98 +++
drivers/net/dpaa/dpaa_ethdev.h| 8 +--
3 files changed, 97 insertions(+), 14 deletions(-)
diff --git a/drivers/bus/dpaa/rte_bus_dpaa_version.map
b/drivers/bus/dpaa/rte_bus_dpaa_version.map
index eeeb458..f412362 100644
--- a/drivers/bus/dpaa/rte_bus_dpaa_version.map
+++ b/drivers/bus/dpaa/rte_bus_dpaa_version.map
@@ -69,6 +69,11 @@ DPDK_18.02 {
global:
dpaa_svr_family;
+ qman_alloc_cgrid_range;
+ qman_create_cgr;
+ qman_delete_cgr;
+ qman_modify_cgr;
+ qman_release_cgrid_range;
local: *;
} DPDK_17.11;
diff --git a/drivers/net/dpaa/dpaa_ethdev.c b/drivers/net/dpaa/dpaa_ethdev.c
index adcc219..6482998 100644
--- a/drivers/net/dpaa/dpaa_ethdev.c
+++ b/drivers/net/dpaa/dpaa_ethdev.c
@@ -73,6 +73,9 @@
/* Keep track of whether QMAN and BMAN have been globally initialized */
static int is_global_init;
+/* Per FQ Taildrop in frame count */
+static unsigned int td_threshold = CGR_RX_PERFQ_THRESH;
+
struct rte_dpaa_xstats_name_off {
char name[RTE_ETH_XSTATS_NAME_SIZE];
uint32_t offset;
@@ -447,12 +450,13 @@ static void dpaa_eth_multicast_disable(struct rte_eth_dev
*dev)
static
int dpaa_eth_rx_queue_setup(struct rte_eth_dev *dev, uint16_t queue_idx,
- uint16_t nb_desc __rte_unused,
+ uint16_t nb_desc,
unsigned int socket_id __rte_unused,
const struct rte_eth_rxconf *rx_conf __rte_unused,
struct rte_mempool *mp)
{
struct dpaa_if *dpaa_intf = dev->data->dev_private;
+ struct qman_fq *rxq = &dpaa_intf->rx_queues[queue_idx];
PMD_INIT_FUNC_TRACE();
@@ -488,7 +492,23 @@ int dpaa_eth_rx_queue_setup(struct rte_eth_dev *dev,
uint16_t queue_idx,
dpaa_intf->name, fd_offset,
fman_if_get_fdoff(dpaa_intf->fif));
}
- dev->data->rx_queues[queue_idx] = &dpaa_intf->rx_queues[queue_idx];
+
+ dev->data->rx_queues[queue_idx] = rxq;
+
+ /* configure the CGR size as per the desc size */
+ if (dpaa_intf->cgr_rx) {
+ struct qm_mcc_initcgr cgr_opts = {0};
+ int ret;
+
+ /* Enable tail drop with cgr on this queue */
+ qm_cgr_cs_thres_set64(&cgr_opts.cgr.cs_thres, nb_desc, 0);
+ ret = qman_modify_cgr(dpaa_intf->cgr_rx, 0, &cgr_opts);
+ if (ret) {
+ DPAA_PMD_WARN(
+ "rx taildrop modify fail on fqid %d (ret=%d)",
+ rxq->fqid, ret);
+ }
+ }
return 0;
}
@@ -724,11 +744,21 @@ static int dpaa_fc_set_default(struct dpaa_if *dpaa_intf)
}
/* Initialise an Rx FQ */
-static int dpaa_rx_queue_init(struct qman_fq *fq,
+static int dpaa_rx_queue_init(struct qman_fq *fq, struct qman_cgr *cgr_rx,
uint32_t fqid)
{
struct qm_mcc_initfq opts = {0};
int ret;
+ u32 flags = 0;
+ struct qm_mcc_initcgr cgr_opts = {
+ .we_mask = QM_CGR_WE_CS_THRES |
+ QM_CGR_WE_CSTD_EN |
+ QM_CGR_WE_MODE,
+ .cgr = {
+ .cstd_en = QM_CGR_EN,
+ .mode = QMAN_CGR_MODE_FRAME
+ }
+ };
PMD_INIT_FUNC_TRACE();
@@ -758,12 +788,24 @@ static int dpaa_rx_queue_init(struct qman_fq *fq,
opts.fqd.context_a.stashing.data_cl = DPAA_IF_RX_DATA_STASH;
opts.fqd.context_a.stashing.context_cl = DPAA_IF_RX_CONTEXT_STASH;
- /*Enable tail drop */
- opts.we_mask = opts.we_mask | QM_INITFQ_WE_TDTHRESH;
- opts.fqd.fq_ctrl = opts.fqd.fq_ctrl | QM_FQCTRL_TDE;
- qm_fqd_taildrop_set(&opts.fqd.td, CONG_THRESHOLD_RX_Q, 1);
-
- ret = qman_init_fq(fq, 0, &opts);
+ if (cgr_rx) {
+ /* Enable tail drop with cgr on this queue */
+ qm_cgr_cs_thres_set64(&cgr_opts.cgr.cs_thres, td_threshold, 0);
+ cgr_rx->cb = NULL;
+ ret = qman_create_cgr(cgr_rx, QMAN_CGR_FLAG_USE_INIT,
+ &cgr_opts);
+ if (ret) {
+ DPAA_PMD_WARN(
+ "rx taildrop init fail on rx fqid %d (ret=%d)",
+ fqid, ret);
+ goto without_cgr;
+ }
+ opts.we_mask |= QM_INITFQ_WE_CGID;
+ opts.fqd.cgid = cgr_rx->cgrid;
+ opts.fqd.fq_ctrl |= QM_FQCTRL_CGE;
+ }
+without_cgr:
+ ret =
[dpdk-dev] [PATCH 09/18] bus/dpaa: add support to create dynamic HW portal
HW portal is a processing context in DPAA. This patch allow
creation of a queue specific HW portal context.
Signed-off-by: Hemant Agrawal
---
drivers/bus/dpaa/base/qbman/qman.c| 69 --
drivers/bus/dpaa/base/qbman/qman_driver.c | 153 +-
drivers/bus/dpaa/base/qbman/qman_priv.h | 6 +-
drivers/bus/dpaa/dpaa_bus.c | 31 +-
drivers/bus/dpaa/include/fsl_qman.h | 25 ++---
drivers/bus/dpaa/include/fsl_usd.h| 4 +
drivers/bus/dpaa/include/process.h| 11 ++-
drivers/bus/dpaa/rte_bus_dpaa_version.map | 2 +
drivers/bus/dpaa/rte_dpaa_bus.h | 4 +
9 files changed, 252 insertions(+), 53 deletions(-)
diff --git a/drivers/bus/dpaa/base/qbman/qman.c
b/drivers/bus/dpaa/base/qbman/qman.c
index 400d920..6ae4bb3 100644
--- a/drivers/bus/dpaa/base/qbman/qman.c
+++ b/drivers/bus/dpaa/base/qbman/qman.c
@@ -650,11 +650,52 @@ struct qman_portal *qman_create_portal(
return NULL;
}
+#define MAX_GLOBAL_PORTLAS 8
+static struct qman_portal global_portals[MAX_GLOBAL_PORTLAS];
+static int global_portals_used[MAX_GLOBAL_PORTLAS];
+
+static struct qman_portal *
+qman_alloc_global_portal(void)
+{
+ unsigned int i;
+
+ for (i = 0; i < MAX_GLOBAL_PORTLAS; i++) {
+ if (global_portals_used[i] == 0) {
+ global_portals_used[i] = 1;
+ return &global_portals[i];
+ }
+ }
+ pr_err("No portal available (%x)\n", MAX_GLOBAL_PORTLAS);
+
+ return NULL;
+}
+
+static int
+qman_free_global_portal(struct qman_portal *portal)
+{
+ unsigned int i;
+
+ for (i = 0; i < MAX_GLOBAL_PORTLAS; i++) {
+ if (&global_portals[i] == portal) {
+ global_portals_used[i] = 0;
+ return 0;
+ }
+ }
+ return -1;
+}
+
struct qman_portal *qman_create_affine_portal(const struct qm_portal_config *c,
- const struct qman_cgrs *cgrs)
+ const struct qman_cgrs *cgrs,
+ int alloc)
{
struct qman_portal *res;
- struct qman_portal *portal = get_affine_portal();
+ struct qman_portal *portal;
+
+ if (alloc)
+ portal = qman_alloc_global_portal();
+ else
+ portal = get_affine_portal();
+
/* A criteria for calling this function (from qman_driver.c) is that
* we're already affine to the cpu and won't schedule onto another cpu.
*/
@@ -704,13 +745,18 @@ void qman_destroy_portal(struct qman_portal *qm)
spin_lock_destroy(&qm->cgr_lock);
}
-const struct qm_portal_config *qman_destroy_affine_portal(void)
+const struct qm_portal_config *
+qman_destroy_affine_portal(struct qman_portal *qp)
{
/* We don't want to redirect if we're a slave, use "raw" */
- struct qman_portal *qm = get_affine_portal();
+ struct qman_portal *qm;
const struct qm_portal_config *pcfg;
int cpu;
+ if (qp == NULL)
+ qm = get_affine_portal();
+ else
+ qm = qp;
pcfg = qm->config;
cpu = pcfg->cpu;
@@ -719,6 +765,9 @@ const struct qm_portal_config
*qman_destroy_affine_portal(void)
spin_lock(&affine_mask_lock);
CPU_CLR(cpu, &affine_mask);
spin_unlock(&affine_mask_lock);
+
+ qman_free_global_portal(qm);
+
return pcfg;
}
@@ -1125,27 +1174,27 @@ void qman_start_dequeues(void)
qm_dqrr_set_maxfill(&p->p, DQRR_MAXFILL);
}
-void qman_static_dequeue_add(u32 pools)
+void qman_static_dequeue_add(u32 pools, struct qman_portal *qp)
{
- struct qman_portal *p = get_affine_portal();
+ struct qman_portal *p = qp ? qp : get_affine_portal();
pools &= p->config->pools;
p->sdqcr |= pools;
qm_dqrr_sdqcr_set(&p->p, p->sdqcr);
}
-void qman_static_dequeue_del(u32 pools)
+void qman_static_dequeue_del(u32 pools, struct qman_portal *qp)
{
- struct qman_portal *p = get_affine_portal();
+ struct qman_portal *p = qp ? qp : get_affine_portal();
pools &= p->config->pools;
p->sdqcr &= ~pools;
qm_dqrr_sdqcr_set(&p->p, p->sdqcr);
}
-u32 qman_static_dequeue_get(void)
+u32 qman_static_dequeue_get(struct qman_portal *qp)
{
- struct qman_portal *p = get_affine_portal();
+ struct qman_portal *p = qp ? qp : get_affine_portal();
return p->sdqcr;
}
diff --git a/drivers/bus/dpaa/base/qbman/qman_driver.c
b/drivers/bus/dpaa/base/qbman/qman_driver.c
index 7a68896..f5d4b37 100644
--- a/drivers/bus/dpaa/base/qbman/qman_driver.c
+++ b/drivers/bus/dpaa/base/qbman/qman_driver.c
@@ -57,8 +57,8 @@ void *qman_ccsr_map;
/* The qman clock frequency */
u32 qman_clk;
-static __thread int fd = -1;
-static __thread struct qm_portal_config pcfg;
+static __thread int qmfd = -1;
+static __
[dpdk-dev] [PATCH 08/18] bus/dpaa: optimize the endianness conversions
From: Nipun Gupta
Signed-off-by: Nipun Gupta
Acked-by: Hemant Agrawal
---
drivers/bus/dpaa/base/qbman/qman.c | 7 ---
drivers/bus/dpaa/include/fsl_qman.h | 2 ++
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/bus/dpaa/base/qbman/qman.c
b/drivers/bus/dpaa/base/qbman/qman.c
index 77e4eeb..400d920 100644
--- a/drivers/bus/dpaa/base/qbman/qman.c
+++ b/drivers/bus/dpaa/base/qbman/qman.c
@@ -935,7 +935,7 @@ static inline unsigned int __poll_portal_fast(struct
qman_portal *p,
do {
qm_dqrr_pvb_update(&p->p);
dq = qm_dqrr_current(&p->p);
- if (!dq)
+ if (unlikely(!dq))
break;
#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
/* If running on an LE system the fields of the
@@ -1194,6 +1194,7 @@ int qman_create_fq(u32 fqid, u32 flags, struct qman_fq
*fq)
}
spin_lock_init(&fq->fqlock);
fq->fqid = fqid;
+ fq->fqid_le = cpu_to_be32(fqid);
fq->flags = flags;
fq->state = qman_fq_state_oos;
fq->cgr_groupid = 0;
@@ -1981,7 +1982,7 @@ int qman_enqueue(struct qman_fq *fq, const struct qm_fd
*fd, u32 flags)
int qman_enqueue_multi(struct qman_fq *fq,
const struct qm_fd *fd,
- int frames_to_send)
+ int frames_to_send)
{
struct qman_portal *p = get_affine_portal();
struct qm_portal *portal = &p->p;
@@ -2003,7 +2004,7 @@ int qman_enqueue_multi(struct qman_fq *fq,
/* try to send as many frames as possible */
while (eqcr->available && frames_to_send--) {
- eq->fqid = cpu_to_be32(fq->fqid);
+ eq->fqid = fq->fqid_le;
#ifdef CONFIG_FSL_QMAN_FQ_LOOKUP
eq->tag = cpu_to_be32(fq->key);
#else
diff --git a/drivers/bus/dpaa/include/fsl_qman.h
b/drivers/bus/dpaa/include/fsl_qman.h
index eedfd7e..ebcfa43 100644
--- a/drivers/bus/dpaa/include/fsl_qman.h
+++ b/drivers/bus/dpaa/include/fsl_qman.h
@@ -1230,6 +1230,8 @@ struct qman_fq {
*/
spinlock_t fqlock;
u32 fqid;
+ u32 fqid_le;
+
/* DPDK Interface */
void *dpaa_intf;
--
2.7.4
[dpdk-dev] [PATCH 07/18] bus/dpaa: optimize the qman HW stashing settings
From: Nipun Gupta
The settings are tuned for performance.
Signed-off-by: Nipun Gupta
Acked-by: Hemant Agrawal
---
drivers/bus/dpaa/base/qbman/qman.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/bus/dpaa/base/qbman/qman.c
b/drivers/bus/dpaa/base/qbman/qman.c
index 87fec60..77e4eeb 100644
--- a/drivers/bus/dpaa/base/qbman/qman.c
+++ b/drivers/bus/dpaa/base/qbman/qman.c
@@ -40,6 +40,7 @@
#include "qman.h"
#include
+#include
/* Compilation constants */
#define DQRR_MAXFILL 15
@@ -532,7 +533,12 @@ struct qman_portal *qman_create_portal(
p = &portal->p;
- portal->use_eqcr_ci_stashing = ((qman_ip_rev >= QMAN_REV30) ? 1 : 0);
+ if (dpaa_svr_family == SVR_LS1043A_FAMILY)
+ portal->use_eqcr_ci_stashing = 3;
+ else
+ portal->use_eqcr_ci_stashing =
+ ((qman_ip_rev >= QMAN_REV30) ? 1 : 0);
+
/*
* prep the low-level portal struct with the mapped addresses from the
* config, everything that follows depends on it and "config" is more
@@ -545,7 +551,7 @@ struct qman_portal *qman_create_portal(
* and stash with high-than-DQRR priority.
*/
if (qm_eqcr_init(p, qm_eqcr_pvb,
-portal->use_eqcr_ci_stashing ? 3 : 0, 1)) {
+portal->use_eqcr_ci_stashing, 1)) {
pr_err("Qman EQCR initialisation failed\n");
goto fail_eqcr;
}
--
2.7.4
[dpdk-dev] [PATCH 10/18] net/dpaa: change Tx HW budget to 7
From: Nipun Gupta
change the TX budget to 7 to sync best with the hw.
Signed-off-by: Nipun Gupta
Acked-by: Hemant Agrawal
---
drivers/net/dpaa/dpaa_ethdev.h | 2 +-
drivers/net/dpaa/dpaa_rxtx.c | 5 +++--
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/dpaa/dpaa_ethdev.h b/drivers/net/dpaa/dpaa_ethdev.h
index b26e411..95d745e 100644
--- a/drivers/net/dpaa/dpaa_ethdev.h
+++ b/drivers/net/dpaa/dpaa_ethdev.h
@@ -67,7 +67,7 @@
#define DPAA_MAX_MAC_FILTER (MEMAC_NUM_OF_PADDRS + 1)
/*Maximum number of slots available in TX ring*/
-#define MAX_TX_RING_SLOTS 8
+#define DPAA_TX_BURST_SIZE 7
#ifndef VLAN_TAG_SIZE
#define VLAN_TAG_SIZE 4 /** < Vlan Header Length */
diff --git a/drivers/net/dpaa/dpaa_rxtx.c b/drivers/net/dpaa/dpaa_rxtx.c
index c0cfec9..1b0ca9a 100644
--- a/drivers/net/dpaa/dpaa_rxtx.c
+++ b/drivers/net/dpaa/dpaa_rxtx.c
@@ -695,7 +695,7 @@ dpaa_eth_queue_tx(void *q, struct rte_mbuf **bufs, uint16_t
nb_bufs)
struct rte_mbuf *mbuf, *mi = NULL;
struct rte_mempool *mp;
struct dpaa_bp_info *bp_info;
- struct qm_fd fd_arr[MAX_TX_RING_SLOTS];
+ struct qm_fd fd_arr[DPAA_TX_BURST_SIZE];
uint32_t frames_to_send, loop, i = 0;
uint16_t state;
int ret;
@@ -709,7 +709,8 @@ dpaa_eth_queue_tx(void *q, struct rte_mbuf **bufs, uint16_t
nb_bufs)
DPAA_DP_LOG(DEBUG, "Transmitting %d buffers on queue: %p", nb_bufs, q);
while (nb_bufs) {
- frames_to_send = (nb_bufs >> 3) ? MAX_TX_RING_SLOTS : nb_bufs;
+ frames_to_send = (nb_bufs > DPAA_TX_BURST_SIZE) ?
+ DPAA_TX_BURST_SIZE : nb_bufs;
for (loop = 0; loop < frames_to_send; loop++, i++) {
mbuf = bufs[i];
if (RTE_MBUF_DIRECT(mbuf)) {
--
2.7.4
[dpdk-dev] [PATCH 11/18] net/dpaa: optimize the Tx burst
From: Nipun Gupta
Optimize it for best case. Create a function
for TX offloads to be used in multiple legs.
Signed-off-by: Nipun Gupta
Acked-by: Hemant Agrawal
---
drivers/net/dpaa/dpaa_rxtx.c | 73
1 file changed, 46 insertions(+), 27 deletions(-)
diff --git a/drivers/net/dpaa/dpaa_rxtx.c b/drivers/net/dpaa/dpaa_rxtx.c
index 1b0ca9a..33cc412 100644
--- a/drivers/net/dpaa/dpaa_rxtx.c
+++ b/drivers/net/dpaa/dpaa_rxtx.c
@@ -298,6 +298,30 @@ static inline void dpaa_checksum_offload(struct rte_mbuf
*mbuf,
fd->cmd = DPAA_FD_CMD_RPD | DPAA_FD_CMD_DTC;
}
+static inline void
+dpaa_unsegmented_checksum(struct rte_mbuf *mbuf, struct qm_fd *fd_arr)
+{
+ if (!mbuf->packet_type) {
+ struct rte_net_hdr_lens hdr_lens;
+
+ mbuf->packet_type = rte_net_get_ptype(mbuf, &hdr_lens,
+ RTE_PTYPE_L2_MASK | RTE_PTYPE_L3_MASK
+ | RTE_PTYPE_L4_MASK);
+ mbuf->l2_len = hdr_lens.l2_len;
+ mbuf->l3_len = hdr_lens.l3_len;
+ }
+ if (mbuf->data_off < (DEFAULT_TX_ICEOF +
+ sizeof(struct dpaa_eth_parse_results_t))) {
+ DPAA_DP_LOG(DEBUG, "Checksum offload Err: "
+ "Not enough Headroom "
+ "space for correct Checksum offload."
+ "So Calculating checksum in Software.");
+ dpaa_checksum(mbuf);
+ } else {
+ dpaa_checksum_offload(mbuf, fd_arr, mbuf->buf_addr);
+ }
+}
+
struct rte_mbuf *
dpaa_eth_sg_to_mbuf(struct qm_fd *fd, uint32_t ifid)
{
@@ -620,27 +644,8 @@ tx_on_dpaa_pool_unsegmented(struct rte_mbuf *mbuf,
rte_pktmbuf_free(mbuf);
}
- if (mbuf->ol_flags & DPAA_TX_CKSUM_OFFLOAD_MASK) {
- if (!mbuf->packet_type) {
- struct rte_net_hdr_lens hdr_lens;
-
- mbuf->packet_type = rte_net_get_ptype(mbuf, &hdr_lens,
- RTE_PTYPE_L2_MASK | RTE_PTYPE_L3_MASK
- | RTE_PTYPE_L4_MASK);
- mbuf->l2_len = hdr_lens.l2_len;
- mbuf->l3_len = hdr_lens.l3_len;
- }
- if (mbuf->data_off < (DEFAULT_TX_ICEOF +
- sizeof(struct dpaa_eth_parse_results_t))) {
- DPAA_DP_LOG(DEBUG, "Checksum offload Err: "
- "Not enough Headroom "
- "space for correct Checksum offload."
- "So Calculating checksum in Software.");
- dpaa_checksum(mbuf);
- } else {
- dpaa_checksum_offload(mbuf, fd_arr, mbuf->buf_addr);
- }
- }
+ if (mbuf->ol_flags & DPAA_TX_CKSUM_OFFLOAD_MASK)
+ dpaa_unsegmented_checksum(mbuf, fd_arr);
}
/* Handle all mbufs on dpaa BMAN managed pool */
@@ -696,7 +701,7 @@ dpaa_eth_queue_tx(void *q, struct rte_mbuf **bufs, uint16_t
nb_bufs)
struct rte_mempool *mp;
struct dpaa_bp_info *bp_info;
struct qm_fd fd_arr[DPAA_TX_BURST_SIZE];
- uint32_t frames_to_send, loop, i = 0;
+ uint32_t frames_to_send, loop, sent = 0;
uint16_t state;
int ret;
@@ -711,10 +716,23 @@ dpaa_eth_queue_tx(void *q, struct rte_mbuf **bufs,
uint16_t nb_bufs)
while (nb_bufs) {
frames_to_send = (nb_bufs > DPAA_TX_BURST_SIZE) ?
DPAA_TX_BURST_SIZE : nb_bufs;
- for (loop = 0; loop < frames_to_send; loop++, i++) {
- mbuf = bufs[i];
- if (RTE_MBUF_DIRECT(mbuf)) {
+ for (loop = 0; loop < frames_to_send; loop++) {
+ mbuf = *(bufs++);
+ if (likely(RTE_MBUF_DIRECT(mbuf))) {
mp = mbuf->pool;
+ bp_info = DPAA_MEMPOOL_TO_POOL_INFO(mp);
+ if (likely(mp->ops_index ==
+ bp_info->dpaa_ops_index &&
+ mbuf->nb_segs == 1 &&
+ rte_mbuf_refcnt_read(mbuf) == 1)) {
+ DPAA_MBUF_TO_CONTIG_FD(mbuf,
+ &fd_arr[loop], bp_info->bpid);
+ if (mbuf->ol_flags &
+ DPAA_TX_CKSUM_OFFLOAD_MASK)
+ dpaa_unsegmented_checksum(mbuf,
+ &fd_arr[loop]);
+ continue;
+ }
} else {
mi = rte_mbuf_from_indirect(mbuf);
mp = mi->po
[dpdk-dev] [PATCH 14/18] net/dpaa: add Rx queue count support
Signed-off-by: Hemant Agrawal
---
drivers/net/dpaa/dpaa_ethdev.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/net/dpaa/dpaa_ethdev.c b/drivers/net/dpaa/dpaa_ethdev.c
index 6482998..53b8c87 100644
--- a/drivers/net/dpaa/dpaa_ethdev.c
+++ b/drivers/net/dpaa/dpaa_ethdev.c
@@ -539,6 +539,22 @@ static void dpaa_eth_tx_queue_release(void *txq
__rte_unused)
PMD_INIT_FUNC_TRACE();
}
+static uint32_t
+dpaa_dev_rx_queue_count(struct rte_eth_dev *dev, uint16_t rx_queue_id)
+{
+ struct dpaa_if *dpaa_intf = dev->data->dev_private;
+ struct qman_fq *rxq = &dpaa_intf->rx_queues[rx_queue_id];
+ u32 frm_cnt = 0;
+
+ PMD_INIT_FUNC_TRACE();
+
+ if (qman_query_fq_frm_cnt(rxq, &frm_cnt) == 0) {
+ RTE_LOG(DEBUG, PMD, "RX frame count for q(%d) is %u\n",
+ rx_queue_id, frm_cnt);
+ }
+ return frm_cnt;
+}
+
static int dpaa_link_down(struct rte_eth_dev *dev)
{
PMD_INIT_FUNC_TRACE();
@@ -690,6 +706,7 @@ static struct eth_dev_ops dpaa_devops = {
.tx_queue_setup = dpaa_eth_tx_queue_setup,
.rx_queue_release = dpaa_eth_rx_queue_release,
.tx_queue_release = dpaa_eth_tx_queue_release,
+ .rx_queue_count = dpaa_dev_rx_queue_count,
.flow_ctrl_get= dpaa_flow_ctrl_get,
.flow_ctrl_set= dpaa_flow_ctrl_set,
--
2.7.4
[dpdk-dev] [PATCH 12/18] net/dpaa: optimize Rx path
From: Nipun Gupta
Signed-off-by: Nipun Gupta
Signed-off-by: Hemant Agrawal
---
drivers/net/dpaa/dpaa_rxtx.c | 48
drivers/net/dpaa/dpaa_rxtx.h | 2 +-
2 files changed, 23 insertions(+), 27 deletions(-)
diff --git a/drivers/net/dpaa/dpaa_rxtx.c b/drivers/net/dpaa/dpaa_rxtx.c
index 33cc412..2609953 100644
--- a/drivers/net/dpaa/dpaa_rxtx.c
+++ b/drivers/net/dpaa/dpaa_rxtx.c
@@ -123,12 +123,6 @@ static inline void dpaa_eth_packet_info(struct rte_mbuf *m,
DPAA_DP_LOG(DEBUG, " Parsing mbuf: %p with annotations: %p", m, annot);
switch (prs) {
- case DPAA_PKT_TYPE_NONE:
- m->packet_type = 0;
- break;
- case DPAA_PKT_TYPE_ETHER:
- m->packet_type = RTE_PTYPE_L2_ETHER;
- break;
case DPAA_PKT_TYPE_IPV4:
m->packet_type = RTE_PTYPE_L2_ETHER |
RTE_PTYPE_L3_IPV4;
@@ -137,6 +131,9 @@ static inline void dpaa_eth_packet_info(struct rte_mbuf *m,
m->packet_type = RTE_PTYPE_L2_ETHER |
RTE_PTYPE_L3_IPV6;
break;
+ case DPAA_PKT_TYPE_ETHER:
+ m->packet_type = RTE_PTYPE_L2_ETHER;
+ break;
case DPAA_PKT_TYPE_IPV4_FRAG:
case DPAA_PKT_TYPE_IPV4_FRAG_UDP:
case DPAA_PKT_TYPE_IPV4_FRAG_TCP:
@@ -199,6 +196,9 @@ static inline void dpaa_eth_packet_info(struct rte_mbuf *m,
m->packet_type = RTE_PTYPE_L2_ETHER |
RTE_PTYPE_L3_IPV6 | RTE_PTYPE_L4_SCTP;
break;
+ case DPAA_PKT_TYPE_NONE:
+ m->packet_type = 0;
+ break;
/* More switch cases can be added */
default:
dpaa_slow_parsing(m, prs);
@@ -209,12 +209,11 @@ static inline void dpaa_eth_packet_info(struct rte_mbuf
*m,
<< DPAA_PKT_L3_LEN_SHIFT;
/* Set the hash values */
- m->hash.rss = (uint32_t)(rte_be_to_cpu_64(annot->hash));
- m->ol_flags = PKT_RX_RSS_HASH;
+ m->hash.rss = (uint32_t)(annot->hash);
/* All packets with Bad checksum are dropped by interface (and
* corresponding notification issued to RX error queues).
*/
- m->ol_flags |= PKT_RX_IP_CKSUM_GOOD;
+ m->ol_flags = PKT_RX_RSS_HASH | PKT_RX_IP_CKSUM_GOOD;
/* Check if Vlan is present */
if (prs & DPAA_PARSE_VLAN_MASK)
@@ -323,7 +322,7 @@ dpaa_unsegmented_checksum(struct rte_mbuf *mbuf, struct
qm_fd *fd_arr)
}
struct rte_mbuf *
-dpaa_eth_sg_to_mbuf(struct qm_fd *fd, uint32_t ifid)
+dpaa_eth_sg_to_mbuf(const struct qm_fd *fd, uint32_t ifid)
{
struct dpaa_bp_info *bp_info = DPAA_BPID_TO_POOL_INFO(fd->bpid);
struct rte_mbuf *first_seg, *prev_seg, *cur_seg, *temp;
@@ -381,34 +380,31 @@ dpaa_eth_sg_to_mbuf(struct qm_fd *fd, uint32_t ifid)
return first_seg;
}
-static inline struct rte_mbuf *dpaa_eth_fd_to_mbuf(struct qm_fd *fd,
- uint32_t ifid)
+static inline struct rte_mbuf *
+dpaa_eth_fd_to_mbuf(const struct qm_fd *fd, uint32_t ifid)
{
- struct dpaa_bp_info *bp_info = DPAA_BPID_TO_POOL_INFO(fd->bpid);
struct rte_mbuf *mbuf;
- void *ptr;
+ struct dpaa_bp_info *bp_info = DPAA_BPID_TO_POOL_INFO(fd->bpid);
+ void *ptr = rte_dpaa_mem_ptov(qm_fd_addr(fd));
uint8_t format =
(fd->opaque & DPAA_FD_FORMAT_MASK) >> DPAA_FD_FORMAT_SHIFT;
- uint16_t offset =
- (fd->opaque & DPAA_FD_OFFSET_MASK) >> DPAA_FD_OFFSET_SHIFT;
- uint32_t length = fd->opaque & DPAA_FD_LENGTH_MASK;
+ uint16_t offset;
+ uint32_t length;
DPAA_DP_LOG(DEBUG, " FD--->MBUF");
if (unlikely(format == qm_fd_sg))
return dpaa_eth_sg_to_mbuf(fd, ifid);
+ rte_prefetch0((void *)((uint8_t *)ptr + DEFAULT_RX_ICEOF));
+
+ offset = (fd->opaque & DPAA_FD_OFFSET_MASK) >> DPAA_FD_OFFSET_SHIFT;
+ length = fd->opaque & DPAA_FD_LENGTH_MASK;
+
/* Ignoring case when format != qm_fd_contig */
dpaa_display_frame(fd);
- ptr = rte_dpaa_mem_ptov(fd->addr);
- /* Ignoring case when ptr would be NULL. That is only possible incase
-* of a corrupted packet
-*/
mbuf = (struct rte_mbuf *)((char *)ptr - bp_info->meta_data_size);
- /* Prefetch the Parse results and packet data to L1 */
- rte_prefetch0((void *)((uint8_t *)ptr + DEFAULT_RX_ICEOF));
- rte_prefetch0((void *)((uint8_t *)ptr + offset));
mbuf->data_off = offset;
mbuf->data_len = length;
@@ -488,11 +484,11 @@ static struct rte_mbuf *dpaa_get_dmable_mbuf(struct
rte_mbuf *mbuf,
if (!dpaa_mbuf)
return NULL;
- memcpy((uint8_t *)(dpaa_mbuf->buf_addr) + mbuf->data_off, (void *)
+ memcpy((uint8_t *)(dpaa_mbuf->buf_addr) + RTE_PKTMBUF_HEADROOM, (void *)
((ui
[dpdk-dev] [PATCH 13/18] bus/dpaa: query queue frame count support
Signed-off-by: Hemant Agrawal
---
drivers/bus/dpaa/base/qbman/qman.c| 22 ++
drivers/bus/dpaa/include/fsl_qman.h | 7 +++
drivers/bus/dpaa/rte_bus_dpaa_version.map | 1 +
3 files changed, 30 insertions(+)
diff --git a/drivers/bus/dpaa/base/qbman/qman.c
b/drivers/bus/dpaa/base/qbman/qman.c
index 6ae4bb3..b2f82a3 100644
--- a/drivers/bus/dpaa/base/qbman/qman.c
+++ b/drivers/bus/dpaa/base/qbman/qman.c
@@ -1750,6 +1750,28 @@ int qman_query_fq_np(struct qman_fq *fq, struct
qm_mcr_queryfq_np *np)
return 0;
}
+int qman_query_fq_frm_cnt(struct qman_fq *fq, u32 *frm_cnt)
+{
+ struct qm_mc_command *mcc;
+ struct qm_mc_result *mcr;
+ struct qman_portal *p = get_affine_portal();
+
+ mcc = qm_mc_start(&p->p);
+ mcc->queryfq.fqid = cpu_to_be32(fq->fqid);
+ qm_mc_commit(&p->p, QM_MCC_VERB_QUERYFQ_NP);
+ while (!(mcr = qm_mc_result(&p->p)))
+ cpu_relax();
+ DPAA_ASSERT((mcr->verb & QM_MCR_VERB_MASK) == QM_MCR_VERB_QUERYFQ_NP);
+
+ if (mcr->result == QM_MCR_RESULT_OK)
+ *frm_cnt = be24_to_cpu(mcr->queryfq_np.frm_cnt);
+ else if (mcr->result == QM_MCR_RESULT_ERR_FQID)
+ return -ERANGE;
+ else if (mcr->result != QM_MCR_RESULT_OK)
+ return -EIO;
+ return 0;
+}
+
int qman_query_wq(u8 query_dedicated, struct qm_mcr_querywq *wq)
{
struct qm_mc_command *mcc;
diff --git a/drivers/bus/dpaa/include/fsl_qman.h
b/drivers/bus/dpaa/include/fsl_qman.h
index c5aef2d..9090b63 100644
--- a/drivers/bus/dpaa/include/fsl_qman.h
+++ b/drivers/bus/dpaa/include/fsl_qman.h
@@ -1649,6 +1649,13 @@ int qman_query_fq_has_pkts(struct qman_fq *fq);
int qman_query_fq_np(struct qman_fq *fq, struct qm_mcr_queryfq_np *np);
/**
+ * qman_query_fq_frmcnt - Queries fq frame count
+ * @fq: the frame queue object to be queried
+ * @frm_cnt: number of frames in the queue
+ */
+int qman_query_fq_frm_cnt(struct qman_fq *fq, u32 *frm_cnt);
+
+/**
* qman_query_wq - Queries work queue lengths
* @query_dedicated: If non-zero, query length of WQs in the channel dedicated
* to this software portal. Otherwise, query length of WQs in a
diff --git a/drivers/bus/dpaa/rte_bus_dpaa_version.map
b/drivers/bus/dpaa/rte_bus_dpaa_version.map
index 4e3afda..212c75f 100644
--- a/drivers/bus/dpaa/rte_bus_dpaa_version.map
+++ b/drivers/bus/dpaa/rte_bus_dpaa_version.map
@@ -73,6 +73,7 @@ DPDK_18.02 {
qman_create_cgr;
qman_delete_cgr;
qman_modify_cgr;
+ qman_query_fq_frm_cnt;
qman_release_cgrid_range;
rte_dpaa_portal_fq_close;
rte_dpaa_portal_fq_init;
--
2.7.4
[dpdk-dev] [PATCH 16/18] app/testpmd: add support for loopback config for dpaa
Signed-off-by: Hemant Agrawal
---
app/test-pmd/Makefile | 4
app/test-pmd/cmdline.c | 7 +++
2 files changed, 11 insertions(+)
diff --git a/app/test-pmd/Makefile b/app/test-pmd/Makefile
index d21308f..f60449b 100644
--- a/app/test-pmd/Makefile
+++ b/app/test-pmd/Makefile
@@ -71,6 +71,10 @@ ifeq ($(CONFIG_RTE_LIBRTE_PMD_BOND),y)
LDLIBS += -lrte_pmd_bond
endif
+ifeq ($(CONFIG_RTE_LIBRTE_DPAA_PMD),y)
+LDLIBS += -lrte_pmd_dpaa
+endif
+
ifeq ($(CONFIG_RTE_LIBRTE_IXGBE_PMD),y)
LDLIBS += -lrte_pmd_ixgbe
endif
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index f71d963..32096aa 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -89,6 +89,9 @@
#include
#include
#endif
+#ifdef RTE_LIBRTE_DPAA_PMD
+#include
+#endif
#ifdef RTE_LIBRTE_IXGBE_PMD
#include
#endif
@@ -12620,6 +12623,10 @@ cmd_set_tx_loopback_parsed(
if (ret == -ENOTSUP)
ret = rte_pmd_bnxt_set_tx_loopback(res->port_id, is_on);
#endif
+#ifdef RTE_LIBRTE_DPAA_PMD
+ if (ret == -ENOTSUP)
+ ret = rte_pmd_dpaa_set_tx_loopback(res->port_id, is_on);
+#endif
switch (ret) {
case 0:
--
2.7.4
[dpdk-dev] [PATCH 15/18] net/dpaa: add support for loopback API
Signed-off-by: Hemant Agrawal
---
drivers/net/dpaa/Makefile | 3 +++
drivers/net/dpaa/dpaa_ethdev.c| 42 +++
drivers/net/dpaa/rte_pmd_dpaa.h | 37 +++
drivers/net/dpaa/rte_pmd_dpaa_version.map | 8 ++
4 files changed, 90 insertions(+)
create mode 100644 drivers/net/dpaa/rte_pmd_dpaa.h
diff --git a/drivers/net/dpaa/Makefile b/drivers/net/dpaa/Makefile
index 171686e..a99d1ee 100644
--- a/drivers/net/dpaa/Makefile
+++ b/drivers/net/dpaa/Makefile
@@ -60,4 +60,7 @@ LDLIBS += -lrte_mempool_dpaa
LDLIBS += -lrte_eal -lrte_mbuf -lrte_mempool -lrte_ring
LDLIBS += -lrte_ethdev -lrte_net -lrte_kvargs
+# install this header file
+SYMLINK-$(CONFIG_RTE_LIBRTE_DPAA_PMD)-include := rte_pmd_dpaa.h
+
include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/drivers/net/dpaa/dpaa_ethdev.c b/drivers/net/dpaa/dpaa_ethdev.c
index 53b8c87..fcba929 100644
--- a/drivers/net/dpaa/dpaa_ethdev.c
+++ b/drivers/net/dpaa/dpaa_ethdev.c
@@ -64,6 +64,7 @@
#include
#include
+#include
#include
#include
@@ -110,6 +111,8 @@ static const struct rte_dpaa_xstats_name_off
dpaa_xstats_strings[] = {
offsetof(struct dpaa_if_stats, tund)},
};
+static struct rte_dpaa_driver rte_dpaa_pmd;
+
static int
dpaa_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
{
@@ -733,6 +736,45 @@ static struct eth_dev_ops dpaa_devops = {
.fw_version_get = dpaa_fw_version_get,
};
+static bool
+is_device_supported(struct rte_eth_dev *dev, struct rte_dpaa_driver *drv)
+{
+ if (strcmp(dev->device->driver->name,
+ drv->driver.name))
+ return false;
+
+ return true;
+}
+
+static bool
+is_dpaa_supported(struct rte_eth_dev *dev)
+{
+ return is_device_supported(dev, &rte_dpaa_pmd);
+}
+
+int
+rte_pmd_dpaa_set_tx_loopback(uint8_t port, uint8_t on)
+{
+ struct rte_eth_dev *dev;
+ struct dpaa_if *dpaa_intf;
+
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port, -ENODEV);
+
+ dev = &rte_eth_devices[port];
+
+ if (!is_dpaa_supported(dev))
+ return -ENOTSUP;
+
+ dpaa_intf = dev->data->dev_private;
+
+ if (on)
+ fman_if_loopback_enable(dpaa_intf->fif);
+ else
+ fman_if_loopback_disable(dpaa_intf->fif);
+
+ return 0;
+}
+
static int dpaa_fc_set_default(struct dpaa_if *dpaa_intf)
{
struct rte_eth_fc_conf *fc_conf;
diff --git a/drivers/net/dpaa/rte_pmd_dpaa.h b/drivers/net/dpaa/rte_pmd_dpaa.h
new file mode 100644
index 000..4464dd4
--- /dev/null
+++ b/drivers/net/dpaa/rte_pmd_dpaa.h
@@ -0,0 +1,37 @@
+/*-
+ * Copyright 2017 NXP.
+ *
+ * SPDX-License-Identifier:BSD-3-Clause
+ */
+
+#ifndef _PMD_DPAA_H_
+#define _PMD_DPAA_H_
+
+/**
+ * @file rte_pmd_dpaa.h
+ *
+ * dpaa PMD specific functions.
+ *
+ * @b EXPERIMENTAL: this API may change, or be removed, without prior notice
+ *
+ */
+
+#include
+
+/**
+ * Enable/Disable TX loopback
+ *
+ * @param port
+ *The port identifier of the Ethernet device.
+ * @param on
+ *1 - Enable TX loopback.
+ *0 - Disable TX loopback.
+ * @return
+ * - (0) if successful.
+ * - (-ENODEV) if *port* invalid.
+ * - (-EINVAL) if bad parameter.
+ */
+int rte_pmd_dpaa_set_tx_loopback(uint8_t port,
+uint8_t on);
+
+#endif /* _PMD_DPAA_H_ */
diff --git a/drivers/net/dpaa/rte_pmd_dpaa_version.map
b/drivers/net/dpaa/rte_pmd_dpaa_version.map
index a70bd19..d76acbd 100644
--- a/drivers/net/dpaa/rte_pmd_dpaa_version.map
+++ b/drivers/net/dpaa/rte_pmd_dpaa_version.map
@@ -2,3 +2,11 @@ DPDK_17.11 {
local: *;
};
+
+DPDK_18.02 {
+ global:
+
+ rte_pmd_dpaa_set_tx_loopback;
+
+ local: *;
+} DPDK_17.11;
--
2.7.4
[dpdk-dev] [PATCH 17/18] bus/dpaa: add support for static queues
DPAA hardware support two kinds of queues:
1. Pull mode queue - where one needs to regularly pull the packets.
2. Push mode queue - where the hw pushes the packet to queue. These are
high performance queues, but limitd in number.
This patch add the driver support for push m de queues.
Signed-off-by: Sunil Kumar Kori
Signed-off-by: Hemant Agrawal
---
drivers/bus/dpaa/base/qbman/qman.c| 64 +++
drivers/bus/dpaa/base/qbman/qman.h| 4 +-
drivers/bus/dpaa/include/fsl_qman.h | 10 +
drivers/bus/dpaa/rte_bus_dpaa_version.map | 2 +
4 files changed, 78 insertions(+), 2 deletions(-)
diff --git a/drivers/bus/dpaa/base/qbman/qman.c
b/drivers/bus/dpaa/base/qbman/qman.c
index b2f82a3..42d509d 100644
--- a/drivers/bus/dpaa/base/qbman/qman.c
+++ b/drivers/bus/dpaa/base/qbman/qman.c
@@ -1080,6 +1080,70 @@ u16 qman_affine_channel(int cpu)
return affine_channels[cpu];
}
+unsigned int qman_portal_poll_rx(unsigned int poll_limit,
+void **bufs,
+struct qman_portal *p)
+{
+ const struct qm_dqrr_entry *dq;
+ struct qman_fq *fq;
+ enum qman_cb_dqrr_result res;
+ unsigned int limit = 0;
+#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
+ struct qm_dqrr_entry *shadow;
+#endif
+ unsigned int rx_number = 0;
+
+ do {
+ qm_dqrr_pvb_update(&p->p);
+ dq = qm_dqrr_current(&p->p);
+ if (unlikely(!dq))
+ break;
+#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
+ /* If running on an LE system the fields of the
+* dequeue entry must be swapper. Because the
+* QMan HW will ignore writes the DQRR entry is
+* copied and the index stored within the copy
+*/
+ shadow = &p->shadow_dqrr[DQRR_PTR2IDX(dq)];
+ *shadow = *dq;
+ dq = shadow;
+ shadow->fqid = be32_to_cpu(shadow->fqid);
+ shadow->contextB = be32_to_cpu(shadow->contextB);
+ shadow->seqnum = be16_to_cpu(shadow->seqnum);
+ hw_fd_to_cpu(&shadow->fd);
+#endif
+
+ /* SDQCR: context_b points to the FQ */
+#ifdef CONFIG_FSL_QMAN_FQ_LOOKUP
+ fq = get_fq_table_entry(dq->contextB);
+#else
+ fq = (void *)(uintptr_t)dq->contextB;
+#endif
+ /* Now let the callback do its stuff */
+ res = fq->cb.dqrr_dpdk_cb(NULL, p, fq, dq, &bufs[rx_number]);
+ rx_number++;
+ /* Interpret 'dq' from a driver perspective. */
+ /*
+* Parking isn't possible unless HELDACTIVE was set. NB,
+* FORCEELIGIBLE implies HELDACTIVE, so we only need to
+* check for HELDACTIVE to cover both.
+*/
+ DPAA_ASSERT((dq->stat & QM_DQRR_STAT_FQ_HELDACTIVE) ||
+ (res != qman_cb_dqrr_park));
+ qm_dqrr_cdc_consume_1ptr(&p->p, dq, res == qman_cb_dqrr_park);
+ /* Move forward */
+ qm_dqrr_next(&p->p);
+ /*
+* Entry processed and consumed, increment our counter. The
+* callback can request that we exit after consuming the
+* entry, and we also exit if we reach our processing limit,
+* so loop back only if neither of these conditions is met.
+*/
+ } while (likely(++limit < poll_limit));
+
+ return limit;
+}
+
struct qm_dqrr_entry *qman_dequeue(struct qman_fq *fq)
{
struct qman_portal *p = get_affine_portal();
diff --git a/drivers/bus/dpaa/base/qbman/qman.h
b/drivers/bus/dpaa/base/qbman/qman.h
index 2c0f694..999e429 100644
--- a/drivers/bus/dpaa/base/qbman/qman.h
+++ b/drivers/bus/dpaa/base/qbman/qman.h
@@ -187,7 +187,7 @@ struct qm_eqcr {
};
struct qm_dqrr {
- const struct qm_dqrr_entry *ring, *cursor;
+ struct qm_dqrr_entry *ring, *cursor;
u8 pi, ci, fill, ithresh, vbit;
#ifdef RTE_LIBRTE_DPAA_HWDEBUG
enum qm_dqrr_dmode dmode;
@@ -460,7 +460,7 @@ static inline u8 DQRR_PTR2IDX(const struct qm_dqrr_entry *e)
return ((uintptr_t)e >> 6) & (QM_DQRR_SIZE - 1);
}
-static inline const struct qm_dqrr_entry *DQRR_INC(
+static inline struct qm_dqrr_entry *DQRR_INC(
const struct qm_dqrr_entry *e)
{
return DQRR_CARRYCLEAR(e + 1);
diff --git a/drivers/bus/dpaa/include/fsl_qman.h
b/drivers/bus/dpaa/include/fsl_qman.h
index 9090b63..7ec07ee 100644
--- a/drivers/bus/dpaa/include/fsl_qman.h
+++ b/drivers/bus/dpaa/include/fsl_qman.h
@@ -1157,6 +1157,12 @@ typedef enum qman_cb_dqrr_result (*qman_cb_dqrr)(struct
qman_portal *qm,
struct qman_fq *fq,
const struct qm_dqrr_entry *dqrr);
+typedef enum qman_cb_dqrr_result (*qman_dpdk_cb_dqrr)(void *event
[dpdk-dev] [PATCH 18/18] net/dpaa: integrate the support of push mode in PMD
Signed-off-by: Sunil Kumar Kori
Signed-off-by: Hemant Agrawal
Signed-off-by: Nipun Gupta
---
doc/guides/nics/dpaa.rst | 11
drivers/net/dpaa/dpaa_ethdev.c | 62 ++
drivers/net/dpaa/dpaa_ethdev.h | 2 +-
drivers/net/dpaa/dpaa_rxtx.c | 34 +++
drivers/net/dpaa/dpaa_rxtx.h | 5
5 files changed, 107 insertions(+), 7 deletions(-)
diff --git a/doc/guides/nics/dpaa.rst b/doc/guides/nics/dpaa.rst
index d331c05..7b6a0b1 100644
--- a/doc/guides/nics/dpaa.rst
+++ b/doc/guides/nics/dpaa.rst
@@ -315,6 +315,17 @@ state during application initialization:
In case the application is configured to use lesser number of queues than
configured above, it might result in packet loss (because of distribution).
+- ``DPAA_NUM_PUSH_QUEUES`` (default 4)
+
+ This defines the number of High performance queues to be used for ethdev Rx.
+ These queues use one private HW portal per queue configured, so they are
+ limited in the system. The first configured ethdev queues will be
+ automatically be assigned from the these high perf PUSH queues. Any queue
+ configuration beyond that will be standard Rx queues. The application can
+ choose to change their number if HW portals are limited.
+ The valid values are from '0' to '4'. The valuse shall be set to '0' if the
+ application want to use eventdev with DPAA device.
+
Driver compilation and testing
--
diff --git a/drivers/net/dpaa/dpaa_ethdev.c b/drivers/net/dpaa/dpaa_ethdev.c
index fcba929..7798994 100644
--- a/drivers/net/dpaa/dpaa_ethdev.c
+++ b/drivers/net/dpaa/dpaa_ethdev.c
@@ -73,6 +73,14 @@
/* Keep track of whether QMAN and BMAN have been globally initialized */
static int is_global_init;
+/* At present we only allow up to 4 push mode queues - as each of this queue
+ * need dedicated portal and we are short of portals.
+ */
+#define DPAA_MAX_PUSH_MODE_QUEUE 4
+
+static int dpaa_push_mode_max_queue = DPAA_MAX_PUSH_MODE_QUEUE;
+static int dpaa_push_queue_idx; /* Queue index which are in push mode*/
+
/* Per FQ Taildrop in frame count */
static unsigned int td_threshold = CGR_RX_PERFQ_THRESH;
@@ -460,6 +468,9 @@ int dpaa_eth_rx_queue_setup(struct rte_eth_dev *dev,
uint16_t queue_idx,
{
struct dpaa_if *dpaa_intf = dev->data->dev_private;
struct qman_fq *rxq = &dpaa_intf->rx_queues[queue_idx];
+ struct qm_mcc_initfq opts = {0};
+ u32 flags = 0;
+ int ret;
PMD_INIT_FUNC_TRACE();
@@ -495,7 +506,41 @@ int dpaa_eth_rx_queue_setup(struct rte_eth_dev *dev,
uint16_t queue_idx,
dpaa_intf->name, fd_offset,
fman_if_get_fdoff(dpaa_intf->fif));
}
-
+ /* checking if push mode only, no error check for now */
+ if (dpaa_push_mode_max_queue > dpaa_push_queue_idx) {
+ dpaa_push_queue_idx++;
+ opts.we_mask = QM_INITFQ_WE_FQCTRL | QM_INITFQ_WE_CONTEXTA;
+ opts.fqd.fq_ctrl = QM_FQCTRL_AVOIDBLOCK |
+ QM_FQCTRL_CTXASTASHING |
+ QM_FQCTRL_PREFERINCACHE;
+ opts.fqd.context_a.stashing.exclusive = 0;
+ opts.fqd.context_a.stashing.data_cl = DPAA_IF_RX_DATA_STASH;
+ opts.fqd.context_a.stashing.context_cl =
+ DPAA_IF_RX_CONTEXT_STASH;
+ if (dpaa_svr_family != SVR_LS1046A_FAMILY)
+ opts.fqd.context_a.stashing.annotation_cl =
+ DPAA_IF_RX_ANNOTATION_STASH;
+
+ /*Create a channel and associate given queue with the channel*/
+ qman_alloc_pool_range((u32 *)&rxq->ch_id, 1, 1, 0);
+ opts.we_mask = opts.we_mask | QM_INITFQ_WE_DESTWQ;
+ opts.fqd.dest.channel = rxq->ch_id;
+ opts.fqd.dest.wq = DPAA_IF_RX_PRIORITY;
+ flags = QMAN_INITFQ_FLAG_SCHED;
+
+ /* Configure tail drop */
+ if (dpaa_intf->cgr_rx) {
+ opts.we_mask |= QM_INITFQ_WE_CGID;
+ opts.fqd.cgid = dpaa_intf->cgr_rx[queue_idx].cgrid;
+ opts.fqd.fq_ctrl |= QM_FQCTRL_CGE;
+ }
+ ret = qman_init_fq(rxq, flags, &opts);
+ if (ret)
+ DPAA_PMD_ERR("Channel/Queue association failed. fqid %d"
+" ret: %d", rxq->fqid, ret);
+ rxq->cb.dqrr_dpdk_cb = dpaa_rx_cb;
+ rxq->is_static = true;
+ }
dev->data->rx_queues[queue_idx] = rxq;
/* configure the CGR size as per the desc size */
@@ -835,11 +880,8 @@ static int dpaa_rx_queue_init(struct qman_fq *fq, struct
qman_cgr *cgr_rx,
fqid, ret);
return ret;
}
-
- opts.we_mask = QM_INITFQ_WE_DESTWQ | QM_INITFQ_WE_FQCTRL |
-
Re: [dpdk-dev] [PATCH v2 05/39] examples/l3fwd: move to ethdev offloads API
Hi Jerin,
> -Original Message-
> From: Jerin Jacob [mailto:jerin.ja...@caviumnetworks.com]
> Sent: Wednesday, December 13, 2017 7:55 AM
> To: Shahaf Shuler
> Cc: Ananyev, Konstantin ; dev@dpdk.org;
> Nicolau, Radu ;
> arybche...@solarflare.com
> Subject: Re: [dpdk-dev] [PATCH v2 05/39] examples/l3fwd: move to ethdev
> offloads API
>
> -Original Message-
> > Date: Wed, 13 Dec 2017 07:21:01 +
> > From: Shahaf Shuler
> > To: "Ananyev, Konstantin" , "dev@dpdk.org"
> > , "Nicolau, Radu" ,
> > "arybche...@solarflare.com"
> > Subject: Re: [dpdk-dev] [PATCH v2 05/39] examples/l3fwd: move to ethdev
> > offloads API
> >
> > Tuesday, December 12, 2017 7:12 PM, Ananyev, Konstantin:
> > > > -Original Message-
> > > > From: Shahaf Shuler [mailto:shah...@mellanox.com]
> > > > Sent: Tuesday, December 12, 2017 12:26 PM
> > > > To: dev@dpdk.org; Ananyev, Konstantin
> > > ;
> > > > Nicolau, Radu ; arybche...@solarflare.com
> > > > Subject: [PATCH v2 05/39] examples/l3fwd: move to ethdev offloads API
> > > >
> > > > Ethdev offloads API has changed since:
> > > >
> > > > commit ce17eddefc20 ("ethdev: introduce Rx queue offloads API") commit
> > > > cba7f53b717d ("ethdev: introduce Tx queue offloads API")
> > > >
> > > > This commit support the new API.
> > > >
> > > > Signed-off-by: Shahaf Shuler
> > > > ---
> > > > examples/l3fwd/main.c | 40 ++
> > > --
> > > > 1 file changed, 30 insertions(+), 10 deletions(-)
> > > >
> > > > diff --git a/examples/l3fwd/main.c b/examples/l3fwd/main.c index
> > > > 6229568..3bdf4d5 100644
> > > > --- a/examples/l3fwd/main.c
> > > > +++ b/examples/l3fwd/main.c
> > > > @@ -149,11 +149,9 @@ struct lcore_params {
> > > > .mq_mode = ETH_MQ_RX_RSS,
> > > > .max_rx_pkt_len = ETHER_MAX_LEN,
> > > > .split_hdr_size = 0,
> > > > - .header_split = 0, /**< Header Split disabled */
> > > > - .hw_ip_checksum = 1, /**< IP checksum offload enabled */
> > > > - .hw_vlan_filter = 0, /**< VLAN filtering disabled */
> > > > - .jumbo_frame= 0, /**< Jumbo Frame Support disabled
> > > > */
> > > > - .hw_strip_crc = 1, /**< CRC stripped by hardware */
> > > > + .ignore_offload_bitfield = 1,
> > > > + .offloads = (DEV_RX_OFFLOAD_CRC_STRIP |
> > > > +DEV_RX_OFFLOAD_CHECKSUM),
> > > > },
> > > > .rx_adv_conf = {
> > > > .rss_conf = {
> > > > @@ -163,6 +161,7 @@ struct lcore_params {
> > > > },
> > > > .txmode = {
> > > > .mq_mode = ETH_MQ_TX_NONE,
> > > > + .offloads = DEV_TX_OFFLOAD_MBUF_FAST_FREE,
> > >
> > > Hmm, does it mean a new warning for all PMDs (majority) which don't
> > > support DEV_TX_OFFLOAD_MBUF_FAST_FREE?
> >
> > Good point.
> > Unlike other offloads which are must for the application proper run, this
> > one it only for optimizing the performance and should be set only
> if PMD supports.
> > Am continuing to aggregate reasons why the DEV_TX_OFFLOAD_MBUF_FAST_FREE
> > should not be defined as an offload. Anyway we
> passed that...
> >
> > I will fix on v3.
>
> Removing is not an option as the PMDs rely on that flag to will have the
> impact.
> # I see DEV_TX_OFFLOAD_MBUF_FAST_FREE as hint driver to depict the
> application requirements
> # All the drivers by default can support DEV_TX_OFFLOAD_MBUF_FAST_FREE(They
> are using the hint or
> not is a different question)
>
> So, How about setting DEV_TX_OFFLOAD_MBUF_FAST_FREE in all PMD driver as
> dummy one? I think, currently, it can be moved to old API to new API
> transition function till the drivers change to new offload flag scheme.
I don't think anyone plans to remove it right now.
If you believe your PMD does need it, that's ok by me.
Though I still think it is a very limited usage for it, and I don't think
we have to make that flag supported by all PMDs.
Konstantin
>
> We are planning to change nicvf driver to new offload scheme for this
> release so with this change, we have the performance impact on l3fwd
> application.
>
> I think, the other option could be to change usage/meaning of
> DEV_TX_OFFLOAD_MBUF_FAST_FREE flag where when the application needs
> multi-pool and reference count scheme then "it sets" the offload flags.
> If so, we don't need to set by default on the these applications.
Re: [dpdk-dev] [ovs-dev] [PATCH] netdev-dpdk: defer MTU set after interface start
> > The issue only arises with the qede PMD and 67fe6d635193
> > ("netdev-dpdk: use rte_eth_dev_set_mtu.")
>
> I had some more time to look at this today but this patch will break OVS DPDK
> for existing supported DPDK ports during testing.
>
> I tested with an XL710 and the MTU will fail to apply, the device must be
> stopped before configuration changes can be applied such as
> MTU. See log message below
>
> 2017-11-28T17:13:50Z|00086|dpdk|ERR|i40e_dev_mtu_set(): port 0 must be
> stopped before configuration
> 2017-11-28T17:13:50Z|00087|netdev_dpdk|ERR|Interface dpdk0 MTU (1500) setup
> error: Device or resource busy
>
> Did you come across it in your testing? I guess you didn’t see this for QEDE
> pmd. In my case the DPDK devices will simply fail to add to the
> bridge.
>
> As is, the patch would not be acceptable as its breaking existing
> functionality. It would have to be reworked to configure for device that
> cannot reconfigure when busy.
>
> Thanks
> Ian
I fully support the original decision to switch to using rte_dev_set_mtu() in
OVS. The prior approach setting max_rx_pkt_len in rte_eth_dev_configure() was
non-portable as that field has no well-defined semantics and its relation to
the MTU size is different for almost every PMD.
I had a look at the qede PMD implementation of rte_dev_set_mtu() in DPDK 17.05
and 17.11. It assumes that the device must be started because qede_set_mtu()
unconditionally stops the device before and restarts it after changing the MTU
value. Given that other PMDs like i40e don’t accept it after start, there is no
possible way OVS can use rte_dev_set_mtu() that will work with all drivers.
I think it is a weakness of the rte_ethdev API that it does not specify clearly
when API functions like rte_dev_set_mtu() may be called. From the documentation
of error -EBUSY one can guess that the intention was to optionally support it
when the device is started. Implicitly one could conclude that it MUST be
supported when the device stopped. That is logical and also what most PMDs do.
I would say the qede PMD should be fixed. It should accept the
rte_dev_set_mtu() at any time between rte_eth_dev_configure() and
rte_eth_dev_start() (and optionally also after start).
BR, Jan
[IS] Thanks for doing this follow up Jan, it’s really valuable in my opinion.
It’s definitely something that should be raised to the DPDK community as
conceivably if there is no set process to follow we could see varying behavior
from PMD device to device. I’m happy to take this and raise it to the DPDK
community.
Thanks
Ian
Re: [dpdk-dev] [PATCH 0/6] next-build: create both static and shared libs
On Tue, 2017-12-12 at 17:14 +, Bruce Richardson wrote: > On Tue, Dec 12, 2017 at 04:59:34PM +, Bruce Richardson wrote: > > This patchset changes the meson+ninja build system to always create > > both > > static and shared libraries when doing a build. The applications > > compiled > > as part of a build use either the shared or static libraries > > depending on > > what the default_library build setting is. > > > > NOTE: > > The main difficulty with this change is adjusting the pkgconfig > > file so > > that external apps, like the examples, can be built using either > > the static > > or shared libraries. One of the key issues was the fact that > > running > > "pkg-config --static --libs libdpdk" outputs first the normal libs, > > and > > then the extra static ones. This is a problem because the driver > > libs are > > for static only builds, but need to come before, not after the > > standard > > DDPK libraries. It also procludes adding in the -Wl,-Bstatic flag > > into the output for the standard libraries to link them statically. > > > > There were two options considered for mananging the pkg-config > > settings. > > 1. Creating a separate .pc file for static builds with exactly the > > flags > > needed. > > 2. Modifying the single .pc file so that it was "good enough" to > > enable > > static builds without too much work. > > > > For this version of this set, I took option #2. To link using > > dynamic libs, > > all is as normal, to use static libs, the user needs to prepend > > "-Wl,-Bstatic" before the "pkgconfig --static" library output. This > > can be > > seen in the changes to the example application makefiles, which now > > support > > building the examples using shared or static DPDK libs. > > > > Just to emphasise that I'm looking for input into whether I took the > right choice here. Option #1 has some advantages in that we can tune > the > output specifically for the static build case, but I wasn't sure > whether > it would be the done thing to have two different .pc files for a > single > package. Feedback from packagers welcome! > > /Bruce I don't link #1 too much - too "special". I think an additional flag is more friendly. A good solution would be a Cflags.private feature, sadly that is not supported by pkgconfig despite many requests for it. A possible way to sugar-coat it could be to add a custom variable, and then instruct the users to do something like: $(shell pkg-config --variable=ldflags.static libdpdk) $(shell pkg- config --static --libs libdpdk) Unfortunately, again, --variable cannot be used together with --libs in the same call. -- Kind regards, Luca Boccassi
Re: [dpdk-dev] [PATCH 0/6] next-build: create both static and shared libs
On Tue, 2017-12-12 at 16:59 +, Bruce Richardson wrote: > This patchset changes the meson+ninja build system to always create > both > static and shared libraries when doing a build. The applications > compiled > as part of a build use either the shared or static libraries > depending on > what the default_library build setting is. > > NOTE: > The main difficulty with this change is adjusting the pkgconfig file > so > that external apps, like the examples, can be built using either the > static > or shared libraries. One of the key issues was the fact that running > "pkg-config --static --libs libdpdk" outputs first the normal libs, > and > then the extra static ones. This is a problem because the driver libs > are > for static only builds, but need to come before, not after the > standard > DDPK libraries. It also procludes adding in the -Wl,-Bstatic flag > into the output for the standard libraries to link them statically. > > There were two options considered for mananging the pkg-config > settings. > 1. Creating a separate .pc file for static builds with exactly the > flags > needed. > 2. Modifying the single .pc file so that it was "good enough" to > enable > static builds without too much work. > > For this version of this set, I took option #2. To link using dynamic > libs, > all is as normal, to use static libs, the user needs to prepend > "-Wl,-Bstatic" before the "pkgconfig --static" library output. This > can be > seen in the changes to the example application makefiles, which now > support > building the examples using shared or static DPDK libs. > > Bruce Richardson (6): > build: remove library special cases > eal: fix list of source files to meson build > build: build all libs and drivers as both static and shared > build: change default library type to static > build: symlink drivers to library directory > examples: enable linking examples both static and shared > > app/test-pmd/meson.build | 5 +- > buildtools/symlink-drivers-solibs.sh | 16 > config/meson.build | 14 > doc/guides/contributing/coding_style.rst | 9 +++ > drivers/meson.build| 43 +++--- > drivers/net/e1000/base/meson.build | 2 +- > drivers/net/fm10k/base/meson.build | 2 +- > drivers/net/i40e/base/meson.build | 2 +- > drivers/net/ixgbe/base/meson.build | 2 +- > examples/bond/Makefile | 21 +++-- > examples/cmdline/Makefile | 21 +++-- > examples/distributor/Makefile | 21 +++-- > examples/eventdev_pipeline_sw_pmd/Makefile | 21 +++-- > examples/exception_path/Makefile | 21 +++-- > examples/flow_classify/Makefile| 21 +++-- > examples/flow_filtering/Makefile | 21 +++-- > examples/helloworld/Makefile | 21 +++-- > examples/ip_fragmentation/Makefile | 21 +++-- > examples/ip_pipeline/Makefile | 21 +++-- > examples/ip_reassembly/Makefile| 21 +++-- > examples/ipsec-secgw/Makefile | 21 +++-- > examples/ipv4_multicast/Makefile | 21 +++-- > examples/kni/Makefile | 21 +++-- > examples/l2fwd-cat/Makefile| 21 +++-- > examples/l2fwd-crypto/Makefile | 21 +++-- > examples/l2fwd-jobstats/Makefile | 21 +++-- > examples/l2fwd-keepalive/Makefile | 21 +++-- > examples/l2fwd/Makefile| 21 +++-- > examples/l3fwd-acl/Makefile| 21 +++-- > examples/l3fwd-power/Makefile | 21 +++-- > examples/l3fwd-vf/Makefile | 21 +++-- > examples/l3fwd/Makefile| 21 +++-- > examples/link_status_interrupt/Makefile| 21 +++-- > examples/load_balancer/Makefile| 21 +++-- > examples/meson.build | 2 +- > examples/packet_ordering/Makefile | 21 +++-- > examples/ptpclient/Makefile| 21 +++-- > examples/qos_meter/Makefile| 21 +++-- > examples/qos_sched/Makefile| 21 +++-- > examples/rxtx_callbacks/Makefile | 21 +++-- > examples/service_cores/Makefile| 21 +++-- > examples/skeleton/Makefile | 21 +++-- > examples/tep_termination/Makefile | 21 +++-- > examples/timer/Makefile| 21 +++-- > examples/vhost/Makefile| 21 +++-- > examples/vhost_scsi/Makefile | 21 +++-- > examples/vmdq/Makefile | 21 +++-- > examples/vmdq_dcb/Makefile | 21 +++-- > lib/librte_eal/bsdapp/eal/meson.build | 34 +--- > lib/librte_eal/bsdapp/meson.build
Re: [dpdk-dev] [PATCH 1/5] pmdinfogen: fix cross compilation for ARM BE
On Wed, Dec 13, 2017 at 05:22:57PM +0530, Hemant Agrawal wrote:
> Hi Neil/Bruce,
>
> On 12/12/2017 12:28 AM, Neil Horman wrote:
> > On Mon, Dec 11, 2017 at 12:40:32PM +, Bruce Richardson wrote:
> > > On Thu, Nov 02, 2017 at 03:38:51PM +0530, Hemant Agrawal wrote:
> > > > cross compiling DPDK for BE mode on ARM results into errors
> > > >
> > > > "PMDINFO portal/dpaa2_hw_dpio.o.pmd.c No drivers registered"
> > > >
> > > > Fixes: 98b0fdb0ffc6 ("pmdinfogen: add buildtools and pmdinfogen
> > > > utility")
> > > > Cc: Neil Horman
> > > > Cc: sta...@dpdk.org
> > > >
> > > > Signed-off-by: Jun Yang
> > > > Signed-off-by: Hemant Agrawal
> > > > ---
> > > > buildtools/pmdinfogen/pmdinfogen.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > >
> > > Comment could be a bit more specific about what the problem is and how
> > > changing the hard-coded "32" fixes it.
> > >
> > > Haven't tested the cross compilation part myself, but this causes no
> > > errors for 32-bit or 64-bit builds on my system. So, with some more
> > > detail on the specifics of the fix in the commit message:
> > >
> > > Acked-by: Bruce Richardson
> > >
> >
> > I'm with Bruce. I'd like to know exactly whats going on here. I dont have
> > an
> > ARM system handy, so could you please post the errors that you are seeing
> > here?
> > Is ADDR_SIZE not defined on BE for ARM or some such? That seems like it
> > should
> > be fixed, rather than this change.
> >
> > Neil
> >
>
> The original code hard codes the conversion for sh_size to 32, which is
> incorrect.
>
> The sh_size can be "Elf32_Wordsh_size" for 32 bit and "Elf64_Xword
> sh_size" for 64 bit systems.
>
> This causes the symtab_stop to have reduced size and thus find can fail.
> info->symtab_stop = RTE_PTR_ADD(hdr, sechdrs[i].sh_offset +
> sechdrs[i].sh_size);
>
> we fixed it by replacing the hardcoded 32 with ADDR_SIZE is better.
>
Oh, my bad, you're correct, I thought it was 32 bits for both ABI's
Acked-by: Neil Horman
Re: [dpdk-dev] [PATCH 2/5] lpm: fix compilation on ARM BE
On 12/11/2017 6:11 PM, Bruce Richardson wrote:
On Thu, Nov 02, 2017 at 03:38:52PM +0530, Hemant Agrawal wrote:
Compiling on ARM BE using Linaro toolchain caused following
error/warnings.
rte_lpm.c: In function ‘add_depth_big_v20’:
rte_lpm.c:911:4: error: braces around scalar initializer [-Werror]
{ .group_idx = (uint8_t)tbl8_group_index, },
^
rte_lpm.c:911:4: note: (near initialization for
‘new_tbl24_entry.depth’)
rte_lpm.c:911:6:error: field name not in record or union initializer
{ .group_idx = (uint8_t)tbl8_group_index, },
^
rte_lpm.c:911:6: note: (near initialization for
‘new_tbl24_entry.depth’)
rte_lpm.c:914:13: error: initialized field overwritten
[-Werror=override-init]
.depth = 0,
Fixes: dc81ebbacaeb ("lpm: extend IPv4 next hop field")
Cc: Michal Kobylinski
Cc: sta...@dpdk.org
Signed-off-by: Hemant Agrawal
---
Acked-by: Bruce Richardson
Thanks for review. I found a better solution, I will be sending a v2.
Re: [dpdk-dev] check_port_config error
On Tue, Dec 12, 2017 at 01:22:16AM -0500, Pragash Vijayaragavan wrote: > Hi, > > I am trying to run dpdk app l3fwd but gives some errors. > > I bind my nics using dpdk-dev-bind script. > > I also set env variables correctly. > > The nb_ports is 0 when i tried printing that inside "check_port_config" > function. > Also I used "igb_uio" module but it still shows net_i40e > > can someone help me please. Thanks > Hi, this question is more suited to the us...@dpdk.org rather than the dev@dpdk.org list. However, in order to debug your problem, it could be useful to send on the output of "dpdk-devbind.py -s" to show the current state of the various ports. > pragash@revvit:~/dpdk-stable-17.05.2/examples/l3fwd/build$ ./l3fwd -l 1-19 > --no-huge -- -p 0x07 -L --config="(0,0,1),(1,0,2)" --ipv6 --parse-ptype > EAL: Detected 20 lcore(s) > EAL: Probing VFIO support... > EAL: Started without hugepages support, physical addresses not available I notice too, that you are not running as the root user and not using hugepage memory. In this case, the driver may not be able to function as it cannot get the physical address information of the memory in use. Does running using sudo and without the "--no-huge" flag work? /Bruce
Re: [dpdk-dev] [RFC] eventdev: add crypto adapter API header
Hi Jerin, Declan,
On Wednesday 13 December 2017 04:56 PM, Jerin Jacob wrote:
-Original Message-
Date: Wed, 13 Dec 2017 11:03:06 +
From: "Doherty, Declan"
To: Jerin Jacob , Abhinandan Gujjar
CC: dev@dpdk.org, narender.vang...@intel.com, Nikhil Rao
, Gage Eads ,
hemant.agra...@nxp.com, nidadavolu.mur...@cavium.com,
nithin.dabilpu...@cavium.com, narayanaprasad.athr...@cavium.com
Subject: Re: [RFC] eventdev: add crypto adapter API header
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
Thunderbird/52.5.0
On 29/11/2017 11:41 AM, Jerin Jacob wrote:
-Original Message-
...
Adding Declan and Hemant.
IMO, RTE_EVENT_CRYPTO_ENQ_MULTI_EVENTQ may not be very useful
from application perceptive as the scope is very limited.
In real world use cases, we will be attaching destination event queue
information
to the session, not to the queue pair.
IMO, RTE_EVENT_CRYPTO_ENQ_MBUF_MULTI_EVENTQ scheme may not very
convenient for application writers as
# it relies on mbuf private area memory. So it has additional memory alloc/free
requirements.
# additional overhead for application/PMD to write/read the event queue metadata
information per packet.
Since we already have meta data structure in the crypto
area, How about adding the destination event queue attributes
in the PMD crypto session area and for, _session less_, we can add it
in rte_crypto_op stricture? This will help in:
# Offloading HW specific meta data generation for event queue attributes
to slow path.
# From the application perspective, most likely the event queue parameters
will be different for each session not per packet nor per event queue
pair.
Hey Jerin,
Hey Declan,
given my limited experience with eventdev, your proposed approach in general
makes sense to me, in that a packet flow having crypto processing done will
always be forwarded the same next stage event queue. So storing this state
in the crypto session, or crypto op in the case of sessionless ops, seems
sensible.
Something like below to share my view. Exact details may be we can work it out.
I terms of your proposed changes below, my main concern would be introducing
dependencies on the eventdev library into cryptodev, as with this new crypto
adpater you will have a dependency on cryptodev in eventdev.
I agree with your dependency concern.
I think the best approach would be to support opaque metadata in both the
crypto op and crypto session structures, as this would allow other uses
cases to be supported which aren't specific to eventdev to also store
metadata across cryptodev processing.
Make sense. Just to add, adding a pointer would be overhead. I think, we
can reserve a few bytes as byte array and then later typecast with
eventdev api in eventdev library.
uint8_t eventdev_metadata[SOMEBYTES];
Thoughts?
Can we have this info in structure rte_crypto_sym_xform instead of
rte_crypto_op
so that for session less or session full we have just one api say as below
to update the event information.
rte_cryptodev_sym_xform_event_init(struct rte_crypto_sym_xform *xforms,
struct
rte_event ev)
IMO, this is better because for both session_less or session_full modes,
app has to
prepare sym_xform structure and in case of session_less make the struct
rte_crypto_op
point to sym_xform and in session_full pass it to
rte_cryptodev_sym_session_create().
The same can be followed for asym/security sessions in future if needed.
➜ [master][dpdk.org] $ git diff
diff --git a/lib/librte_cryptodev/rte_crypto.h
b/lib/librte_cryptodev/rte_crypto.h
index 3d672fe7d..b44ef673b 100644
--- a/lib/librte_cryptodev/rte_crypto.h
+++ b/lib/librte_cryptodev/rte_crypto.h
@@ -115,6 +115,9 @@ struct rte_crypto_op {
uint8_t reserved[5];
/**< Reserved bytes to fill 64 bits for future additions */
+#if 0
+ Crypto completion event attribute. For _session less_ crypto enqueue
operation,
+ The will field shall be used by application to post the crypto completion
event
+ upon the crypto enqueue operation complete.
+ Note: In the case of session based crypto operation, SW based crypto adapter
can use
+ this memory to store crypto event completion attributes from the PMD
+ specific session area.
+
+ Note: ev.event_ptr will point to struct rte_crypto_op *op, So
+ that core can free the ops memory on event_dequeue().
+#endif
+
+ struct rte_event ev;
struct rte_mempool *mempool;
/**< crypto operation mempool which operation is allocated from
* */
diff --git a/lib/librte_cryptodev/rte_cryptodev.h
b/lib/librte_cryptodev/rte_cryptodev.h
index dade5548f..540b29e66 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -945,6 +945,13 @@ rte_cryptodev_sym_session_init(uint8_t dev_id,
struct rte_crypto_sym_xform *xforms,
struct rte_mempool *mempool);
+#if 0
+ Crea
Re: [dpdk-dev] [PATCH v3 3/4] net/bond: dedicated hw queues for LACP control traffic
Hi, > -Original Message- > From: linhaifeng [mailto:haifeng@huawei.com] > Sent: Wednesday, December 13, 2017 09:16 > To: Doherty, Declan ; dev@dpdk.org > Cc: Kulasek, TomaszX > Subject: Re: [dpdk-dev] [PATCH v3 3/4] net/bond: dedicated hw queues for LACP > control traffic > > Hi, > > What is the purpose of this patch? fix problem or improve performance? > > 在 2017/7/5 0:46, Declan Doherty 写道: > > From: Tomasz Kulasek > > > > Add support for hardware flow classification of LACP control plane > > traffic to be redirect to a dedicated receive queue on each slave which > > is not visible to application. Also enables a dedicate transmit queue > > for LACP traffic which allows complete decoupling of control and data > > paths. > This is performance improvement. Tomasz
Re: [dpdk-dev] [PATCH 1/3] ethdev: add max burst size to device info
> -Original Message-
> From: Shreyansh Jain [mailto:shreyansh.j...@nxp.com]
> Sent: Tuesday, December 12, 2017 1:44 PM
> To: Ananyev, Konstantin ; Matan Azrad
> ; Nikhil Agarwal
>
> Cc: dev@dpdk.org; Hunt, David ; nikhil.agar...@nxp.com;
> hemant.agra...@nxp.com; Yigit, Ferruh
>
> Subject: Re: [PATCH 1/3] ethdev: add max burst size to device info
>
> On Tuesday 12 December 2017 04:33 PM, Ananyev, Konstantin wrote:
> >
> >
> >> -Original Message-
> >> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Matan Azrad
> >> Sent: Tuesday, December 12, 2017 10:46 AM
> >> To: Nikhil Agarwal ; dev@dpdk.org
> >> Cc: Hunt, David ; nikhil.agar...@nxp.com;
> >> hemant.agra...@nxp.com; Yigit, Ferruh
> >> Subject: Re: [dpdk-dev] [PATCH 1/3] ethdev: add max burst size to device
> >> info
> >>
> >> Hi Nikhil
> >>
> >>> -Original Message-
> >>> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Nikhil Agarwal
> >>> Sent: Tuesday, December 12, 2017 12:05 PM
> >>> To: dev@dpdk.org
> >>> Cc: david.h...@intel.com; nikhil.agar...@nxp.com;
> >>> hemant.agra...@nxp.com; ferruh.yi...@intel.com
> >>> Subject: [dpdk-dev] [PATCH 1/3] ethdev: add max burst size to device info
> >>>
> >>> Currently, if the rte_eth_rx_burst() function returns a value less than
> >>> *nb_pkts*, the application will assume that no more packets are present..
> >>>
> >>> Some of the hw queue based hardware can only support smaller burst for RX
> >>> and TX and thus break the expectation of the rx_burst API.
> >>>
> >>
> >> Doesn't such like devices PMDs should try to retrieve multiple HW burst to
> >> adjust the asked received packet number?
> >
> > Same thought here...
> > Can't that limitation be hidden inside PMD by calling HW burst multiple
> > times?
>
> This might be required in some cases for performance.
> It is possible that for each request containing N buffers, if the PMD
> fetches all N (more than its preferred burst_size), cache misses reduce
> the performance - especially for SoC with limited cache size.
>
> Also, a complete cycle of
> application->driver->hardware->driver->application can help driver
> prefetch buffers - which, in case of hw burst looping, might be too
> little to complete the prefetch cycle.
>
> To summarize, indeed this is for performance specific cases and the idea
> that @Matan gave for renaming 'perf_buf_size' to highlight this, sounds
> logical.
>
> > Also if I am not mistaken - it would increase size of struct
> > rte_eth_dev_info, right?
> > If so, then it means ABI breakage.
>
> Yes, deprecation notice should have been sent - if we continue with the
> dev_info change. To me that looks as one of the option. Maybe, someone
> on the list has a better idea.
In theory there is at least 2 free bytes at the end of struct rte_eth_desc_lim.
Might be it would help a bit.
Konstantin
>
> > Konstantin
> >
> >>
> >>> This patch adds support to provide the maximum burst size that can be
> >>> supported by a given PMD. The dev_info is being memset to '0' in
> >>> rte_ethdev library. The value of '0' indicates that any value for burst
> >>> size can
> >>> be supported i.e. no change for existing PMDs.
> >>>
> >>> The application can now use the lowest available max_burst_size value for
> >>> rte_eth_rx_burst.
> >>>
> >>
> >> If you are talking about performance, maybe the right field to expose is
> >> something like "perf_burst_size" or "preferred_burst_size".
> >> I also suggest to expose different fields for RX and for TX.
> >> Maybe the rte_eth_rx\tx_burst() descriptions should be updated.
> >>
> >> Thanks
> >> Matan.
> >>
> >>> Signed-off-by: Nikhil Agarwal
> >>> ---
> >>> lib/librte_ether/rte_ethdev.h | 1 +
> >>> 1 file changed, 1 insertion(+)
> >>>
> >>> diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
> >>> index 341c2d6..3ab6f02 100644
> >>> --- a/lib/librte_ether/rte_ethdev.h
> >>> +++ b/lib/librte_ether/rte_ethdev.h
> >>> @@ -1047,6 +1047,7 @@ struct rte_eth_dev_info {
> >>> /** Configured number of rx/tx queues */
> >>> uint16_t nb_rx_queues; /**< Number of RX queues. */
> >>> uint16_t nb_tx_queues; /**< Number of TX queues. */
> >>> + uint16_t max_burst_size; /**< MAX burst size, 0 for no limit. */
> >>> };
> >>>
> >>> /**
> >>> --
> >>> 2.7.4
> >
> >
Re: [dpdk-dev] [PATCH v3 2/2] examples/ipsec-secgw: add target queues in flow actions
Hi Anoob,
On Wed, Dec 13, 2017 at 05:08:19PM +0530, Anoob Joseph wrote:
> Hi Nelio,
>
>
> On 12/13/2017 03:32 PM, Nelio Laranjeiro wrote:
> > Hi Anoob,
> >
> > On Wed, Dec 13, 2017 at 12:11:18PM +0530, Anoob Joseph wrote:
> > > Hi Nelio,
> > >
> > >
> > > On 12/12/2017 08:08 PM, Nelio Laranjeiro wrote:
> > > > Hi Anoob,
> > > >
> > > > On Tue, Dec 12, 2017 at 07:34:31PM +0530, Anoob Joseph wrote:
> > > > > Hi Nelio,
> > > > >
> > > > >
> > > > > On 12/12/2017 07:14 PM, Nelio Laranjeiro wrote:
> > > > > > Hi Anoob,
> > > > > >
> > > > > > On Tue, Dec 12, 2017 at 06:13:08PM +0530, Anoob Joseph wrote:
> > > > > > > Hi Nelio,
> > > > > > >
> > > > > > >
> > > > > > > On 12/11/2017 07:34 PM, Nelio Laranjeiro wrote:
> > > > > > > > Mellanox INNOVA NIC needs to have final target queue actions to
> > > > > > > > perform
> > > > > > > > inline crypto.
> > > > > > > >
> > > > > > > > Signed-off-by: Nelio Laranjeiro
> > > > > > > >
> > > > > > > > ---
> > > > > > > >
> > > > > > > > Changes in v3:
> > > > > > > >
> > > > > > > > * removed PASSTHRU test for ingress.
> > > > > > > > * removed check on configured queues for the queue action.
> > > > > > > >
> > > > > > > > Changes in v2:
> > > > > > > >
> > > > > > > > * Test the rule by PASSTHRU/RSS/QUEUE and apply the first
> > > > > > > > one validated.
> > > > > > > > ---
> > > > > > > > examples/ipsec-secgw/ipsec.c | 57
> > > > > > > > ++--
> > > > > > > > examples/ipsec-secgw/ipsec.h | 2 +-
> > > > > > > > 2 files changed, 56 insertions(+), 3 deletions(-)
> > > > > > > >
> > > > > > > > diff --git a/examples/ipsec-secgw/ipsec.c
> > > > > > > > b/examples/ipsec-secgw/ipsec.c
> > > > > > > > index 17bd7620d..1b8b251c8 100644
> > > > > > > > --- a/examples/ipsec-secgw/ipsec.c
> > > > > > > > +++ b/examples/ipsec-secgw/ipsec.c
> > > > > > > > @@ -142,6 +142,7 @@ create_session(struct ipsec_ctx *ipsec_ctx,
> > > > > > > > struct ipsec_sa *sa)
> > > > > > > >
> > > > > > > > rte_eth_dev_get_sec_ctx(
> > > > > > > >
> > > > > > > > sa->portid);
> > > > > > > > const struct rte_security_capability
> > > > > > > > *sec_cap;
> > > > > > > > + int ret = 0;
> > > > > > > > sa->sec_session =
> > > > > > > > rte_security_session_create(ctx,
> > > > > > > > &sess_conf,
> > > > > > > > ipsec_ctx->session_pool);
> > > > > > > > @@ -201,15 +202,67 @@ create_session(struct ipsec_ctx
> > > > > > > > *ipsec_ctx, struct ipsec_sa *sa)
> > > > > > > > sa->action[0].type =
> > > > > > > > RTE_FLOW_ACTION_TYPE_SECURITY;
> > > > > > > > sa->action[0].conf = sa->sec_session;
> > > > > > > > - sa->action[1].type =
> > > > > > > > RTE_FLOW_ACTION_TYPE_END;
> > > > > > > > -
> > > > > > > > sa->attr.egress = (sa->direction ==
> > > > > > > >
> > > > > > > > RTE_SECURITY_IPSEC_SA_DIR_EGRESS);
> > > > > > > > sa->attr.ingress = (sa->direction ==
> > > > > > > >
> > > > > > > > RTE_SECURITY_IPSEC_SA_DIR_INGRESS);
> > > > > > > > + if (sa->attr.ingress) {
> > > > > > > > + uint8_t rss_key[40];
> > > > > > > > + struct rte_eth_rss_conf
> > > > > > > > rss_conf = {
> > > > > > > > + .rss_key = rss_key,
> > > > > > > > + .rss_key_len = 40,
> > > > > > > > + };
> > > > > > > > + struct rte_eth_dev *eth_dev;
> > > > > > > > + union {
> > > > > > > > + struct
> > > > > > > > rte_flow_action_rss rss;
> > > > > > > > + struct {
> > > > > > > > + const struct
> > > > > > > > rte_eth_rss_conf *rss_conf;
> > > > > > > > + uint16_t num;
> > > > > > > > + uint16_t
> > > > > > > > queue[RTE_MAX_QUEUES_PER_PORT];
> > > > > > > > + } local;
> > > > > > > > + } action_rss;
> > > > > > > > + unsigned int i;
> > > > > > > > + unsigned int j;
> > > > > > > > +
> > > > > > > > + sa->action[2].type =
> > > > > > > > RTE_FLOW_ACTION_TYPE_END;
> > > > > > > > + /* Try RSS. */
> > > > > > > > + sa->action[1].type =
> > > > > > > > RTE_FLOW_ACTION_TYPE_RSS;
>
[dpdk-dev] [PATCH v2 1/5] pmdinfogen: fix cross compilation for ARM BE
Cross compiling DPDK for BE mode on ARM results into errors
"PMDINFO portal/dpaa2_hw_dpio.o.pmd.c No drivers registered"
The original code assumes the sh_size to be 32 bit, while it can
be Elf32_Word or Elf64_Xword based on 32bit or 64 bit systems.
This patches replaces the sh_size conversion routines to use ADDR_SIZE
Fixes: 98b0fdb0ffc6 ("pmdinfogen: add buildtools and pmdinfogen utility")
Cc: Neil Horman
Cc: sta...@dpdk.org
Signed-off-by: Jun Yang
Signed-off-by: Hemant Agrawal
Acked-by: Bruce Richardson
Acked-by: Neil Horman
--
v2: add descriptions and one more place for fix
buildtools/pmdinfogen/pmdinfogen.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/buildtools/pmdinfogen/pmdinfogen.c
b/buildtools/pmdinfogen/pmdinfogen.c
index 96ccbf3..b07dbcf 100644
--- a/buildtools/pmdinfogen/pmdinfogen.c
+++ b/buildtools/pmdinfogen/pmdinfogen.c
@@ -158,7 +158,8 @@ static int parse_elf(struct elf_info *info, const char
*filename)
* There are more than 64k sections,
* read count from .sh_size.
*/
- info->num_sections = TO_NATIVE(endian, 32, sechdrs[0].sh_size);
+ info->num_sections =
+ TO_NATIVE(endian, ADDR_SIZE, sechdrs[0].sh_size);
} else {
info->num_sections = hdr->e_shnum;
}
@@ -181,7 +182,7 @@ static int parse_elf(struct elf_info *info, const char
*filename)
sechdrs[i].sh_offset=
TO_NATIVE(endian, ADDR_SIZE, sechdrs[i].sh_offset);
sechdrs[i].sh_size =
- TO_NATIVE(endian, 32, sechdrs[i].sh_size);
+ TO_NATIVE(endian, ADDR_SIZE, sechdrs[i].sh_size);
sechdrs[i].sh_link =
TO_NATIVE(endian, 32, sechdrs[i].sh_link);
sechdrs[i].sh_info =
--
2.7.4
[dpdk-dev] [PATCH v2 4/5] net/i40e: fix compilation on ARM BE
This patch fixes the following error observed when
compiling with ARM BE compiler.
i40e_ethdev.c: In function ‘i40e_dev_tunnel_filter_set’:
i40e_ethdev.c:6988:5: error: lvalue required as unary ‘&’ operand
&rte_cpu_to_le_32(ipv4_addr),
Fixes: edc845bd53ec ("app/testpmd: fix build on FreeBSD")
Cc: Marvin Liu
Cc: sta...@dpdk.org
Signed-off-by: Hemant Agrawal
Acked-by: Beilei Xing
---
drivers/net/i40e/i40e_ethdev.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 811cc9f..a92933c 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -6951,7 +6951,7 @@ i40e_dev_tunnel_filter_set(struct i40e_pf *pf,
uint8_t add)
{
uint16_t ip_type;
- uint32_t ipv4_addr;
+ uint32_t ipv4_addr, ipv4_addr_le;
uint8_t i, tun_type = 0;
/* internal varialbe to convert ipv6 byte order */
uint32_t convert_ipv6[4];
@@ -6984,8 +6984,9 @@ i40e_dev_tunnel_filter_set(struct i40e_pf *pf,
if (tunnel_filter->ip_type == RTE_TUNNEL_IPTYPE_IPV4) {
ip_type = I40E_AQC_ADD_CLOUD_FLAGS_IPV4;
ipv4_addr = rte_be_to_cpu_32(tunnel_filter->ip_addr.ipv4_addr);
+ ipv4_addr_le = rte_cpu_to_le_32(ipv4_addr);
rte_memcpy(&pfilter->element.ipaddr.v4.data,
- &rte_cpu_to_le_32(ipv4_addr),
+ &ipv4_addr_le,
sizeof(pfilter->element.ipaddr.v4.data));
} else {
ip_type = I40E_AQC_ADD_CLOUD_FLAGS_IPV6;
@@ -7302,7 +7303,7 @@ i40e_dev_consistent_tunnel_filter_set(struct i40e_pf *pf,
uint8_t add)
{
uint16_t ip_type;
- uint32_t ipv4_addr;
+ uint32_t ipv4_addr, ipv4_addr_le;
uint8_t i, tun_type = 0;
/* internal variable to convert ipv6 byte order */
uint32_t convert_ipv6[4];
@@ -7338,8 +7339,9 @@ i40e_dev_consistent_tunnel_filter_set(struct i40e_pf *pf,
if (tunnel_filter->ip_type == I40E_TUNNEL_IPTYPE_IPV4) {
ip_type = I40E_AQC_ADD_CLOUD_FLAGS_IPV4;
ipv4_addr = rte_be_to_cpu_32(tunnel_filter->ip_addr.ipv4_addr);
+ ipv4_addr_le = rte_cpu_to_le_32(ipv4_addr);
rte_memcpy(&pfilter->element.ipaddr.v4.data,
- &rte_cpu_to_le_32(ipv4_addr),
+ &ipv4_addr_le,
sizeof(pfilter->element.ipaddr.v4.data));
} else {
ip_type = I40E_AQC_ADD_CLOUD_FLAGS_IPV6;
--
2.7.4
[dpdk-dev] [PATCH v2 5/5] net/ixgbe: fix compilation on ARM BE
fixes the following compilation error on compiling with ARM BE compiler
ixgbe_common.c: In function ‘ixgbe_host_interface_command’:
ixgbe_common.c:4610:22: error: passing argument 1 of
‘__builtin_bswap32’ makes integer from pointer without a cast
[-Werror=int-conversion]
IXGBE_LE32_TO_CPUS(&buffer[bi]);
^
Fixes: aa4fc14d2cee ("ixgbe: update base driver")
Cc: sta...@dpdk.org
Signed-off-by: Hemant Agrawal
Acked-by: Bruce Richardson
---
drivers/net/ixgbe/base/ixgbe_common.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ixgbe/base/ixgbe_common.c
b/drivers/net/ixgbe/base/ixgbe_common.c
index 7f85713..5e6ad95 100644
--- a/drivers/net/ixgbe/base/ixgbe_common.c
+++ b/drivers/net/ixgbe/base/ixgbe_common.c
@@ -4607,7 +4607,7 @@ s32 ixgbe_host_interface_command(struct ixgbe_hw *hw, u32
*buffer,
/* first pull in the header so we know the buffer length */
for (bi = 0; bi < dword_len; bi++) {
buffer[bi] = IXGBE_READ_REG_ARRAY(hw, IXGBE_FLEX_MNG, bi);
- IXGBE_LE32_TO_CPUS(&buffer[bi]);
+ IXGBE_LE32_TO_CPUS((uintptr_t)&buffer[bi]);
}
/* If there is any thing in data position pull it in */
@@ -4627,7 +4627,7 @@ s32 ixgbe_host_interface_command(struct ixgbe_hw *hw, u32
*buffer,
/* Pull in the rest of the buffer (bi is where we left off) */
for (; bi <= dword_len; bi++) {
buffer[bi] = IXGBE_READ_REG_ARRAY(hw, IXGBE_FLEX_MNG, bi);
- IXGBE_LE32_TO_CPUS(&buffer[bi]);
+ IXGBE_LE32_TO_CPUS((uintptr_t)&buffer[bi]);
}
rel_out:
--
2.7.4
[dpdk-dev] [PATCH v2 3/5] bus/dpaa: fix compilation on ARM BE
Fix the following compilation error when compiling
with ARM BE compiler.
drivers/bus/dpaa/include/fsl_qman.h:1997:25:
error: statement with no effect [-Werror=unused-value]
#define hw_sg_to_cpu(x) (x)
Fixes: c47ff048b99a ("bus/dpaa: add QMAN driver core routines")
Cc: sta...@dpdk.org
Signed-off-by: Hemant Agrawal
---
drivers/bus/dpaa/include/fsl_qman.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/bus/dpaa/include/fsl_qman.h
b/drivers/bus/dpaa/include/fsl_qman.h
index eedfd7e..72556dc 100644
--- a/drivers/bus/dpaa/include/fsl_qman.h
+++ b/drivers/bus/dpaa/include/fsl_qman.h
@@ -1993,8 +1993,8 @@ static inline int qman_poll_fq_for_init(struct qman_fq
*fq)
}
#if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
-#define cpu_to_hw_sg(x) (x)
-#define hw_sg_to_cpu(x) (x)
+#define cpu_to_hw_sg(x)
+#define hw_sg_to_cpu(x)
#else
#define cpu_to_hw_sg(x) __cpu_to_hw_sg(x)
#define hw_sg_to_cpu(x) __hw_sg_to_cpu(x)
--
2.7.4
[dpdk-dev] [PATCH v2 2/5] lpm: fix compilation on ARM BE
Compiling on ARM BE using Linaro toolchain caused following
error/warnings.
rte_lpm.c: In function ‘add_depth_big_v20’:
rte_lpm.c:911:4: error: braces around scalar initializer [-Werror]
{ .group_idx = (uint8_t)tbl8_group_index, },
^
rte_lpm.c:911:4: note: (near initialization for
‘new_tbl24_entry.depth’)
rte_lpm.c:911:6:error: field name not in record or union initializer
{ .group_idx = (uint8_t)tbl8_group_index, },
^
rte_lpm.c:911:6: note: (near initialization for
‘new_tbl24_entry.depth’)
rte_lpm.c:914:13: error: initialized field overwritten
[-Werror=override-init]
.depth = 0,
Fixes: dc81ebbacaeb ("lpm: extend IPv4 next hop field")
Cc: Michal Kobylinski
Cc: sta...@dpdk.org
Signed-off-by: Jun Yang
Signed-off-by: Hemant Agrawal
Acked-by: Bruce Richardson
---
v2: added endianess check in the assignments
lib/librte_lpm/rte_lpm.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/lib/librte_lpm/rte_lpm.c b/lib/librte_lpm/rte_lpm.c
index e1f1fad..a47c04f 100644
--- a/lib/librte_lpm/rte_lpm.c
+++ b/lib/librte_lpm/rte_lpm.c
@@ -912,10 +912,17 @@ add_depth_big_v20(struct rte_lpm_v20 *lpm, uint32_t
ip_masked, uint8_t depth,
*/
struct rte_lpm_tbl_entry_v20 new_tbl24_entry = {
+#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
{ .group_idx = (uint8_t)tbl8_group_index, },
.valid = VALID,
.valid_group = 1,
.depth = 0,
+#else
+ .depth = 0,
+ .valid_group = 1,
+ .valid = VALID,
+ { .group_idx = (uint8_t)tbl8_group_index, },
+#endif
};
lpm->tbl24[tbl24_index] = new_tbl24_entry;
@@ -958,10 +965,17 @@ add_depth_big_v20(struct rte_lpm_v20 *lpm, uint32_t
ip_masked, uint8_t depth,
*/
struct rte_lpm_tbl_entry_v20 new_tbl24_entry = {
+#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
{ .group_idx = (uint8_t)tbl8_group_index, },
.valid = VALID,
.valid_group = 1,
.depth = 0,
+#else
+ .depth = 0,
+ .valid_group = 1,
+ .valid = VALID,
+ { .group_idx = (uint8_t)tbl8_group_index, },
+#endif
};
lpm->tbl24[tbl24_index] = new_tbl24_entry;
@@ -1365,10 +1379,18 @@ delete_depth_small_v20(struct rte_lpm_v20 *lpm,
uint32_t ip_masked,
*/
struct rte_lpm_tbl_entry_v20 new_tbl24_entry = {
+#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
{.next_hop = lpm->rules_tbl[sub_rule_index].next_hop,},
.valid = VALID,
.valid_group = 0,
.depth = sub_rule_depth,
+#else
+ .depth = sub_rule_depth,
+ .valid_group = 0,
+ .valid = VALID,
+ { .next_hop = lpm->rules_tbl[sub_rule_index].next_hop,
},
+#endif
+
};
struct rte_lpm_tbl_entry_v20 new_tbl8_entry = {
@@ -1668,10 +1690,17 @@ delete_depth_big_v20(struct rte_lpm_v20 *lpm, uint32_t
ip_masked,
} else if (tbl8_recycle_index > -1) {
/* Update tbl24 entry. */
struct rte_lpm_tbl_entry_v20 new_tbl24_entry = {
+#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
{ .next_hop = lpm->tbl8[tbl8_recycle_index].next_hop, },
.valid = VALID,
.valid_group = 0,
.depth = lpm->tbl8[tbl8_recycle_index].depth,
+#else
+ .depth = lpm->tbl8[tbl8_recycle_index].depth,
+ .valid_group = 0,
+ .valid = VALID,
+ { .next_hop = lpm->tbl8[tbl8_recycle_index].next_hop, },
+#endif
};
/* Set tbl24 before freeing tbl8 to avoid race condition. */
--
2.7.4
Re: [dpdk-dev] [PATCH] net/failsafe: add Rx interrupts
Thank you Stephen,
Will gather more review inputs and send a fix.
Moti
> -Original Message-
> From: Stephen Hemminger [mailto:step...@networkplumber.org]
> Sent: Tuesday, December 12, 2017 3:34 AM
> To: Mordechay Haimovsky
> Cc: gaetan.ri...@6wind.com; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] net/failsafe: add Rx interrupts
>
> On Mon, 11 Dec 2017 14:41:47 +0200
> Moti Haimovsky wrote:
>
> > + for (i = 0; i < n; i++) {
> > + rxq = (struct rxq *)events[i].epdata.data;
>
> Minor nit. events[i].epdata.data is "void *" therefore cast is unnecessary.
[dpdk-dev] [PATCH] app/crypto-perf: support IMIX
Add support for IMIX performance tests, where a distribution
of various packet sizes can be submitted to a crypto
device, testing a closer to a real world scenario.
A sequence of packet sizes, selected randomly from a list of packet
sizes (with "buffer-sz" parameter) with a list of the weights
per packet size (using "imix" parameter), is generated
(the length of this sequence is the same length as the pool,
set with "pool-sz" parameter).
This sequence is used repeteadly for all the crypto
operations submitted to the crypto device (with "--total-ops" parameter).
Signed-off-by: Pablo de Lara
---
app/test-crypto-perf/cperf_ops.c | 77 ++--
app/test-crypto-perf/cperf_ops.h | 2 +-
app/test-crypto-perf/cperf_options.h | 4 ++
app/test-crypto-perf/cperf_options_parsing.c | 61 ++--
app/test-crypto-perf/cperf_test_latency.c| 4 +-
app/test-crypto-perf/cperf_test_pmd_cyclecount.c | 8 ++-
app/test-crypto-perf/cperf_test_throughput.c | 3 +-
app/test-crypto-perf/cperf_test_verify.c | 3 +-
app/test-crypto-perf/main.c | 89
doc/guides/tools/cryptoperf.rst | 14
10 files changed, 220 insertions(+), 45 deletions(-)
diff --git a/app/test-crypto-perf/cperf_ops.c b/app/test-crypto-perf/cperf_ops.c
index 23d30ca..e3c7ab4 100644
--- a/app/test-crypto-perf/cperf_ops.c
+++ b/app/test-crypto-perf/cperf_ops.c
@@ -41,7 +41,7 @@ cperf_set_ops_null_cipher(struct rte_crypto_op **ops,
uint16_t nb_ops, struct rte_cryptodev_sym_session *sess,
const struct cperf_options *options,
const struct cperf_test_vector *test_vector __rte_unused,
- uint16_t iv_offset __rte_unused)
+ uint16_t iv_offset __rte_unused, uint32_t *imix_idx)
{
uint16_t i;
@@ -62,7 +62,12 @@ cperf_set_ops_null_cipher(struct rte_crypto_op **ops,
dst_buf_offset);
/* cipher parameters */
- sym_op->cipher.data.length = options->test_buffer_size;
+ if (options->imix_distribution_count) {
+ sym_op->cipher.data.length =
+ options->imix_buffer_sizes[*imix_idx];
+ *imix_idx = (*imix_idx + 1) % options->pool_sz;
+ } else
+ sym_op->cipher.data.length = options->test_buffer_size;
sym_op->cipher.data.offset = 0;
}
@@ -75,7 +80,7 @@ cperf_set_ops_null_auth(struct rte_crypto_op **ops,
uint16_t nb_ops, struct rte_cryptodev_sym_session *sess,
const struct cperf_options *options,
const struct cperf_test_vector *test_vector __rte_unused,
- uint16_t iv_offset __rte_unused)
+ uint16_t iv_offset __rte_unused, uint32_t *imix_idx)
{
uint16_t i;
@@ -96,7 +101,12 @@ cperf_set_ops_null_auth(struct rte_crypto_op **ops,
dst_buf_offset);
/* auth parameters */
- sym_op->auth.data.length = options->test_buffer_size;
+ if (options->imix_distribution_count) {
+ sym_op->auth.data.length =
+ options->imix_buffer_sizes[*imix_idx];
+ *imix_idx = (*imix_idx + 1) % options->pool_sz;
+ } else
+ sym_op->auth.data.length = options->test_buffer_size;
sym_op->auth.data.offset = 0;
}
@@ -109,7 +119,7 @@ cperf_set_ops_cipher(struct rte_crypto_op **ops,
uint16_t nb_ops, struct rte_cryptodev_sym_session *sess,
const struct cperf_options *options,
const struct cperf_test_vector *test_vector,
- uint16_t iv_offset)
+ uint16_t iv_offset, uint32_t *imix_idx)
{
uint16_t i;
@@ -130,12 +140,17 @@ cperf_set_ops_cipher(struct rte_crypto_op **ops,
dst_buf_offset);
/* cipher parameters */
+ if (options->imix_distribution_count) {
+ sym_op->cipher.data.length =
+ options->imix_buffer_sizes[*imix_idx];
+ *imix_idx = (*imix_idx + 1) % options->pool_sz;
+ } else
+ sym_op->cipher.data.length = options->test_buffer_size;
+
if (options->cipher_algo == RTE_CRYPTO_CIPHER_SNOW3G_UEA2 ||
options->cipher_algo ==
RTE_CRYPTO_CIPHER_KASUMI_F8 ||
options->cipher_algo ==
RTE_CRYPTO_CIPHER_ZUC_EEA3)
- sym_op->cipher.data.length = options->test_buffer_size
<< 3;
- else
- sym_op->cipher.data.length = options->test_buffer
Re: [dpdk-dev] [PATCH v2 2/5] lpm: fix compilation on ARM BE
On Wed, Dec 13, 2017 at 06:22:55PM +0530, Hemant Agrawal wrote:
> Compiling on ARM BE using Linaro toolchain caused following
> error/warnings.
>
> rte_lpm.c: In function ‘add_depth_big_v20’:
> rte_lpm.c:911:4: error: braces around scalar initializer [-Werror]
> { .group_idx = (uint8_t)tbl8_group_index, },
> ^
> rte_lpm.c:911:4: note: (near initialization for
> ‘new_tbl24_entry.depth’)
> rte_lpm.c:911:6:error: field name not in record or union initializer
> { .group_idx = (uint8_t)tbl8_group_index, },
> ^
> rte_lpm.c:911:6: note: (near initialization for
> ‘new_tbl24_entry.depth’)
> rte_lpm.c:914:13: error: initialized field overwritten
> [-Werror=override-init]
> .depth = 0,
>
> Fixes: dc81ebbacaeb ("lpm: extend IPv4 next hop field")
> Cc: Michal Kobylinski
> Cc: sta...@dpdk.org
>
> Signed-off-by: Jun Yang
> Signed-off-by: Hemant Agrawal
> Acked-by: Bruce Richardson
> ---
> v2: added endianess check in the assignments
>
> lib/librte_lpm/rte_lpm.c | 29 +
> 1 file changed, 29 insertions(+)
>
> diff --git a/lib/librte_lpm/rte_lpm.c b/lib/librte_lpm/rte_lpm.c
> index e1f1fad..a47c04f 100644
> --- a/lib/librte_lpm/rte_lpm.c
> +++ b/lib/librte_lpm/rte_lpm.c
> @@ -912,10 +912,17 @@ add_depth_big_v20(struct rte_lpm_v20 *lpm, uint32_t
> ip_masked, uint8_t depth,
>*/
>
> struct rte_lpm_tbl_entry_v20 new_tbl24_entry = {
> +#if RTE_BYTE_ORDER == RTE_LITTLE_ENDIAN
> { .group_idx = (uint8_t)tbl8_group_index, },
> .valid = VALID,
> .valid_group = 1,
> .depth = 0,
> +#else
> + .depth = 0,
> + .valid_group = 1,
> + .valid = VALID,
> + { .group_idx = (uint8_t)tbl8_group_index, },
> +#endif
> };
>
I'm not I'd agree with this as a "better" fix. Were the issues with the
previous version of just removing the braces. All the ifdefs are rather
ugly.
Re: [dpdk-dev] [PATCH 0/6] next-build: create both static and shared libs
On Wed, Dec 13, 2017 at 12:10:52PM +, Luca Boccassi wrote: > On Tue, 2017-12-12 at 17:14 +, Bruce Richardson wrote: > > On Tue, Dec 12, 2017 at 04:59:34PM +, Bruce Richardson wrote: > > > This patchset changes the meson+ninja build system to always create > > > both > > > static and shared libraries when doing a build. The applications > > > compiled > > > as part of a build use either the shared or static libraries > > > depending on > > > what the default_library build setting is. > > > > > > NOTE: > > > The main difficulty with this change is adjusting the pkgconfig > > > file so > > > that external apps, like the examples, can be built using either > > > the static > > > or shared libraries. One of the key issues was the fact that > > > running > > > "pkg-config --static --libs libdpdk" outputs first the normal libs, > > > and > > > then the extra static ones. This is a problem because the driver > > > libs are > > > for static only builds, but need to come before, not after the > > > standard > > > DDPK libraries. It also procludes adding in the -Wl,-Bstatic flag > > > into the output for the standard libraries to link them statically. > > > > > > There were two options considered for mananging the pkg-config > > > settings. > > > 1. Creating a separate .pc file for static builds with exactly the > > > flags > > > needed. > > > 2. Modifying the single .pc file so that it was "good enough" to > > > enable > > > static builds without too much work. > > > > > > For this version of this set, I took option #2. To link using > > > dynamic libs, > > > all is as normal, to use static libs, the user needs to prepend > > > "-Wl,-Bstatic" before the "pkgconfig --static" library output. This > > > can be > > > seen in the changes to the example application makefiles, which now > > > support > > > building the examples using shared or static DPDK libs. > > > > > > > Just to emphasise that I'm looking for input into whether I took the > > right choice here. Option #1 has some advantages in that we can tune > > the > > output specifically for the static build case, but I wasn't sure > > whether > > it would be the done thing to have two different .pc files for a > > single > > package. Feedback from packagers welcome! > > > > /Bruce > > I don't link #1 too much - too "special". I think an additional flag is > more friendly. > Yes, it is not very neat indeed. The main advantage of it would include the fact that we could do away with all the -Wl,-Bstatic/-Bdynamic flags completely, and have the libs line just have the direct paths to the .a files. > A good solution would be a Cflags.private feature, sadly that is not > supported by pkgconfig despite many requests for it. > Not sure that would help. It's the ldflags that need to be special-cased, as far as I can see. > A possible way to sugar-coat it could be to add a custom variable, and > then instruct the users to do something like: > > $(shell pkg-config --variable=ldflags.static libdpdk) $(shell pkg- > config --static --libs libdpdk) > > Unfortunately, again, --variable cannot be used together with --libs in > the same call. Yes, that could work, but having the user specific a special variable from pkgconfig is just as much work as just telling the user to add -Wl,-Bstatic to their existing pkg-config lines. In any case, none of this is cast in stone. Even after this is merged, we can support #1 alongside this if that turns out to be easier for users. /Bruce
Re: [dpdk-dev] [PATCH 7/7] doc: update eventdev documentation
> -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Pavan Nikhilesh > Sent: Tuesday, December 12, 2017 7:27 PM > To: jerin.ja...@caviumnetworks.com; Richardson, Bruce > ; Van Haaren, Harry > ; Eads, Gage ; > hemant.agra...@nxp.com; nipun.gu...@nxp.com; Ma, Liang J > > Cc: dev@dpdk.org; Pavan Nikhilesh > Subject: [dpdk-dev] [PATCH 7/7] doc: update eventdev documentation > > Update octeontx and software eventdev documentation to include new selftest > feature. > > Signed-off-by: Pavan Nikhilesh Acked-by: Marko Kovacevic
Re: [dpdk-dev] [PATCH v3 2/2] examples/ipsec-secgw: add target queues in flow actions
Hi Nelio,
On 12/13/2017 06:23 PM, Nelio Laranjeiro wrote:
Hi Anoob,
On Wed, Dec 13, 2017 at 05:08:19PM +0530, Anoob Joseph wrote:
Hi Nelio,
On 12/13/2017 03:32 PM, Nelio Laranjeiro wrote:
Hi Anoob,
On Wed, Dec 13, 2017 at 12:11:18PM +0530, Anoob Joseph wrote:
Hi Nelio,
On 12/12/2017 08:08 PM, Nelio Laranjeiro wrote:
Hi Anoob,
On Tue, Dec 12, 2017 at 07:34:31PM +0530, Anoob Joseph wrote:
Hi Nelio,
On 12/12/2017 07:14 PM, Nelio Laranjeiro wrote:
Hi Anoob,
On Tue, Dec 12, 2017 at 06:13:08PM +0530, Anoob Joseph wrote:
Hi Nelio,
On 12/11/2017 07:34 PM, Nelio Laranjeiro wrote:
Mellanox INNOVA NIC needs to have final target queue actions to perform
inline crypto.
Signed-off-by: Nelio Laranjeiro
---
Changes in v3:
* removed PASSTHRU test for ingress.
* removed check on configured queues for the queue action.
Changes in v2:
* Test the rule by PASSTHRU/RSS/QUEUE and apply the first one validated.
---
examples/ipsec-secgw/ipsec.c | 57
++--
examples/ipsec-secgw/ipsec.h | 2 +-
2 files changed, 56 insertions(+), 3 deletions(-)
diff --git a/examples/ipsec-secgw/ipsec.c b/examples/ipsec-secgw/ipsec.c
index 17bd7620d..1b8b251c8 100644
--- a/examples/ipsec-secgw/ipsec.c
+++ b/examples/ipsec-secgw/ipsec.c
@@ -142,6 +142,7 @@ create_session(struct ipsec_ctx *ipsec_ctx, struct ipsec_sa
*sa)
rte_eth_dev_get_sec_ctx(
sa->portid);
const struct rte_security_capability *sec_cap;
+ int ret = 0;
sa->sec_session = rte_security_session_create(ctx,
&sess_conf, ipsec_ctx->session_pool);
@@ -201,15 +202,67 @@ create_session(struct ipsec_ctx *ipsec_ctx, struct
ipsec_sa *sa)
sa->action[0].type = RTE_FLOW_ACTION_TYPE_SECURITY;
sa->action[0].conf = sa->sec_session;
- sa->action[1].type = RTE_FLOW_ACTION_TYPE_END;
-
sa->attr.egress = (sa->direction ==
RTE_SECURITY_IPSEC_SA_DIR_EGRESS);
sa->attr.ingress = (sa->direction ==
RTE_SECURITY_IPSEC_SA_DIR_INGRESS);
+ if (sa->attr.ingress) {
+ uint8_t rss_key[40];
+ struct rte_eth_rss_conf rss_conf = {
+ .rss_key = rss_key,
+ .rss_key_len = 40,
+ };
+ struct rte_eth_dev *eth_dev;
+ union {
+ struct rte_flow_action_rss rss;
+ struct {
+ const struct rte_eth_rss_conf *rss_conf;
+ uint16_t num;
+ uint16_t queue[RTE_MAX_QUEUES_PER_PORT];
+ } local;
+ } action_rss;
+ unsigned int i;
+ unsigned int j;
+
+ sa->action[2].type = RTE_FLOW_ACTION_TYPE_END;
+ /* Try RSS. */
+ sa->action[1].type = RTE_FLOW_ACTION_TYPE_RSS;
+ sa->action[1].conf = &action_rss;
+ eth_dev = ctx->device;
+ rte_eth_dev_rss_hash_conf_get(sa->portid,
+ &rss_conf);
+ for (i = 0, j = 0;
+i < eth_dev->data->nb_rx_queues; ++i)
+ if (eth_dev->data->rx_queues[i])
+ action_rss.local.queue[j++] = i;
+ action_rss.local.num = j;
+ action_rss.local.rss_conf = &rss_conf;
+ ret = rte_flow_validate(sa->portid, &sa->attr,
+ sa->pattern, sa->action,
+ &err);
+ if (!ret)
+ goto flow_create;
+ /* Try Queue. */
+ sa->action[1].type = RTE_FLOW_ACTION_TYPE_QUEUE;
+ sa->action[1].conf =
+ &(struct rte_flow_action_queue){
+ .index = 0,
+ };
+ ret = rte_flow_validate(sa->portid, &sa->attr,
+
[dpdk-dev] [PATCH 0/5] crypto/dpaa_sec: performance optimizations
Following changes are added to improve performance. 1. optimize virtual to physical address conversion 2. support for multiple sessions in a single queue pair 3. support for ipsec protocol offload 4. enqueue/dequeue code is rewritten to optimize the data path. Akhil Goyal (3): crypto/dpaa_sec: support ipsec protocol offload bus/dpaa: support for enqueue frames of multiple queues crypto/dpaa_sec: rewrite Rx/Tx path Hemant Agrawal (2): crypto/dpaa_sec: optimize virt to phy conversion crypto/dpaa_sec: support multiple sessions per qp doc/guides/cryptodevs/features/dpaa_sec.ini | 1 + drivers/bus/dpaa/base/qbman/qman.c | 66 +++ drivers/bus/dpaa/include/fsl_qman.h | 14 + drivers/bus/dpaa/rte_bus_dpaa_version.map | 1 + drivers/crypto/dpaa_sec/dpaa_sec.c | 804 ++-- drivers/crypto/dpaa_sec/dpaa_sec.h | 137 +++-- 6 files changed, 823 insertions(+), 200 deletions(-) -- 2.9.3
[dpdk-dev] [PATCH 1/5] crypto/dpaa_sec: optimize virt to phy conversion
From: Hemant Agrawal
Context memory is allocated from mempool. Ideally
it will get all memory from single segment, so simple offset
calculation is used for address conversion for such addresses
from context memory.
Signed-off-by: Hemant Agrawal
Acked-by: Akhil Goyal
---
drivers/crypto/dpaa_sec/dpaa_sec.c | 27 ++-
drivers/crypto/dpaa_sec/dpaa_sec.h | 1 +
2 files changed, 19 insertions(+), 9 deletions(-)
diff --git a/drivers/crypto/dpaa_sec/dpaa_sec.c
b/drivers/crypto/dpaa_sec/dpaa_sec.c
index 16155b1..a1271be 100644
--- a/drivers/crypto/dpaa_sec/dpaa_sec.c
+++ b/drivers/crypto/dpaa_sec/dpaa_sec.c
@@ -106,6 +106,8 @@ dpaa_sec_alloc_ctx(dpaa_sec_session *ses)
dcbz_64(&ctx->job.sg[SG_CACHELINE_3]);
ctx->ctx_pool = ses->ctx_pool;
+ ctx->vtop_offset = (uint64_t) ctx
+ - rte_mempool_virt2iova(ctx);
return ctx;
}
@@ -130,6 +132,13 @@ dpaa_mem_vtop(void *vaddr)
return (rte_iova_t)(NULL);
}
+/* virtual address conversin when mempool support is available for ctx */
+static inline phys_addr_t
+dpaa_mem_vtop_ctx(struct dpaa_sec_op_ctx *ctx, void *vaddr)
+{
+ return (uint64_t)vaddr - ctx->vtop_offset;
+}
+
static inline void *
dpaa_mem_ptov(rte_iova_t paddr)
{
@@ -589,7 +598,7 @@ build_auth_only(struct rte_crypto_op *op, dpaa_sec_session
*ses)
if (is_decode(ses)) {
/* need to extend the input to a compound frame */
sg->extension = 1;
- qm_sg_entry_set64(sg, dpaa_mem_vtop(&cf->sg[2]));
+ qm_sg_entry_set64(sg, dpaa_mem_vtop_ctx(ctx, &cf->sg[2]));
sg->length = sym->auth.data.length + ses->digest_length;
sg->final = 1;
cpu_to_hw_sg(sg);
@@ -603,7 +612,7 @@ build_auth_only(struct rte_crypto_op *op, dpaa_sec_session
*ses)
cpu_to_hw_sg(sg);
/* let's check digest by hw */
- start_addr = dpaa_mem_vtop(old_digest);
+ start_addr = dpaa_mem_vtop_ctx(ctx, old_digest);
sg++;
qm_sg_entry_set64(sg, start_addr);
sg->length = ses->digest_length;
@@ -657,7 +666,7 @@ build_cipher_only(struct rte_crypto_op *op,
dpaa_sec_session *ses)
sg->extension = 1;
sg->final = 1;
sg->length = sym->cipher.data.length + ses->iv.length;
- qm_sg_entry_set64(sg, dpaa_mem_vtop(&cf->sg[2]));
+ qm_sg_entry_set64(sg, dpaa_mem_vtop_ctx(ctx, &cf->sg[2]));
cpu_to_hw_sg(sg);
sg = &cf->sg[2];
@@ -703,7 +712,7 @@ build_cipher_auth_gcm(struct rte_crypto_op *op,
dpaa_sec_session *ses)
/* input */
rte_prefetch0(cf->sg);
sg = &cf->sg[2];
- qm_sg_entry_set64(&cf->sg[1], dpaa_mem_vtop(sg));
+ qm_sg_entry_set64(&cf->sg[1], dpaa_mem_vtop_ctx(ctx, sg));
if (is_encode(ses)) {
qm_sg_entry_set64(sg, dpaa_mem_vtop(IV_ptr));
sg->length = ses->iv.length;
@@ -748,7 +757,7 @@ build_cipher_auth_gcm(struct rte_crypto_op *op,
dpaa_sec_session *ses)
ses->digest_length);
sg++;
- qm_sg_entry_set64(sg, dpaa_mem_vtop(ctx->digest));
+ qm_sg_entry_set64(sg, dpaa_mem_vtop_ctx(ctx, ctx->digest));
sg->length = ses->digest_length;
length += sg->length;
sg->final = 1;
@@ -762,7 +771,7 @@ build_cipher_auth_gcm(struct rte_crypto_op *op,
dpaa_sec_session *ses)
/* output */
sg++;
- qm_sg_entry_set64(&cf->sg[0], dpaa_mem_vtop(sg));
+ qm_sg_entry_set64(&cf->sg[0], dpaa_mem_vtop_ctx(ctx, sg));
qm_sg_entry_set64(sg,
dst_start_addr + sym->aead.data.offset - ses->auth_only_len);
sg->length = sym->aead.data.length + ses->auth_only_len;
@@ -814,7 +823,7 @@ build_cipher_auth(struct rte_crypto_op *op,
dpaa_sec_session *ses)
/* input */
rte_prefetch0(cf->sg);
sg = &cf->sg[2];
- qm_sg_entry_set64(&cf->sg[1], dpaa_mem_vtop(sg));
+ qm_sg_entry_set64(&cf->sg[1], dpaa_mem_vtop_ctx(ctx, sg));
if (is_encode(ses)) {
qm_sg_entry_set64(sg, dpaa_mem_vtop(IV_ptr));
sg->length = ses->iv.length;
@@ -844,7 +853,7 @@ build_cipher_auth(struct rte_crypto_op *op,
dpaa_sec_session *ses)
ses->digest_length);
sg++;
- qm_sg_entry_set64(sg, dpaa_mem_vtop(ctx->digest));
+ qm_sg_entry_set64(sg, dpaa_mem_vtop_ctx(ctx, ctx->digest));
sg->length = ses->digest_length;
length += sg->length;
sg->final = 1;
@@ -858,7 +867,7 @@ build_cipher_auth(struct rte_crypto_op *op,
dpaa_sec_session *ses)
/* output */
sg++;
- qm_sg_entry_set64(&cf->sg[0], dpaa_mem_vtop(sg));
+ qm_sg_entry_set64(&cf->sg[0], dpaa_mem_vtop_ctx(ctx, sg));
qm_sg_entry_set64(sg, dst_start_addr + sym->cip
[dpdk-dev] [PATCH 2/5] crypto/dpaa_sec: support multiple sessions per qp
From: Hemant Agrawal
Signed-off-by: Hemant Agrawal
Acked-by: Akhil Goyal
---
drivers/crypto/dpaa_sec/dpaa_sec.c | 154 +
drivers/crypto/dpaa_sec/dpaa_sec.h | 74 +-
2 files changed, 145 insertions(+), 83 deletions(-)
diff --git a/drivers/crypto/dpaa_sec/dpaa_sec.c
b/drivers/crypto/dpaa_sec/dpaa_sec.c
index a1271be..b51db83 100644
--- a/drivers/crypto/dpaa_sec/dpaa_sec.c
+++ b/drivers/crypto/dpaa_sec/dpaa_sec.c
@@ -69,6 +69,9 @@ static uint8_t cryptodev_driver_id;
static __thread struct rte_crypto_op **dpaa_sec_ops;
static __thread int dpaa_sec_op_nb;
+static int
+dpaa_sec_attach_sess_q(struct dpaa_sec_qp *qp, dpaa_sec_session *sess);
+
static inline void
dpaa_sec_op_ending(struct dpaa_sec_op_ctx *ctx)
{
@@ -177,15 +180,6 @@ dpaa_sec_init_rx(struct qman_fq *fq_in, rte_iova_t hwdesc,
/* Clear FQ options */
memset(&fq_opts, 0x00, sizeof(struct qm_mcc_initfq));
- flags = QMAN_FQ_FLAG_LOCKED | QMAN_FQ_FLAG_DYNAMIC_FQID |
- QMAN_FQ_FLAG_TO_DCPORTAL;
-
- ret = qman_create_fq(0, flags, fq_in);
- if (unlikely(ret != 0)) {
- PMD_INIT_LOG(ERR, "qman_create_fq failed");
- return ret;
- }
-
flags = QMAN_INITFQ_FLAG_SCHED;
fq_opts.we_mask = QM_INITFQ_WE_DESTWQ | QM_INITFQ_WE_CONTEXTA |
QM_INITFQ_WE_CONTEXTB;
@@ -197,9 +191,11 @@ dpaa_sec_init_rx(struct qman_fq *fq_in, rte_iova_t hwdesc,
fq_in->cb.ern = ern_sec_fq_handler;
+ PMD_INIT_LOG(DEBUG, "in-%x out-%x", fq_in->fqid, fqid_out);
+
ret = qman_init_fq(fq_in, flags, &fq_opts);
if (unlikely(ret != 0))
- PMD_INIT_LOG(ERR, "qman_init_fq failed");
+ PMD_INIT_LOG(ERR, "qman_init_fq failed %d", ret);
return ret;
}
@@ -383,7 +379,7 @@ dpaa_sec_prep_cdb(dpaa_sec_session *ses)
{
struct alginfo alginfo_c = {0}, alginfo_a = {0}, alginfo = {0};
uint32_t shared_desc_len = 0;
- struct sec_cdb *cdb = &ses->qp->cdb;
+ struct sec_cdb *cdb = &ses->cdb;
int err;
#if RTE_BYTE_ORDER == RTE_BIG_ENDIAN
int swap = false;
@@ -903,12 +899,10 @@ dpaa_sec_enqueue_op(struct rte_crypto_op *op, struct
dpaa_sec_qp *qp)
ses = (dpaa_sec_session *)get_session_private_data(op->sym->session,
cryptodev_driver_id);
- if (unlikely(!qp->ses || qp->ses != ses)) {
- qp->ses = ses;
- ses->qp = qp;
- ret = dpaa_sec_prep_cdb(ses);
- if (ret)
- return ret;
+ if (unlikely(!ses->qp || ses->qp != qp)) {
+ PMD_INIT_LOG(DEBUG, "sess->qp - %p qp %p", ses->qp, qp);
+ if (dpaa_sec_attach_sess_q(qp, ses))
+ return -1;
}
/*
@@ -944,7 +938,7 @@ dpaa_sec_enqueue_op(struct rte_crypto_op *op, struct
dpaa_sec_qp *qp)
if (auth_only_len)
fd.cmd = 0x8000 | auth_only_len;
do {
- ret = qman_enqueue(&qp->inq, &fd, 0);
+ ret = qman_enqueue(ses->inq, &fd, 0);
} while (ret != 0);
return 0;
@@ -1160,43 +1154,82 @@ dpaa_sec_aead_init(struct rte_cryptodev *dev
__rte_unused,
return 0;
}
-static int
-dpaa_sec_qp_attach_sess(struct rte_cryptodev *dev, uint16_t qp_id, void *ses)
+static struct qman_fq *
+dpaa_sec_attach_rxq(struct dpaa_sec_dev_private *qi)
{
- dpaa_sec_session *sess = ses;
- struct dpaa_sec_qp *qp;
+ unsigned int i;
- PMD_INIT_FUNC_TRACE();
+ for (i = 0; i < qi->max_nb_sessions; i++) {
+ if (qi->inq_attach[i] == 0) {
+ qi->inq_attach[i] = 1;
+ return &qi->inq[i];
+ }
+ }
+ PMD_DRV_LOG(ERR, "All ses session in use %x", qi->max_nb_sessions);
+
+ return NULL;
+}
- qp = dev->data->queue_pairs[qp_id];
- if (qp->ses != NULL) {
- PMD_INIT_LOG(ERR, "qp in-use by another session\n");
- return -EBUSY;
+static int
+dpaa_sec_detach_rxq(struct dpaa_sec_dev_private *qi, struct qman_fq *fq)
+{
+ unsigned int i;
+
+ for (i = 0; i < qi->max_nb_sessions; i++) {
+ if (&qi->inq[i] == fq) {
+ qi->inq_attach[i] = 0;
+ return 0;
+ }
}
+ return -1;
+}
+
+static int
+dpaa_sec_attach_sess_q(struct dpaa_sec_qp *qp, dpaa_sec_session *sess)
+{
+ int ret;
- qp->ses = sess;
sess->qp = qp;
+ ret = dpaa_sec_prep_cdb(sess);
+ if (ret) {
+ PMD_DRV_LOG(ERR, "Unable to prepare sec cdb");
+ return -1;
+ }
- return dpaa_sec_prep_cdb(sess);
+ ret = dpaa_sec_init_rx(sess->inq, dpaa_mem_vtop(&sess->cdb),
+ qman_fq_fqid(&qp->outq));
+ if (ret)
+ PMD_DRV_LOG(ERR, "Unable to init
[dpdk-dev] [PATCH 4/5] bus/dpaa: support for enqueue frames of multiple queues
Signed-off-by: Akhil Goyal
Signed-off-by: Nipun Gupta
---
drivers/bus/dpaa/base/qbman/qman.c| 66 +++
drivers/bus/dpaa/include/fsl_qman.h | 14 +++
drivers/bus/dpaa/rte_bus_dpaa_version.map | 1 +
3 files changed, 81 insertions(+)
diff --git a/drivers/bus/dpaa/base/qbman/qman.c
b/drivers/bus/dpaa/base/qbman/qman.c
index 9faf25f..6b7cbf6 100644
--- a/drivers/bus/dpaa/base/qbman/qman.c
+++ b/drivers/bus/dpaa/base/qbman/qman.c
@@ -2082,6 +2082,72 @@ int qman_enqueue_multi(struct qman_fq *fq,
return sent;
}
+int
+qman_enqueue_multi_fq(struct qman_fq *fq[], const struct qm_fd *fd,
+ int frames_to_send)
+{
+ struct qman_portal *p = get_affine_portal();
+ struct qm_portal *portal = &p->p;
+
+ register struct qm_eqcr *eqcr = &portal->eqcr;
+ struct qm_eqcr_entry *eq = eqcr->cursor, *prev_eq;
+
+ u8 i, diff, old_ci, sent = 0;
+
+ /* Update the available entries if no entry is free */
+ if (!eqcr->available) {
+ old_ci = eqcr->ci;
+ eqcr->ci = qm_cl_in(EQCR_CI) & (QM_EQCR_SIZE - 1);
+ diff = qm_cyc_diff(QM_EQCR_SIZE, old_ci, eqcr->ci);
+ eqcr->available += diff;
+ if (!diff)
+ return 0;
+ }
+
+ /* try to send as many frames as possible */
+ while (eqcr->available && frames_to_send--) {
+ eq->fqid = fq[sent]->fqid_le;
+ eq->fd.opaque_addr = fd->opaque_addr;
+ eq->fd.addr = cpu_to_be40(fd->addr);
+ eq->fd.status = cpu_to_be32(fd->status);
+ eq->fd.opaque = cpu_to_be32(fd->opaque);
+
+ eq = (void *)((unsigned long)(eq + 1) &
+ (~(unsigned long)(QM_EQCR_SIZE << 6)));
+ eqcr->available--;
+ sent++;
+ fd++;
+ }
+ lwsync();
+
+ /* In order for flushes to complete faster, all lines are recorded in
+* 32 bit word.
+*/
+ eq = eqcr->cursor;
+ for (i = 0; i < sent; i++) {
+ eq->__dont_write_directly__verb =
+ QM_EQCR_VERB_CMD_ENQUEUE | eqcr->vbit;
+ prev_eq = eq;
+ eq = (void *)((unsigned long)(eq + 1) &
+ (~(unsigned long)(QM_EQCR_SIZE << 6)));
+ if (unlikely((prev_eq + 1) != eq))
+ eqcr->vbit ^= QM_EQCR_VERB_VBIT;
+ }
+
+ /* We need to flush all the lines but without load/store operations
+* between them
+*/
+ eq = eqcr->cursor;
+ for (i = 0; i < sent; i++) {
+ dcbf(eq);
+ eq = (void *)((unsigned long)(eq + 1) &
+ (~(unsigned long)(QM_EQCR_SIZE << 6)));
+ }
+ /* Update cursor for the next call */
+ eqcr->cursor = eq;
+ return sent;
+}
+
int qman_enqueue_orp(struct qman_fq *fq, const struct qm_fd *fd, u32 flags,
struct qman_fq *orp, u16 orp_seqnum)
{
diff --git a/drivers/bus/dpaa/include/fsl_qman.h
b/drivers/bus/dpaa/include/fsl_qman.h
index 9090b63..6d935d8 100644
--- a/drivers/bus/dpaa/include/fsl_qman.h
+++ b/drivers/bus/dpaa/include/fsl_qman.h
@@ -1724,6 +1724,20 @@ int qman_enqueue_multi(struct qman_fq *fq,
const struct qm_fd *fd,
int frames_to_send);
+/**
+ * qman_enqueue_multi_fq - Enqueue multiple frames to their respective frame
+ * queues.
+ * @fq[]: Array of frame queue objects to enqueue to
+ * @fd: pointer to first descriptor of frame to be enqueued
+ * @frames_to_send: number of frames to be sent.
+ *
+ * This API is similar to qman_enqueue_multi(), but it takes fd which needs
+ * to be processed by different frame queues.
+ */
+int
+qman_enqueue_multi_fq(struct qman_fq *fq[], const struct qm_fd *fd,
+ int frames_to_send);
+
typedef int (*qman_cb_precommit) (void *arg);
/**
diff --git a/drivers/bus/dpaa/rte_bus_dpaa_version.map
b/drivers/bus/dpaa/rte_bus_dpaa_version.map
index 5fa975c..d440f91 100644
--- a/drivers/bus/dpaa/rte_bus_dpaa_version.map
+++ b/drivers/bus/dpaa/rte_bus_dpaa_version.map
@@ -72,6 +72,7 @@ DPDK_18.02 {
qman_alloc_cgrid_range;
qman_create_cgr;
qman_delete_cgr;
+ qman_enqueue_multi_fq;
qman_query_fq_frm_cnt;
qman_release_cgrid_range;
rte_dpaa_portal_fq_close;
--
2.9.3
[dpdk-dev] [PATCH 3/5] crypto/dpaa_sec: support ipsec protocol offload
Signed-off-by: Akhil Goyal
---
doc/guides/cryptodevs/features/dpaa_sec.ini | 1 +
drivers/crypto/dpaa_sec/dpaa_sec.c | 409 ++--
drivers/crypto/dpaa_sec/dpaa_sec.h | 62 -
3 files changed, 449 insertions(+), 23 deletions(-)
diff --git a/doc/guides/cryptodevs/features/dpaa_sec.ini
b/doc/guides/cryptodevs/features/dpaa_sec.ini
index 0e8f5b2..deab53a 100644
--- a/doc/guides/cryptodevs/features/dpaa_sec.ini
+++ b/doc/guides/cryptodevs/features/dpaa_sec.ini
@@ -7,6 +7,7 @@
Symmetric crypto = Y
Sym operation chaining = Y
HW Accelerated = Y
+Protocol offload = Y
;
; Supported crypto algorithms of the 'dpaa_sec' crypto driver.
diff --git a/drivers/crypto/dpaa_sec/dpaa_sec.c
b/drivers/crypto/dpaa_sec/dpaa_sec.c
index b51db83..ea744e6 100644
--- a/drivers/crypto/dpaa_sec/dpaa_sec.c
+++ b/drivers/crypto/dpaa_sec/dpaa_sec.c
@@ -41,6 +41,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -222,8 +223,19 @@ dqrr_out_fq_cb_rx(struct qman_portal *qm __always_unused,
* sg[1] for input
*/
job = dpaa_mem_ptov(qm_fd_addr_get64(fd));
+
ctx = container_of(job, struct dpaa_sec_op_ctx, job);
ctx->fd_status = fd->status;
+ if (ctx->op->sess_type == RTE_CRYPTO_OP_SECURITY_SESSION) {
+ struct qm_sg_entry *sg_out;
+ uint32_t len;
+
+ sg_out = &job->sg[0];
+ hw_sg_to_cpu(sg_out);
+ len = sg_out->length;
+ ctx->op->sym->m_src->pkt_len = len;
+ ctx->op->sym->m_src->data_len = len;
+ }
dpaa_sec_ops[dpaa_sec_op_nb++] = ctx->op;
dpaa_sec_op_ending(ctx);
@@ -287,7 +299,13 @@ static inline int is_aead(dpaa_sec_session *ses)
static inline int is_auth_cipher(dpaa_sec_session *ses)
{
return ((ses->cipher_alg != RTE_CRYPTO_CIPHER_NULL) &&
- (ses->auth_alg != RTE_CRYPTO_AUTH_NULL));
+ (ses->auth_alg != RTE_CRYPTO_AUTH_NULL) &&
+ (ses->proto_alg != RTE_SECURITY_PROTOCOL_IPSEC));
+}
+
+static inline int is_proto_ipsec(dpaa_sec_session *ses)
+{
+ return (ses->proto_alg == RTE_SECURITY_PROTOCOL_IPSEC);
}
static inline int is_encode(dpaa_sec_session *ses)
@@ -308,27 +326,39 @@ caam_auth_alg(dpaa_sec_session *ses, struct alginfo
*alginfo_a)
ses->digest_length = 0;
break;
case RTE_CRYPTO_AUTH_MD5_HMAC:
- alginfo_a->algtype = OP_ALG_ALGSEL_MD5;
+ alginfo_a->algtype =
+ (ses->proto_alg == RTE_SECURITY_PROTOCOL_IPSEC) ?
+ OP_PCL_IPSEC_HMAC_MD5_96 : OP_ALG_ALGSEL_MD5;
alginfo_a->algmode = OP_ALG_AAI_HMAC;
break;
case RTE_CRYPTO_AUTH_SHA1_HMAC:
- alginfo_a->algtype = OP_ALG_ALGSEL_SHA1;
+ alginfo_a->algtype =
+ (ses->proto_alg == RTE_SECURITY_PROTOCOL_IPSEC) ?
+ OP_PCL_IPSEC_HMAC_SHA1_96 : OP_ALG_ALGSEL_SHA1;
alginfo_a->algmode = OP_ALG_AAI_HMAC;
break;
case RTE_CRYPTO_AUTH_SHA224_HMAC:
- alginfo_a->algtype = OP_ALG_ALGSEL_SHA224;
+ alginfo_a->algtype =
+ (ses->proto_alg == RTE_SECURITY_PROTOCOL_IPSEC) ?
+ OP_PCL_IPSEC_HMAC_SHA1_160 : OP_ALG_ALGSEL_SHA224;
alginfo_a->algmode = OP_ALG_AAI_HMAC;
break;
case RTE_CRYPTO_AUTH_SHA256_HMAC:
- alginfo_a->algtype = OP_ALG_ALGSEL_SHA256;
+ alginfo_a->algtype =
+ (ses->proto_alg == RTE_SECURITY_PROTOCOL_IPSEC) ?
+ OP_PCL_IPSEC_HMAC_SHA2_256_128 : OP_ALG_ALGSEL_SHA256;
alginfo_a->algmode = OP_ALG_AAI_HMAC;
break;
case RTE_CRYPTO_AUTH_SHA384_HMAC:
- alginfo_a->algtype = OP_ALG_ALGSEL_SHA384;
+ alginfo_a->algtype =
+ (ses->proto_alg == RTE_SECURITY_PROTOCOL_IPSEC) ?
+ OP_PCL_IPSEC_HMAC_SHA2_384_192 : OP_ALG_ALGSEL_SHA384;
alginfo_a->algmode = OP_ALG_AAI_HMAC;
break;
case RTE_CRYPTO_AUTH_SHA512_HMAC:
- alginfo_a->algtype = OP_ALG_ALGSEL_SHA512;
+ alginfo_a->algtype =
+ (ses->proto_alg == RTE_SECURITY_PROTOCOL_IPSEC) ?
+ OP_PCL_IPSEC_HMAC_SHA2_512_256 : OP_ALG_ALGSEL_SHA512;
alginfo_a->algmode = OP_ALG_AAI_HMAC;
break;
default:
@@ -343,15 +373,21 @@ caam_cipher_alg(dpaa_sec_session *ses, struct alginfo
*alginfo_c)
case RTE_CRYPTO_CIPHER_NULL:
break;
case RTE_CRYPTO_CIPHER_AES_CBC:
- alginfo_c->algtype = OP_ALG_ALGSEL_AES;
+ alginfo_c->algtype =
+ (ses->proto_alg == RTE_SECURITY_PROTOCOL_IPSEC) ?
+
[dpdk-dev] [PATCH 5/5] crypto/dpaa_sec: rewrite Rx/Tx path
Rx and Tx patch are rewritten with improved internal APIs
to improve performance.
Signed-off-by: Akhil Goyal
Signed-off-by: Nipun Gupta
---
drivers/crypto/dpaa_sec/dpaa_sec.c | 260 ++---
drivers/crypto/dpaa_sec/dpaa_sec.h | 2 +-
2 files changed, 153 insertions(+), 109 deletions(-)
diff --git a/drivers/crypto/dpaa_sec/dpaa_sec.c
b/drivers/crypto/dpaa_sec/dpaa_sec.c
index ea744e6..b650d5c 100644
--- a/drivers/crypto/dpaa_sec/dpaa_sec.c
+++ b/drivers/crypto/dpaa_sec/dpaa_sec.c
@@ -563,46 +563,67 @@ dpaa_sec_prep_cdb(dpaa_sec_session *ses)
return 0;
}
-static inline unsigned int
-dpaa_volatile_deq(struct qman_fq *fq, unsigned int len, bool exact)
-{
- unsigned int pkts = 0;
- int ret;
- struct qm_mcr_queryfq_np np;
- enum qman_fq_state state;
- uint32_t flags;
- uint32_t vdqcr;
-
- qman_query_fq_np(fq, &np);
- if (np.frm_cnt) {
- vdqcr = QM_VDQCR_NUMFRAMES_SET(len);
- if (exact)
- vdqcr |= QM_VDQCR_EXACT;
- ret = qman_volatile_dequeue(fq, 0, vdqcr);
- if (ret)
- return 0;
- do {
- pkts += qman_poll_dqrr(len);
- qman_fq_state(fq, &state, &flags);
- } while (flags & QMAN_FQ_STATE_VDQCR);
- }
- return pkts;
-}
-
+#define DPAA_MAX_DEQUEUE_NUM_FRAMES 32
/* qp is lockless, should be accessed by only one thread */
static int
dpaa_sec_deq(struct dpaa_sec_qp *qp, struct rte_crypto_op **ops, int nb_ops)
{
struct qman_fq *fq;
+ unsigned int pkts = 0;
+ int ret;
+ struct qm_dqrr_entry *dq;
fq = &qp->outq;
- dpaa_sec_op_nb = 0;
- dpaa_sec_ops = ops;
+ ret = qman_set_vdq(fq, (nb_ops > DPAA_MAX_DEQUEUE_NUM_FRAMES) ?
+ DPAA_MAX_DEQUEUE_NUM_FRAMES : nb_ops);
+ if (ret)
+ return 0;
+
+ do {
+ const struct qm_fd *fd;
+ struct dpaa_sec_job *job;
+ struct dpaa_sec_op_ctx *ctx;
+ struct rte_crypto_op *op;
+
+ dq = qman_dequeue(fq);
+ if (!dq)
+ continue;
+
+ fd = &dq->fd;
+ /* sg is embedded in an op ctx,
+* sg[0] is for output
+* sg[1] for input
+*/
+ job = dpaa_mem_ptov(qm_fd_addr_get64(fd));
+
+ ctx = container_of(job, struct dpaa_sec_op_ctx, job);
+ ctx->fd_status = fd->status;
+ op = ctx->op;
+ if (op->sess_type == RTE_CRYPTO_OP_SECURITY_SESSION) {
+ struct qm_sg_entry *sg_out;
+ uint32_t len;
+
+ sg_out = &job->sg[0];
+ hw_sg_to_cpu(sg_out);
+ len = sg_out->length;
+ op->sym->m_src->pkt_len = len;
+ op->sym->m_src->data_len = len;
+ }
+ if (!ctx->fd_status) {
+ op->status = RTE_CRYPTO_OP_STATUS_SUCCESS;
+ } else {
+ printf("\nSEC return err: 0x%x", ctx->fd_status);
+ op->status = RTE_CRYPTO_OP_STATUS_ERROR;
+ }
+ ops[pkts++] = op;
- if (unlikely(nb_ops > DPAA_SEC_BURST))
- nb_ops = DPAA_SEC_BURST;
+ /* report op status to sym->op and then free the ctx memeory */
+ rte_mempool_put(ctx->ctx_pool, (void *)ctx);
- return dpaa_volatile_deq(fq, nb_ops, 1);
+ qman_dqrr_consume(fq, dq);
+ } while (fq->flags & QMAN_FQ_STATE_VDQCR);
+
+ return pkts;
}
/**
@@ -975,95 +996,118 @@ build_proto(struct rte_crypto_op *op, dpaa_sec_session
*ses)
return cf;
}
-static int
-dpaa_sec_enqueue_op(struct rte_crypto_op *op, struct dpaa_sec_qp *qp)
-{
- struct dpaa_sec_job *cf;
- dpaa_sec_session *ses;
- struct qm_fd fd;
- int ret;
- uint32_t auth_only_len = op->sym->auth.data.length -
- op->sym->cipher.data.length;
-
- if (op->sess_type == RTE_CRYPTO_OP_WITH_SESSION)
- ses = (dpaa_sec_session *)get_session_private_data(
- op->sym->session, cryptodev_driver_id);
- else if (op->sess_type == RTE_CRYPTO_OP_SECURITY_SESSION)
- ses = (dpaa_sec_session *)get_sec_session_private_data(
- op->sym->sec_session);
- else
- return -ENOTSUP;
-
- if (unlikely(!ses->qp || ses->qp != qp)) {
- PMD_INIT_LOG(DEBUG, "sess->qp - %p qp %p", ses->qp, qp);
- if (dpaa_sec_attach_sess_q(qp, ses))
- return -1;
- }
-
- /*
-* Segmented buffer is not supported.
-*/
- if (!rte_pktmbuf_is_contiguou
[dpdk-dev] [PATCH] net/mlx5: fix VLAN configuration after port stop
Ethdev layer has an API to configure vlan setting on the flight, i.e.
when the port state is start.
calling such API when the port is stopped may cause segmentation fault
as the related Verbs contexts has not been created yet.
Fixes: 09cb5b581762 ("net/mlx5: separate DPDK from verbs Rx queue objects")
Cc: nelio.laranje...@6wind.com
Cc: sta...@dpdk.org
Signed-off-by: Shahaf Shuler
Acked-by: Nelio Laranjeiro
---
drivers/net/mlx5/mlx5_vlan.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/net/mlx5/mlx5_vlan.c b/drivers/net/mlx5/mlx5_vlan.c
index 6fc315ef3..198a69e3c 100644
--- a/drivers/net/mlx5/mlx5_vlan.c
+++ b/drivers/net/mlx5/mlx5_vlan.c
@@ -127,6 +127,11 @@ priv_vlan_strip_queue_set(struct priv *priv, uint16_t idx,
int on)
DEBUG("set VLAN offloads 0x%x for port %d queue %d",
vlan_offloads, rxq->port_id, idx);
+ if (!rxq_ctrl->ibv) {
+ /* Update related bits in RX queue. */
+ rxq->vlan_strip = !!on;
+ return;
+ }
mod = (struct ibv_wq_attr){
.attr_mask = IBV_WQ_ATTR_FLAGS,
.flags_mask = IBV_WQ_FLAGS_CVLAN_STRIPPING,
--
2.12.0
Re: [dpdk-dev] [PATCH v2 12/18] eal: add generic device declaration parameter
On Thursday 12 October 2017 01:51 PM, Gaetan Rivet wrote:
Add a new generic device declaration parameter:
--dev=
[...]
diff --git a/lib/librte_eal/common/eal_common_options.c
b/lib/librte_eal/common/eal_common_options.c
index 603df27..b7591fd 100644
--- a/lib/librte_eal/common/eal_common_options.c
+++ b/lib/librte_eal/common/eal_common_options.c
@@ -95,6 +95,7 @@ eal_long_options[] = {
{OPT_PROC_TYPE, 1, NULL, OPT_PROC_TYPE_NUM},
{OPT_SOCKET_MEM,1, NULL, OPT_SOCKET_MEM_NUM },
{OPT_SYSLOG,1, NULL, OPT_SYSLOG_NUM },
+ {OPT_DEV, 1, NULL, OPT_DEV_NUM },
{OPT_VDEV, 1, NULL, OPT_VDEV_NUM },
{OPT_VFIO_INTR, 1, NULL, OPT_VFIO_INTR_NUM},
{OPT_VMWARE_TSC_MAP,0, NULL, OPT_VMWARE_TSC_MAP_NUM },
@@ -1120,6 +1121,21 @@ eal_parse_common_option(int opt, const char *optarg,
}
break;
+ case OPT_DEV_NUM: {
+ struct rte_devargs da;
+ int ret;
+
+ if (rte_eal_devargs_parse(&da, optarg) < 0)
+ return -1;
+ ret = rte_bus_probe_mode_set(da.bus->name,
+ RTE_BUS_PROBE_WHITELIST);
+ if (ret < 0 && ret != -ENOTSUP)
+ return -1;
+ if (eal_option_device_add(NULL, optarg) < 0)
+ return -1;
+ }
Might be a naive question: Any specific reason why we don't add the
devices directly into devargs_list here (eal_parse_args ->
eal_parse_common_option -> OPT_DEV ->) rather than wait for eal to call
eal_option_device_parse again?
Is it to allow eal_plugins_init() to finish?
+ break;
+
case OPT_VDEV_NUM:
if (eal_option_device_add("vdev", optarg) < 0)
return -1;
[...]
Re: [dpdk-dev] [PATCH 1/4] examples/l3fwd-power: fix non Rx intr supported platform
On 12/12/2017 10:08 AM, Nikhil Agarwal wrote:
This existing code cause the platform to start receiving packet
immediately irrespective of interrupts available or not.
If the platform does not support Rx interrupt, it shall not start
receiving packets immediately. It shall let the timer management work.
Fixes: aee3bc79cc34 ("examples/l3fwd-power: enable one-shot Rx interrupt and polling
switch")
Cc: sta...@dpdk.org
Cc: Danny Zhou
Cc: Cunming Liang
Signed-off-by: Nikhil Agarwal
---
---snip---
Acked-by: David Hunt
Re: [dpdk-dev] [PATCH 2/4] examples/l3fwd-power: fix the timer for any platform freq
On 12/12/2017 10:08 AM, Nikhil Agarwal wrote:
The code assumes that the platform frequency is 2GHz.
This patch add support for dynamically detecting platform frequence.
Fixes: d7937e2e3d12 ("power: initial import")
Cc: sta...@dpdk.org
Signed-off-by: Nikhil Agarwal
---
---snip---
Acked-by: David Hunt
Re: [dpdk-dev] [PATCH 3/4] examples/l3fwd-power: replace desc done with Rx queue count
On 12/12/2017 10:08 AM, Nikhil Agarwal wrote: HW queue based platforms may not support descriptor done API. This patch changes the usages to rx_queue_count API, which is more generic. Signed-off-by: Nikhil Agarwal --- ---snip--- Acked-by: David Hunt
Re: [dpdk-dev] [RFC] eventdev: add crypto adapter API header
Hi Jerin,
On 12/13/2017 4:56 PM, Jerin Jacob wrote:
-Original Message-
Date: Wed, 13 Dec 2017 11:03:06 +
From: "Doherty, Declan"
To: Jerin Jacob , Abhinandan Gujjar
CC: dev@dpdk.org, narender.vang...@intel.com, Nikhil Rao
, Gage Eads ,
hemant.agra...@nxp.com, nidadavolu.mur...@cavium.com,
nithin.dabilpu...@cavium.com, narayanaprasad.athr...@cavium.com
Subject: Re: [RFC] eventdev: add crypto adapter API header
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
Thunderbird/52.5.0
On 29/11/2017 11:41 AM, Jerin Jacob wrote:
-Original Message-
...
Adding Declan and Hemant.
IMO, RTE_EVENT_CRYPTO_ENQ_MULTI_EVENTQ may not be very useful
from application perceptive as the scope is very limited.
In real world use cases, we will be attaching destination event queue
information
to the session, not to the queue pair.
IMO, RTE_EVENT_CRYPTO_ENQ_MBUF_MULTI_EVENTQ scheme may not very
convenient for application writers as
# it relies on mbuf private area memory. So it has additional memory alloc/free
requirements.
# additional overhead for application/PMD to write/read the event queue metadata
information per packet.
Since we already have meta data structure in the crypto
area, How about adding the destination event queue attributes
in the PMD crypto session area and for, _session less_, we can add it
in rte_crypto_op stricture? This will help in:
# Offloading HW specific meta data generation for event queue attributes
to slow path.
# From the application perspective, most likely the event queue parameters
will be different for each session not per packet nor per event queue
pair.
Hey Jerin,
Hey Declan,
given my limited experience with eventdev, your proposed approach in general
makes sense to me, in that a packet flow having crypto processing done will
always be forwarded the same next stage event queue. So storing this state
in the crypto session, or crypto op in the case of sessionless ops, seems
sensible.
Something like below to share my view. Exact details may be we can work it out.
I terms of your proposed changes below, my main concern would be introducing
dependencies on the eventdev library into cryptodev, as with this new crypto
adpater you will have a dependency on cryptodev in eventdev.
I agree with your dependency concern.
I think the best approach would be to support opaque metadata in both the
crypto op and crypto session structures, as this would allow other uses
cases to be supported which aren't specific to eventdev to also store
metadata across cryptodev processing.
Make sense. Just to add, adding a pointer would be overhead. I think, we
can reserve a few bytes as byte array and then later typecast with
eventdev api in eventdev library.
uint8_t eventdev_metadata[SOMEBYTES];
Thoughts?
I believe only 1 uint64 is sufficient. The metadata that we need here is
rte_event which is 2 uint64 and the second one is mbuf. Since mbuf is
already part of rte_crypto_sym_op, we do not need it.
So only a pointer/uint64 is required.
➜ [master][dpdk.org] $ git diff
diff --git a/lib/librte_cryptodev/rte_crypto.h
b/lib/librte_cryptodev/rte_crypto.h
index 3d672fe7d..b44ef673b 100644
--- a/lib/librte_cryptodev/rte_crypto.h
+++ b/lib/librte_cryptodev/rte_crypto.h
@@ -115,6 +115,9 @@ struct rte_crypto_op {
uint8_t reserved[5];
/**< Reserved bytes to fill 64 bits for future additions */
+#if 0
+ Crypto completion event attribute. For _session less_ crypto enqueue
operation,
+ The will field shall be used by application to post the crypto completion
event
+ upon the crypto enqueue operation complete.
+ Note: In the case of session based crypto operation, SW based crypto adapter
can use
+ this memory to store crypto event completion attributes from the PMD
+ specific session area.
+
+ Note: ev.event_ptr will point to struct rte_crypto_op *op, So
+ that core can free the ops memory on event_dequeue().
+#endif
+
+ struct rte_event ev;
struct rte_mempool *mempool;
/**< crypto operation mempool which operation is allocated from
* */
diff --git a/lib/librte_cryptodev/rte_cryptodev.h
b/lib/librte_cryptodev/rte_cryptodev.h
index dade5548f..540b29e66 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -945,6 +945,13 @@ rte_cryptodev_sym_session_init(uint8_t dev_id,
struct rte_crypto_sym_xform *xforms,
struct rte_mempool *mempool);
+#if 0
+ Create PMD specific session meta data for the destination event queue
+ attribute to post the crypto completion event on crypto work complete.
+#endif
+int
+rte_cryptodev_sym_session_event_init(uint8_t dev_id,
+ struct rte_cryptodev_sym_session *sess,
+ struct rte_crypto_sym_xform *xforms,
+ struct rte_mempool *mempool,
+ struct rte_event ev);
+
/**
* Frees priva
Re: [dpdk-dev] [PATCH 4/4] examples/l3fwd-power: disable Lsc interrupts
On 12/12/2017 10:08 AM, Nikhil Agarwal wrote: This application does not need Link Status Interrupt. It will cause failure for the platforms not supporting LSC. Signed-off-by: Nikhil Agarwal --- ---snip--- Acked-by: David Hunt
[dpdk-dev] [PATCH v2 1/4] ethdev: add devop to check removal status
There is time between the physical removal of the device until PMDs get
a RMV interrupt. At this time DPDK PMDs and applications still don't
know about the removal.
Current removal detection is achieved only by registration to device RMV
event and the notification comes asynchronously. So, there is no option
to detect a device removal synchronously.
Applications and other DPDK entities may want to check a device removal
synchronously and to take an immediate decision accordingly.
Add new dev op called is_removed to allow DPDK entities to check an
Ethernet device removal status immediately.
Signed-off-by: Matan Azrad
---
lib/librte_ether/rte_ethdev.c | 28 +---
lib/librte_ether/rte_ethdev.h | 17 +
lib/librte_ether/rte_ethdev_version.map | 7 +++
3 files changed, 49 insertions(+), 3 deletions(-)
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 318af28..c759d0e 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -142,7 +142,8 @@ enum {
rte_eth_find_next(uint16_t port_id)
{
while (port_id < RTE_MAX_ETHPORTS &&
- rte_eth_devices[port_id].state != RTE_ETH_DEV_ATTACHED)
+ rte_eth_devices[port_id].state != RTE_ETH_DEV_ATTACHED &&
+ rte_eth_devices[port_id].state != RTE_ETH_DEV_REMOVED)
port_id++;
if (port_id >= RTE_MAX_ETHPORTS)
@@ -286,8 +287,7 @@ struct rte_eth_dev *
rte_eth_dev_is_valid_port(uint16_t port_id)
{
if (port_id >= RTE_MAX_ETHPORTS ||
- (rte_eth_devices[port_id].state != RTE_ETH_DEV_ATTACHED &&
-rte_eth_devices[port_id].state != RTE_ETH_DEV_DEFERRED))
+ (rte_eth_devices[port_id].state == RTE_ETH_DEV_UNUSED))
return 0;
else
return 1;
@@ -1118,6 +1118,28 @@ struct rte_eth_dev *
}
int
+rte_eth_dev_is_removed(uint16_t port_id)
+{
+ struct rte_eth_dev *dev;
+ int ret;
+
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, 0);
+
+ dev = &rte_eth_devices[port_id];
+
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->is_removed, 0);
+
+ if (dev->state == RTE_ETH_DEV_REMOVED)
+ return 1;
+
+ ret = dev->dev_ops->is_removed(dev);
+ if (ret != 0)
+ dev->state = RTE_ETH_DEV_REMOVED;
+
+ return ret;
+}
+
+int
rte_eth_rx_queue_setup(uint16_t port_id, uint16_t rx_queue_id,
uint16_t nb_rx_desc, unsigned int socket_id,
const struct rte_eth_rxconf *rx_conf,
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 341c2d6..3aa9d3f 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -1196,6 +1196,9 @@ struct rte_eth_dcb_info {
typedef int (*eth_dev_reset_t)(struct rte_eth_dev *dev);
/** <@internal Function used to reset a configured Ethernet device. */
+typedef int (*eth_is_removed_t)(struct rte_eth_dev *dev);
+/**< @internal Function used to detect an Ethernet device removal. */
+
typedef void (*eth_promiscuous_enable_t)(struct rte_eth_dev *dev);
/**< @internal Function used to enable the RX promiscuous mode of an Ethernet
device. */
@@ -1525,6 +1528,8 @@ struct eth_dev_ops {
eth_dev_close_tdev_close; /**< Close device. */
eth_dev_reset_tdev_reset; /**< Reset device. */
eth_link_update_t link_update; /**< Get device link state. */
+ eth_is_removed_t is_removed;
+ /**< Check if the device was physically removed. */
eth_promiscuous_enable_t promiscuous_enable; /**< Promiscuous ON. */
eth_promiscuous_disable_t promiscuous_disable;/**< Promiscuous OFF. */
@@ -1711,6 +1716,7 @@ enum rte_eth_dev_state {
RTE_ETH_DEV_UNUSED = 0,
RTE_ETH_DEV_ATTACHED,
RTE_ETH_DEV_DEFERRED,
+ RTE_ETH_DEV_REMOVED,
};
/**
@@ -1997,6 +2003,17 @@ int rte_eth_dev_configure(uint16_t port_id, uint16_t
nb_rx_queue,
void _rte_eth_dev_reset(struct rte_eth_dev *dev);
/**
+ * Check if an Ethernet device was physically removed.
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @return
+ * - 0 when the Ethernet device is removed, otherwise 1.
+ */
+int
+rte_eth_dev_is_removed(uint16_t port_id);
+
+/**
* Allocate and set up a receive queue for an Ethernet device.
*
* The function allocates a contiguous block of memory for *nb_rx_desc*
diff --git a/lib/librte_ether/rte_ethdev_version.map
b/lib/librte_ether/rte_ethdev_version.map
index e9681ac..78547ff 100644
--- a/lib/librte_ether/rte_ethdev_version.map
+++ b/lib/librte_ether/rte_ethdev_version.map
@@ -198,6 +198,13 @@ DPDK_17.11 {
} DPDK_17.08;
+DPDK_18.02 {
+ global:
+
+ rte_eth_dev_is_removed;
+
+} DPDK_17.11;
+
EXPERIMENTAL {
global:
--
1.8.3.1
[dpdk-dev] [PATCH v2 0/4] Fail-safe fix removal handling lack
There is time between the physical removal of the device until sub-device PMDs get a RMV interrupt. At this time DPDK PMDs and applications still don't know about the removal and may call sub-device control operation which should return an error. This series adds new ethdev operation to check device removal, adds support for it in mlx PMDs and fixes the fail-safe bug of removal error report. V2: Remove ENODEV definition. Remove checks from all mlx control commands. Add new devop - "is_removed". Implement it in mlx4 and mlx5. Fix failsafe bug by the new devop. Matan Azrad (4): ethdev: add devop to check removal status net/mlx4: support a device removal check operation net/mlx5: support a device removal check operation net/failsafe: fix removed device handling drivers/net/failsafe/failsafe_flow.c| 18 ++--- drivers/net/failsafe/failsafe_ops.c | 34 ++--- drivers/net/failsafe/failsafe_private.h | 10 ++ drivers/net/mlx4/mlx4.c | 1 + drivers/net/mlx4/mlx4.h | 1 + drivers/net/mlx4/mlx4_ethdev.c | 20 +++ drivers/net/mlx5/mlx5.c | 2 ++ drivers/net/mlx5/mlx5.h | 1 + drivers/net/mlx5/mlx5_ethdev.c | 20 +++ lib/librte_ether/rte_ethdev.c | 28 --- lib/librte_ether/rte_ethdev.h | 17 + lib/librte_ether/rte_ethdev_version.map | 7 +++ 12 files changed, 138 insertions(+), 21 deletions(-) -- 1.8.3.1
[dpdk-dev] [PATCH v2 2/4] net/mlx4: support a device removal check operation
Add support to get removal status of mlx4 device.
Signed-off-by: Matan Azrad
---
drivers/net/mlx4/mlx4.c| 1 +
drivers/net/mlx4/mlx4.h| 1 +
drivers/net/mlx4/mlx4_ethdev.c | 20
3 files changed, 22 insertions(+)
diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c
index f9e4f9d..3cde640 100644
--- a/drivers/net/mlx4/mlx4.c
+++ b/drivers/net/mlx4/mlx4.c
@@ -256,6 +256,7 @@ struct mlx4_conf {
.filter_ctrl = mlx4_filter_ctrl,
.rx_queue_intr_enable = mlx4_rx_intr_enable,
.rx_queue_intr_disable = mlx4_rx_intr_disable,
+ .is_removed = mlx4_is_removed,
};
/**
diff --git a/drivers/net/mlx4/mlx4.h b/drivers/net/mlx4/mlx4.h
index 3aeef87..0eaba89 100644
--- a/drivers/net/mlx4/mlx4.h
+++ b/drivers/net/mlx4/mlx4.h
@@ -165,6 +165,7 @@ int mlx4_flow_ctrl_get(struct rte_eth_dev *dev,
int mlx4_flow_ctrl_set(struct rte_eth_dev *dev,
struct rte_eth_fc_conf *fc_conf);
const uint32_t *mlx4_dev_supported_ptypes_get(struct rte_eth_dev *dev);
+int mlx4_is_removed(struct rte_eth_dev *dev);
/* mlx4_intr.c */
diff --git a/drivers/net/mlx4/mlx4_ethdev.c b/drivers/net/mlx4/mlx4_ethdev.c
index 2f69e7d..0d46f5a 100644
--- a/drivers/net/mlx4/mlx4_ethdev.c
+++ b/drivers/net/mlx4/mlx4_ethdev.c
@@ -1060,3 +1060,23 @@ enum rxmode_toggle {
}
return NULL;
}
+
+/**
+ * Check if mlx4 device was removed.
+ *
+ * @param dev
+ * Pointer to Ethernet device structure.
+ *
+ * @return
+ * 1 when device is removed, otherwise 0.
+ */
+int
+mlx4_is_removed(struct rte_eth_dev *dev)
+{
+ struct ibv_device_attr device_attr;
+ struct priv *priv = dev->data->dev_private;
+
+ if (ibv_query_device(priv->ctx, &device_attr) == EIO)
+ return 1;
+ return 0;
+}
--
1.8.3.1
[dpdk-dev] [PATCH v2 3/4] net/mlx5: support a device removal check operation
Add support to get removal status of mlx5 device.
It is not supported in secondary process.
Signed-off-by: Matan Azrad
---
drivers/net/mlx5/mlx5.c| 2 ++
drivers/net/mlx5/mlx5.h| 1 +
drivers/net/mlx5/mlx5_ethdev.c | 20
3 files changed, 23 insertions(+)
diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
index 0548d17..e0b781b 100644
--- a/drivers/net/mlx5/mlx5.c
+++ b/drivers/net/mlx5/mlx5.c
@@ -303,6 +303,7 @@ struct mlx5_args {
.tx_descriptor_status = mlx5_tx_descriptor_status,
.rx_queue_intr_enable = mlx5_rx_intr_enable,
.rx_queue_intr_disable = mlx5_rx_intr_disable,
+ .is_removed = mlx5_is_removed,
};
static const struct eth_dev_ops mlx5_dev_sec_ops = {
@@ -350,6 +351,7 @@ struct mlx5_args {
.tx_descriptor_status = mlx5_tx_descriptor_status,
.rx_queue_intr_enable = mlx5_rx_intr_enable,
.rx_queue_intr_disable = mlx5_rx_intr_disable,
+ .is_removed = mlx5_is_removed,
};
static struct {
diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index e6a69b8..2ec7ae7 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -208,6 +208,7 @@ int mlx5_ibv_device_to_pci_addr(const struct ibv_device *,
int mlx5_set_link_up(struct rte_eth_dev *dev);
void priv_dev_select_tx_function(struct priv *priv, struct rte_eth_dev *dev);
void priv_dev_select_rx_function(struct priv *priv, struct rte_eth_dev *dev);
+int mlx5_is_removed(struct rte_eth_dev *dev);
/* mlx5_mac.c */
diff --git a/drivers/net/mlx5/mlx5_ethdev.c b/drivers/net/mlx5/mlx5_ethdev.c
index a3cef68..5cf0849 100644
--- a/drivers/net/mlx5/mlx5_ethdev.c
+++ b/drivers/net/mlx5/mlx5_ethdev.c
@@ -1474,3 +1474,23 @@ struct priv *
dev->rx_pkt_burst = mlx5_rx_burst;
}
}
+
+/**
+ * Check if mlx5 device was removed.
+ *
+ * @param dev
+ * Pointer to Ethernet device structure.
+ *
+ * @return
+ * 1 when device is removed, otherwise 0.
+ */
+int
+mlx5_is_removed(struct rte_eth_dev *dev)
+{
+ struct ibv_device_attr device_attr;
+ struct priv *priv = dev->data->dev_private;
+
+ if (ibv_query_device(priv->ctx, &device_attr) == EIO)
+ return 1;
+ return 0;
+}
--
1.8.3.1
[dpdk-dev] [PATCH v2 4/4] net/failsafe: fix removed device handling
There is time between the physical removal of the device until
sub-device PMDs get a RMV interrupt. At this time DPDK PMDs and
applications still don't know about the removal and may call sub-device
control operation which should return an error.
In previous code this error is reported to the application contrary to
fail-safe principle that the app should not be aware of device removal.
Add an removal check in each relevant control command error flow and
prevent an error report to application when the sub-device is removed.
Fixes: a46f8d5 ("net/failsafe: add fail-safe PMD")
Fixes: b737a1e ("net/failsafe: support flow API")
Cc: sta...@dpdk.org
Signed-off-by: Matan Azrad
---
drivers/net/failsafe/failsafe_flow.c| 18 ++---
drivers/net/failsafe/failsafe_ops.c | 34 ++---
drivers/net/failsafe/failsafe_private.h | 10 ++
3 files changed, 44 insertions(+), 18 deletions(-)
diff --git a/drivers/net/failsafe/failsafe_flow.c
b/drivers/net/failsafe/failsafe_flow.c
index 153ceee..1e39d66 100644
--- a/drivers/net/failsafe/failsafe_flow.c
+++ b/drivers/net/failsafe/failsafe_flow.c
@@ -87,7 +87,7 @@
DEBUG("Calling rte_flow_validate on sub_device %d", i);
ret = rte_flow_validate(PORT_ID(sdev),
attr, patterns, actions, error);
- if (ret) {
+ if (ret && fs_is_removed(sdev) == 0) {
ERROR("Operation rte_flow_validate failed for
sub_device %d"
" with error %d", i, ret);
return ret;
@@ -111,7 +111,7 @@
FOREACH_SUBDEV_STATE(sdev, i, dev, DEV_ACTIVE) {
flow->flows[i] = rte_flow_create(PORT_ID(sdev),
attr, patterns, actions, error);
- if (flow->flows[i] == NULL) {
+ if (flow->flows[i] == NULL && fs_is_removed(sdev) == 0) {
ERROR("Failed to create flow on sub_device %d",
i);
goto err;
@@ -150,7 +150,7 @@
continue;
local_ret = rte_flow_destroy(PORT_ID(sdev),
flow->flows[i], error);
- if (local_ret) {
+ if (local_ret && fs_is_removed(sdev) == 0) {
ERROR("Failed to destroy flow on sub_device %d: %d",
i, local_ret);
if (ret == 0)
@@ -175,7 +175,7 @@
FOREACH_SUBDEV_STATE(sdev, i, dev, DEV_ACTIVE) {
DEBUG("Calling rte_flow_flush on sub_device %d", i);
ret = rte_flow_flush(PORT_ID(sdev), error);
- if (ret) {
+ if (ret && fs_is_removed(sdev) == 0) {
ERROR("Operation rte_flow_flush failed for sub_device
%d"
" with error %d", i, ret);
return ret;
@@ -199,8 +199,12 @@
sdev = TX_SUBDEV(dev);
if (sdev != NULL) {
- return rte_flow_query(PORT_ID(sdev),
- flow->flows[SUB_ID(sdev)], type, arg, error);
+ int ret = rte_flow_query(PORT_ID(sdev),
+flow->flows[SUB_ID(sdev)],
+type, arg, error);
+
+ if (ret && fs_is_removed(sdev) == 0)
+ return ret;
}
WARN("No active sub_device to query about its flow");
return -1;
@@ -223,7 +227,7 @@
WARN("flow isolation mode of sub_device %d in
incoherent state.",
i);
ret = rte_flow_isolate(PORT_ID(sdev), set, error);
- if (ret) {
+ if (ret && fs_is_removed(sdev) == 0) {
ERROR("Operation rte_flow_isolate failed for sub_device
%d"
" with error %d", i, ret);
return ret;
diff --git a/drivers/net/failsafe/failsafe_ops.c
b/drivers/net/failsafe/failsafe_ops.c
index e16a590..6799b55 100644
--- a/drivers/net/failsafe/failsafe_ops.c
+++ b/drivers/net/failsafe/failsafe_ops.c
@@ -121,6 +121,8 @@
dev->data->nb_tx_queues,
&dev->data->dev_conf);
if (ret) {
+ if (fs_is_removed(sdev) != 0)
+ continue;
ERROR("Could not configure sub_device %d", i);
return ret;
}
@@ -163,8 +165,11 @@
continue;
DEBUG("Starting sub_device %d", i);
ret = rte_eth_dev_start(PORT_ID(sdev));
- if (ret)
+ if (ret) {
+ if (fs_is_removed(sdev) != 0)
+ continue;
return ret;
+ }
Re: [dpdk-dev] [RFC] eventdev: add crypto adapter API header
Hi Nithin,
On 12/13/2017 5:58 PM, Nithin Dabilpuram wrote:
Hi Jerin, Declan,
On Wednesday 13 December 2017 04:56 PM, Jerin Jacob wrote:
-Original Message-
Date: Wed, 13 Dec 2017 11:03:06 +
From: "Doherty, Declan"
To: Jerin Jacob , Abhinandan Gujjar
CC: dev@dpdk.org, narender.vang...@intel.com, Nikhil Rao
, Gage Eads ,
hemant.agra...@nxp.com, nidadavolu.mur...@cavium.com,
nithin.dabilpu...@cavium.com, narayanaprasad.athr...@cavium.com
Subject: Re: [RFC] eventdev: add crypto adapter API header
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
Thunderbird/52.5.0
On 29/11/2017 11:41 AM, Jerin Jacob wrote:
-Original Message-
...
Adding Declan and Hemant.
IMO, RTE_EVENT_CRYPTO_ENQ_MULTI_EVENTQ may not be very useful
from application perceptive as the scope is very limited.
In real world use cases, we will be attaching destination event
queue information
to the session, not to the queue pair.
IMO, RTE_EVENT_CRYPTO_ENQ_MBUF_MULTI_EVENTQ scheme may not very
convenient for application writers as
# it relies on mbuf private area memory. So it has additional memory
alloc/free
requirements.
# additional overhead for application/PMD to write/read the event
queue metadata
information per packet.
Since we already have meta data structure in the crypto
area, How about adding the destination event queue attributes
in the PMD crypto session area and for, _session less_, we can add it
in rte_crypto_op stricture? This will help in:
# Offloading HW specific meta data generation for event queue
attributes
to slow path.
# From the application perspective, most likely the event queue
parameters
will be different for each session not per packet nor per event queue
pair.
Hey Jerin,
Hey Declan,
given my limited experience with eventdev, your proposed approach in
general
makes sense to me, in that a packet flow having crypto processing
done will
always be forwarded the same next stage event queue. So storing this
state
in the crypto session, or crypto op in the case of sessionless ops,
seems
sensible.
Something like below to share my view. Exact details may be we can
work it out.
I terms of your proposed changes below, my main concern would be
introducing
dependencies on the eventdev library into cryptodev, as with this new
crypto
adpater you will have a dependency on cryptodev in eventdev.
I agree with your dependency concern.
I think the best approach would be to support opaque metadata in both
the
crypto op and crypto session structures, as this would allow other uses
cases to be supported which aren't specific to eventdev to also store
metadata across cryptodev processing.
Make sense. Just to add, adding a pointer would be overhead. I think, we
can reserve a few bytes as byte array and then later typecast with
eventdev api in eventdev library.
uint8_t eventdev_metadata[SOMEBYTES];
Thoughts?
Can we have this info in structure rte_crypto_sym_xform instead of
rte_crypto_op
so that for session less or session full we have just one api say as below
to update the event information.
rte_cryptodev_sym_xform_event_init(struct rte_crypto_sym_xform *xforms,
struct
rte_event ev)
IMO, this is better because for both session_less or session_full modes,
app has to
prepare sym_xform structure and in case of session_less make the struct
rte_crypto_op
point to sym_xform and in session_full pass it to
rte_cryptodev_sym_session_create().
The same can be followed for asym/security sessions in future if needed.
IMO, the metadata that we are talking here is per packet and not per
session. So moving it to xform will not serve the purpose as it is raw
information which fills the session parameters of the driver.
And yes security sessions will surely support eventdev crypto adapter APIs.
➜ [master][dpdk.org] $ git diff
diff --git a/lib/librte_cryptodev/rte_crypto.h
b/lib/librte_cryptodev/rte_crypto.h
index 3d672fe7d..b44ef673b 100644
--- a/lib/librte_cryptodev/rte_crypto.h
+++ b/lib/librte_cryptodev/rte_crypto.h
@@ -115,6 +115,9 @@ struct rte_crypto_op {
uint8_t reserved[5];
/**< Reserved bytes to fill 64 bits for future additions */
+#if 0
+ Crypto completion event attribute. For _session less_ crypto
enqueue operation,
+ The will field shall be used by application to post the crypto
completion event
+ upon the crypto enqueue operation complete.
+ Note: In the case of session based crypto operation, SW based
crypto adapter can use
+ this memory to store crypto event completion attributes from the PMD
+ specific session area.
+
+ Note: ev.event_ptr will point to struct rte_crypto_op *op, So
+ that core can free the ops memory on event_dequeue().
+#endif
+
+ struct rte_event ev;
struct rte_mempool *mempool;
/**< crypto operation mempool which operation is allocated
from
* */
diff --git a/lib/librte_cryptodev/rte_crypto
Re: [dpdk-dev] [PATCH v3 1/2] lib/security: add support for get metadata
On 12/12/2017 7:20 PM, Anoob Joseph wrote:
Hi Akhil, Radu
On 12/12/2017 02:25 PM, Akhil Goyal wrote:
Hi Anoob,
On 12/11/2017 12:51 PM, Anoob wrote:
Hi Akhil,
Can you confirm if you are fine with the approach explained inline.
Thanks,
Anoob
On 12/06/2017 03:13 PM, Radu Nicolau wrote:
Hi,
On 12/6/2017 7:30 AM, Anoob wrote:
Hi Akhil, Radu,
Please see inline.
Thanks,
Anoob
On 11/24/2017 05:33 PM, Akhil Goyal wrote:
On 11/24/2017 5:29 PM, Radu Nicolau wrote:
On 11/24/2017 11:34 AM, Akhil Goyal wrote:
Hi Radu,
On 11/24/2017 4:47 PM, Radu Nicolau wrote:
On 11/24/2017 10:55 AM, Akhil Goyal wrote:
On 11/24/2017 3:09 PM, Radu Nicolau wrote:
Hi,
Comment inline
On 11/24/2017 8:50 AM, Akhil Goyal wrote:
Hi Anoob, Radu,
On 11/23/2017 4:49 PM, Anoob Joseph wrote:
In case of inline protocol processed ingress traffic, the
packet may not
have enough information to determine the security
parameters with which
the packet was processed. In such cases, application could
get metadata
from the packet which could be used to identify the
security parameters
with which the packet was processed.
Signed-off-by: Anoob Joseph
---
v3:
* Replaced 64 bit metadata in conf with (void *)userdata
* The API(rte_security_get_pkt_metadata) would return void
* instead of
uint64_t
v2:
* Replaced get_session and get_cookie APIs with
get_pkt_metadata API
lib/librte_security/rte_security.c | 13 +
lib/librte_security/rte_security.h | 19 +++
lib/librte_security/rte_security_driver.h | 16
3 files changed, 48 insertions(+)
diff --git a/lib/librte_security/rte_security.c
b/lib/librte_security/rte_security.c
index 1227fca..a1d78b6 100644
--- a/lib/librte_security/rte_security.c
+++ b/lib/librte_security/rte_security.c
@@ -108,6 +108,19 @@ rte_security_set_pkt_metadata(struct
rte_security_ctx *instance,
sess, m, params);
}
+void *
+rte_security_get_pkt_metadata(struct rte_security_ctx
*instance,
+ struct rte_mbuf *pkt)
Can we rename pkt with m. Just to make it consistent with
the set API.
+{
+ void *md = NULL;
+
+ RTE_FUNC_PTR_OR_ERR_RET(*instance->ops->get_pkt_metadata,
NULL);
+ if (instance->ops->get_pkt_metadata(instance->device,
pkt, &md))
+ return NULL;
+
+ return md;
+}
Pkt metadata should be set by user i.e. the application, and
the driver need not be aware of the format and the values of
the metadata.
So setting the metadata in the driver and getting it back
from the driver does not look a good idea.
Is it possible, that the application define the metadata on
its own and set it in the library itself without the call to
the driver ops.
I'm not sure I understand here; even in our case (ixgbe) the
driver sets the metadata and it is aware of the format - that
is the whole idea. This is why we added the set_metadata API,
to allow the driver to inject extra information into the
mbuf, information that is driver specific and derived from
the security session, so it makes sense to also have a
symmetric get_metadata.
Private data is the one that follows those rules, i.e.
application specific and driver transparent.
As per my understanding of the user metadata, it should be in
control of the application, and the application shall know the
format of that. Setting in driver will disallow this.
Please let me know if my understanding is incorrect.
If at all, some information is needed to be set on the basis
of driver, then application can get that information from the
driver and then set it in the packet metadata in its own
way/format.
The rte_security_set_pkt_metadata() doc defines the metadata as
"device-specific defined metadata" and also takes a device
specific params pointer, so the symmetric function is to be
expected to work in the same way, i.e. return device specific
metadata associated with the security session and instance and
mbuf. How is this metadata stored is not specified in the
security API, so the PMD implementation have the flexibility.
Is rte_security_get_pkt_metadata() expected to return a "device
specific" pointer? If that's the case, we would need another call
(something like, rte_security_get_userdata()) to get back the
userdata, right? Or is it fine, if the application assumes it will
get userdata (the one passed in conf while creating security
session) with rte_security_get_pkt_metadata()?
Yes, this will be my assumption, a "device specific" pointer
(similar to the "void *params" parameter of the
rte_security_set_pkt_metadata function), which will contain an
arbitrary defined structure that will be decoded by calling a PMD
defined function.
But I think Akhil has a different view on this.
I am ok with the approach, if we are adding this as a limitation of
using udata in the documentation for inline cases.
The ideal approach should be such that driver should not be knowing
the content of the udata. But, if we cannot
Re: [dpdk-dev] [PATCH v3 2/2] examples/ipsec-secgw: add target queues in flow actions
Hi,
On Wed, Dec 13, 2017 at 07:23:19PM +0530, Anoob Joseph wrote:
> Hi Nelio,
>
>
> On 12/13/2017 06:23 PM, Nelio Laranjeiro wrote:
> > Hi Anoob,
> >
> > On Wed, Dec 13, 2017 at 05:08:19PM +0530, Anoob Joseph wrote:
> > > Hi Nelio,
> > >
> > >
> > > On 12/13/2017 03:32 PM, Nelio Laranjeiro wrote:
> > > > Hi Anoob,
> > > >
> > > > On Wed, Dec 13, 2017 at 12:11:18PM +0530, Anoob Joseph wrote:
> > > > > Hi Nelio,
> > > > >
> > > > >
> > > > > On 12/12/2017 08:08 PM, Nelio Laranjeiro wrote:
> > > > > > Hi Anoob,
> > > > > >
> > > > > > On Tue, Dec 12, 2017 at 07:34:31PM +0530, Anoob Joseph wrote:
> > > > > > > Hi Nelio,
> > > > > > >
> > > > > > >
> > > > > > > On 12/12/2017 07:14 PM, Nelio Laranjeiro wrote:
> > > > > > > > Hi Anoob,
> > > > > > > >
> > > > > > > > On Tue, Dec 12, 2017 at 06:13:08PM +0530, Anoob Joseph wrote:
> > > > > > > > > Hi Nelio,
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On 12/11/2017 07:34 PM, Nelio Laranjeiro wrote:
> > > > > > > > > > Mellanox INNOVA NIC needs to have final target queue
> > > > > > > > > > actions to perform
> > > > > > > > > > inline crypto.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Nelio Laranjeiro
> > > > > > > > > >
> > > > > > > > > > ---
> > > > > > > > > >
> > > > > > > > > > Changes in v3:
> > > > > > > > > >
> > > > > > > > > > * removed PASSTHRU test for ingress.
> > > > > > > > > > * removed check on configured queues for the queue
> > > > > > > > > > action.
> > > > > > > > > >
> > > > > > > > > > Changes in v2:
> > > > > > > > > >
> > > > > > > > > > * Test the rule by PASSTHRU/RSS/QUEUE and apply the
> > > > > > > > > > first one validated.
> > > > > > > > > > ---
> > > > > > > > > > examples/ipsec-secgw/ipsec.c | 57
> > > > > > > > > > ++--
> > > > > > > > > > examples/ipsec-secgw/ipsec.h | 2 +-
> > > > > > > > > > 2 files changed, 56 insertions(+), 3 deletions(-)
> > > > > > > > > >
> > > > > > > > > > diff --git a/examples/ipsec-secgw/ipsec.c
> > > > > > > > > > b/examples/ipsec-secgw/ipsec.c
> > > > > > > > > > index 17bd7620d..1b8b251c8 100644
> > > > > > > > > > --- a/examples/ipsec-secgw/ipsec.c
> > > > > > > > > > +++ b/examples/ipsec-secgw/ipsec.c
> > > > > > > > > > @@ -142,6 +142,7 @@ create_session(struct ipsec_ctx
> > > > > > > > > > *ipsec_ctx, struct ipsec_sa *sa)
> > > > > > > > > >
> > > > > > > > > > rte_eth_dev_get_sec_ctx(
> > > > > > > > > >
> > > > > > > > > > sa->portid);
> > > > > > > > > > const struct
> > > > > > > > > > rte_security_capability *sec_cap;
> > > > > > > > > > + int ret = 0;
> > > > > > > > > > sa->sec_session =
> > > > > > > > > > rte_security_session_create(ctx,
> > > > > > > > > > &sess_conf,
> > > > > > > > > > ipsec_ctx->session_pool);
> > > > > > > > > > @@ -201,15 +202,67 @@ create_session(struct ipsec_ctx
> > > > > > > > > > *ipsec_ctx, struct ipsec_sa *sa)
> > > > > > > > > > sa->action[0].type =
> > > > > > > > > > RTE_FLOW_ACTION_TYPE_SECURITY;
> > > > > > > > > > sa->action[0].conf =
> > > > > > > > > > sa->sec_session;
> > > > > > > > > > - sa->action[1].type =
> > > > > > > > > > RTE_FLOW_ACTION_TYPE_END;
> > > > > > > > > > -
> > > > > > > > > > sa->attr.egress =
> > > > > > > > > > (sa->direction ==
> > > > > > > > > >
> > > > > > > > > > RTE_SECURITY_IPSEC_SA_DIR_EGRESS);
> > > > > > > > > > sa->attr.ingress =
> > > > > > > > > > (sa->direction ==
> > > > > > > > > >
> > > > > > > > > > RTE_SECURITY_IPSEC_SA_DIR_INGRESS);
> > > > > > > > > > + if (sa->attr.ingress) {
> > > > > > > > > > + uint8_t rss_key[40];
> > > > > > > > > > + struct rte_eth_rss_conf
> > > > > > > > > > rss_conf = {
> > > > > > > > > > + .rss_key = rss_key,
> > > > > > > > > > + .rss_key_len = 40,
> > > > > > > > > > + };
> > > > > > > > > > + struct rte_eth_dev *eth_dev;
> > > > > > > > > > + union {
> > > > > > > > > > + struct
> > > > > > > > > > rte_flow_action_rss rss;
> > > > > > > > > > + struct {
> > > > > > > > > > + const struct
> > > > > > > > > > rte_eth_rss_conf *rss_conf;
> > > > > > > > > > + uint16_t num;
> > > > > > > > > > + uint16_t
> >
Re: [dpdk-dev] [PATCH v2 12/18] eal: add generic device declaration parameter
On Wed, Dec 13, 2017 at 07:56:42PM +0530, Shreyansh Jain wrote:
> On Thursday 12 October 2017 01:51 PM, Gaetan Rivet wrote:
> > Add a new generic device declaration parameter:
> >
> > --dev=
> >
>
> [...]
>
> >
> > diff --git a/lib/librte_eal/common/eal_common_options.c
> > b/lib/librte_eal/common/eal_common_options.c
> > index 603df27..b7591fd 100644
> > --- a/lib/librte_eal/common/eal_common_options.c
> > +++ b/lib/librte_eal/common/eal_common_options.c
> > @@ -95,6 +95,7 @@ eal_long_options[] = {
> > {OPT_PROC_TYPE, 1, NULL, OPT_PROC_TYPE_NUM},
> > {OPT_SOCKET_MEM,1, NULL, OPT_SOCKET_MEM_NUM },
> > {OPT_SYSLOG,1, NULL, OPT_SYSLOG_NUM },
> > + {OPT_DEV, 1, NULL, OPT_DEV_NUM },
> > {OPT_VDEV, 1, NULL, OPT_VDEV_NUM },
> > {OPT_VFIO_INTR, 1, NULL, OPT_VFIO_INTR_NUM},
> > {OPT_VMWARE_TSC_MAP,0, NULL, OPT_VMWARE_TSC_MAP_NUM },
> > @@ -1120,6 +1121,21 @@ eal_parse_common_option(int opt, const char *optarg,
> > }
> > break;
> > + case OPT_DEV_NUM: {
> > + struct rte_devargs da;
> > + int ret;
> > +
> > + if (rte_eal_devargs_parse(&da, optarg) < 0)
> > + return -1;
> > + ret = rte_bus_probe_mode_set(da.bus->name,
> > + RTE_BUS_PROBE_WHITELIST);
> > + if (ret < 0 && ret != -ENOTSUP)
> > + return -1;
> > + if (eal_option_device_add(NULL, optarg) < 0)
> > + return -1;
> > + }
>
> Might be a naive question: Any specific reason why we don't add the devices
> directly into devargs_list here (eal_parse_args -> eal_parse_common_option
> -> OPT_DEV ->) rather than wait for eal to call eal_option_device_parse
> again?
>
> Is it to allow eal_plugins_init() to finish?
>
Yes. And actually this makes me aware of an issue with this
implementation.
Calling rte_eal_devargs_parse here is premature, and
rte_bus_probe_mode_set as well.
eal_plugins_init() must be executed before calling rte_devargs to allow
for buses introduced as plugins to be able to recognize their devices.
I will reorder a few things in eal_options, thanks for catching this.
> > + break;
> > +
> > case OPT_VDEV_NUM:
> > if (eal_option_device_add("vdev", optarg) < 0)
> > return -1;
>
> [...]
>
--
Gaëtan Rivet
6WIND
