Re: [dpdk-dev] [dpdk-stable] [PATCH] eventdev: fix eth port in eth Rx adapter internal function
On 5/25/2018 2:25 AM, Thomas Monjalon wrote:
23/05/2018 07:51, Jerin Jacob:
-Original Message-
Date: Wed, 23 May 2018 02:36:42 +0530
From: Nikhil Rao
To: jerin.ja...@caviumnetworks.com
CC: dev@dpdk.org, Nikhil Rao , sta...@dpdk.org
Subject: [PATCH] eventdev: fix eth port in eth Rx adapter internal function
X-Mailer: git-send-email 1.8.3.1
The dev_id parameter to fill_event_buffer() should be 16 bit,
also rename to to eth_dev_id to avoid confusion with event device
id elsewhere in the file.
Fixes: c2189c907dd1 ("eventdev: make ethdev port identifiers 16-bit")
Cc: sta...@dpdk.org
Signed-off-by: Nikhil Rao
Acked-by: Jerin Jacob
Hi Jerin,
Can you please apply this patch to next-eventdev ?
Nikhil
It doesn't look to be critical.
So it is deferred to 18.08 (we minimize risks in -rc6).
Re: [dpdk-dev] [PATCH] ethdev: force RSS offload rules again
Thursday, May 31, 2018 4:23 PM, Ferruh Yigit: > Subject: [PATCH] ethdev: force RSS offload rules again > > PMDs should provide supported RSS hash functions via > dev_info.flow_type_rss_offloads variable. > > There is a check in ethdev if requested RSS hash function is supported by > PMD or not. > This check has been relaxed in previous release to not return an error when a > non supported has function requested [1], this has been done to not break > the applications. > > Adding the error return back. > PMDs need to provide correct list of supported hash functions and > applications need to take care this information before configuring the RSS > otherwise they will get an error from APIs: > rte_eth_dev_rss_hash_update() > rte_eth_dev_configure() Are the current app/examples in DPDK tree behave accordingly?
[dpdk-dev] [PATCH] eventdev: fix missing update to Rx adaper WRR position
After dequeuing Rx packets and enqueueing them to the
temporary buffer towards eventdev, the packet Rx loop exits
if the temporary buffer is full but the current WRR position
is not saved.
Save away the current value of the WRR position, so packets
are dequeued from the correct Rx queue in the next invocation.
Fixes: 9c38b704d280 ("eventdev: add eth Rx adapter implementation")
Suggested-by: Gage Eads
Signed-off-by: Nikhil Rao
Cc: sta...@dpdk.org
---
lib/librte_eventdev/rte_event_eth_rx_adapter.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/lib/librte_eventdev/rte_event_eth_rx_adapter.c
b/lib/librte_eventdev/rte_event_eth_rx_adapter.c
index 6f70509..53a3788 100644
--- a/lib/librte_eventdev/rte_event_eth_rx_adapter.c
+++ b/lib/librte_eventdev/rte_event_eth_rx_adapter.c
@@ -517,8 +517,10 @@ static uint16_t gcd_u16(uint16_t a, uint16_t b)
*/
if (buf->count >= BATCH_SIZE)
flush_event_buffer(rx_adapter);
- if (BATCH_SIZE > (ETH_EVENT_BUFFER_SIZE - buf->count))
+ if (BATCH_SIZE > (ETH_EVENT_BUFFER_SIZE - buf->count)) {
+ rx_adapter->wrr_pos = wrr_pos;
break;
+ }
stats->rx_poll_count++;
n = rte_eth_rx_burst(d, qid, mbufs, BATCH_SIZE);
--
1.8.3.1
[dpdk-dev] [PATCH] eventdev: add event buffer flush in Rx adapter
Add an event buffer flush when the current invocation
of the Rx adapter is completed.
This patch provides lower latency in case there is a
BATCH_SIZE of events in the event buffer.
Suggested-by: Narender Vangati
Signed-off-by: Nikhil Rao
Cc: sta...@dpdk.org
---
lib/librte_eventdev/rte_event_eth_rx_adapter.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/lib/librte_eventdev/rte_event_eth_rx_adapter.c
b/lib/librte_eventdev/rte_event_eth_rx_adapter.c
index 53a3788..3a70058 100644
--- a/lib/librte_eventdev/rte_event_eth_rx_adapter.c
+++ b/lib/librte_eventdev/rte_event_eth_rx_adapter.c
@@ -490,7 +490,7 @@ static uint16_t gcd_u16(uint16_t a, uint16_t b)
* the hypervisor's switching layer where adjustments can be made to deal with
* it.
*/
-static inline uint32_t
+static inline void
eth_rx_poll(struct rte_event_eth_rx_adapter *rx_adapter)
{
uint32_t num_queue;
@@ -519,7 +519,7 @@ static uint16_t gcd_u16(uint16_t a, uint16_t b)
flush_event_buffer(rx_adapter);
if (BATCH_SIZE > (ETH_EVENT_BUFFER_SIZE - buf->count)) {
rx_adapter->wrr_pos = wrr_pos;
- break;
+ return;
}
stats->rx_poll_count++;
@@ -535,7 +535,7 @@ static uint16_t gcd_u16(uint16_t a, uint16_t b)
if (nb_rx > max_nb_rx) {
rx_adapter->wrr_pos =
(wrr_pos + 1) % rx_adapter->wrr_len;
- return nb_rx;
+ break;
}
}
@@ -543,20 +543,18 @@ static uint16_t gcd_u16(uint16_t a, uint16_t b)
wrr_pos = 0;
}
- return nb_rx;
+ if (buf->count >= BATCH_SIZE)
+ flush_event_buffer(rx_adapter);
}
static int
event_eth_rx_adapter_service_func(void *args)
{
struct rte_event_eth_rx_adapter *rx_adapter = args;
- struct rte_eth_event_enqueue_buffer *buf;
- buf = &rx_adapter->event_enqueue_buffer;
if (rte_spinlock_trylock(&rx_adapter->rx_lock) == 0)
return 0;
- if (eth_rx_poll(rx_adapter) == 0 && buf->count)
- flush_event_buffer(rx_adapter);
+ eth_rx_poll(rx_adapter);
rte_spinlock_unlock(&rx_adapter->rx_lock);
return 0;
}
--
1.8.3.1
[dpdk-dev] [PATCH] eventdev: fix internal event port logic in Rx event adapter
Set the internal_event_port flag when the ethdev-eventdev
packet transfer is implemented in hardware and add a check
for the flag to ignore the connection when setting up the
WRR polling sequence.
Fixes: 9c38b704d280 ("eventdev: add eth Rx adapter implementation")
Signed-off-by: Nikhil Rao
CC: sta...@dpdk.org
---
lib/librte_eventdev/rte_event_eth_rx_adapter.c | 4
1 file changed, 4 insertions(+)
diff --git a/lib/librte_eventdev/rte_event_eth_rx_adapter.c
b/lib/librte_eventdev/rte_event_eth_rx_adapter.c
index 3a70058..d03f870 100644
--- a/lib/librte_eventdev/rte_event_eth_rx_adapter.c
+++ b/lib/librte_eventdev/rte_event_eth_rx_adapter.c
@@ -224,6 +224,8 @@ static uint16_t gcd_u16(uint16_t a, uint16_t b)
nb_rx_queues = dev_info->dev->data->nb_rx_queues;
if (dev_info->rx_queue == NULL)
continue;
+ if (dev_info->internal_event_port)
+ continue;
for (q = 0; q < nb_rx_queues; q++) {
struct eth_rx_queue_info *queue_info =
&dev_info->rx_queue[q];
@@ -1050,6 +1052,7 @@ static int add_rx_queue(struct rte_event_eth_rx_adapter
*rx_adapter,
&rte_eth_devices[eth_dev_id],
rx_queue_id, queue_conf);
if (ret == 0) {
+ dev_info->internal_event_port = 1;
update_queue_info(rx_adapter,
&rx_adapter->eth_devices[eth_dev_id],
rx_queue_id,
@@ -1057,6 +1060,7 @@ static int add_rx_queue(struct rte_event_eth_rx_adapter
*rx_adapter,
}
} else {
rte_spinlock_lock(&rx_adapter->rx_lock);
+ dev_info->internal_event_port = 0;
ret = init_service(rx_adapter, id);
if (ret == 0)
ret = add_rx_queue(rx_adapter, eth_dev_id, rx_queue_id,
--
1.8.3.1
Re: [dpdk-dev] [PATCH] ethdev: force RSS offload rules again
On 6/3/2018 11:41 AM, Shahaf Shuler wrote: > Thursday, May 31, 2018 4:23 PM, Ferruh Yigit: >> Subject: [PATCH] ethdev: force RSS offload rules again >> >> PMDs should provide supported RSS hash functions via >> dev_info.flow_type_rss_offloads variable. >> >> There is a check in ethdev if requested RSS hash function is supported by >> PMD or not. >> This check has been relaxed in previous release to not return an error when a >> non supported has function requested [1], this has been done to not break >> the applications. >> >> Adding the error return back. >> PMDs need to provide correct list of supported hash functions and >> applications need to take care this information before configuring the RSS >> otherwise they will get an error from APIs: >> rte_eth_dev_rss_hash_update() >> rte_eth_dev_configure() > > Are the current app/examples in DPDK tree behave accordingly? I tried a few which were good but I don't know about all. That is why we should merge this patch early so that we can detect and fix ones fails.
[dpdk-dev] [RFC] net/mlx5: add support 32bit build
This RFC and patch aim to add support for building mlx5 PMD on 32bit
archs such as i686.
The attached patch was not tested on 32bit environments and is given
here for explanatory purposes.
Prerequisites:
* RDMA-core with 32bit support libraries.
* compile and build tools for 32bit systems according to DPDK documentation.
Assumptions:
* Kernel and drivers are 64bit.
* Only user programs and support libraries are 32Bit.
Changes proposed in the PMD for adding 32bit support:
The attached patch provides the changes needed in the PMD in order to support
32bit builds with the major changes being:
* Modifying the UAR access routine to support non-atomic 64bit writes
according to the mlx5 hardware reference manual.
* Handling 64bit address fields that are written to the device WQEs.
* Modify UAR address and size mapping to fit into the 32bit address space.
Concerns:
* The major concern of this modification is the UAR mapping.
Current PMD assumes 64bit address and therefore feels free to map 4G size
UAR to virtual address just above the huge-page addresses which of course
cannot work for 32bit address space.
As a workaround I reduced the UAR size to half the original size but
this of course is not the solution.
* Will vectorized support work on 32bit builds ?
I am interested in your inputs regarding the concerns listed above,
especially the UAR mapping issue mentioned there.
Signed-off-by: Moti Haimovsky
---
doc/guides/nics/features/mlx5.ini | 1 +
drivers/net/mlx5/mlx5.c | 29 ---
drivers/net/mlx5/mlx5_rxq.c | 2 +-
drivers/net/mlx5/mlx5_rxtx.c | 12 +--
drivers/net/mlx5/mlx5_txq.c | 2 +-
drivers/net/mlx5/mlx5_utils.h | 42 +++
6 files changed, 77 insertions(+), 11 deletions(-)
diff --git a/doc/guides/nics/features/mlx5.ini
b/doc/guides/nics/features/mlx5.ini
index e75b14b..b28b43e 100644
--- a/doc/guides/nics/features/mlx5.ini
+++ b/doc/guides/nics/features/mlx5.ini
@@ -43,5 +43,6 @@ Multiprocess aware = Y
Other kdrv = Y
ARMv8= Y
Power8 = Y
+x86-32 = Y
x86-64 = Y
Usage doc= Y
diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
index c933e27..6e9566d 100644
--- a/drivers/net/mlx5/mlx5.c
+++ b/drivers/net/mlx5/mlx5.c
@@ -110,6 +110,28 @@
/** Driver-specific log messages type. */
int mlx5_logtype;
+static rte_spinlock_t mlx5_mmio_spinlock = RTE_SPINLOCK_INITIALIZER;
+
+/**
+ * Provide an emulation for 64 bit store on arch that does not have a 64 bit
+ * atomic store command. This is done using two 32bit store operations in
+ * address ascending order while holding a global spinlock.
+ */
+void
+mlx5_mmio_write64(uint64_t be_val, volatile void *addr)
+{
+ uint32_t first_dword =
+ rte_cpu_to_be_32(rte_be_to_cpu_64(be_val) >> 32);
+ uint32_t second_dword =
+ rte_cpu_to_be_32(rte_be_to_cpu_64(be_val));
+
+ rte_spinlock_lock(&mlx5_mmio_spinlock);
+ rte_write32(first_dword, addr);
+ rte_write32(second_dword,
+ (volatile void *)((volatile char *)addr + 4));
+ rte_spinlock_unlock(&mlx5_mmio_spinlock);
+}
+
/**
* Prepare shared data between primary and secondary process.
*/
@@ -600,9 +622,10 @@
rte_memseg_walk(find_lower_va_bound, &addr);
/* keep distance to hugepages to minimize potential conflicts. */
- addr = RTE_PTR_SUB(addr, MLX5_UAR_OFFSET + MLX5_UAR_SIZE);
+ addr = RTE_PTR_SUB(addr,
+ (uintptr_t)((MLX5_UAR_OFFSET + MLX5_UAR_SIZE) >> 2));
/* anonymous mmap, no real memory consumption. */
- addr = mmap(addr, MLX5_UAR_SIZE,
+ addr = mmap(addr, MLX5_UAR_SIZE >> 2,
PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
if (addr == MAP_FAILED) {
DRV_LOG(ERR,
@@ -644,7 +667,7 @@
return 0;
}
/* anonymous mmap, no real memory consumption. */
- addr = mmap(priv->uar_base, MLX5_UAR_SIZE,
+ addr = mmap(priv->uar_base, MLX5_UAR_SIZE >> 2,
PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
if (addr == MAP_FAILED) {
DRV_LOG(ERR, "port %u UAR mmap failed: %p size: %llu",
diff --git a/drivers/net/mlx5/mlx5_rxq.c b/drivers/net/mlx5/mlx5_rxq.c
index de3f869..6fc5a55 100644
--- a/drivers/net/mlx5/mlx5_rxq.c
+++ b/drivers/net/mlx5/mlx5_rxq.c
@@ -643,7 +643,7 @@
doorbell = (uint64_t)doorbell_hi << 32;
doorbell |= rxq->cqn;
rxq->cq_db[MLX5_CQ_ARM_DB] = rte_cpu_to_be_32(doorbell_hi);
- rte_write64(rte_cpu_to_be_64(doorbell), cq_db_reg);
+ mlx5_write64(rte_cpu_to_be_64(doorbell), cq_db_reg);
}
/**
diff --git a/drivers/net/mlx5/mlx5_rxtx.c b/drivers/net/mlx5/mlx5_rxtx.c
index 5278594..1e38841 100644
--- a/drivers/net/mlx5/mlx5_rxtx.c
+++ b/drivers/net/mlx5/mlx5_rxtx.c
@@ -715,8 +715,8 @@
Re: [dpdk-dev] [RFC] hot plug failure handle mechanism
hi,bruce On 5/29/2018 7:20 PM, Bruce Richardson wrote: On Thu, May 24, 2018 at 07:55:43AM +0100, Guo, Jia wrote: The hot plug failure handle mechanism should be come across as bellow: 1. Add a new bus ops “handle_hot-unplug”in bus to handle bus read/write error, it is bus-specific and each kind of bus can implement its own logic. 2. Implement pci bus specific ops“pci_handle_hot_unplug”, in the function, base on the failure address to remap memory which belong to the corresponding device that unplugged. 3. Implement a new sigbus handler, and register it when start device event monitoring, once the MMIO sigbus error exposure, it will trigger the above hot plug failure handle mechanism, that will keep app, that working on packet processing, would not be broken and crash, then could keep going clean, fail-safe or other working task. 4. Also also will introduce the solution by use testpmd to show the example of the whole procedure like that: device unplug ->failure handle->stop forwarding->stop port->close port->detach port. Hi Jeff, so if I understand this correctly the proposal is that we need two parallel solutions to handle safe removal of a device. 1. We need a solution to support unpluging of the device at the bus level, ie. remove the device from the list of devices and to make access to that device invalid. 2. Since the removal of the device from the software lists is not going to be instantaneous, we need a mechanism to handle any accesses to the device from the data path until such time as the removal is complete. To support that, you propose to add a sigbus handler which will automatically replace any mmio bar mappings with some other memory that is ok to access - presumable zero memory or similar. Is this understanding correct? i think you are correct about that. Point #2 seems reasonably clear to me, but for #1, presumably the trigger to the bus needs to come from the kernel. What is planned to be used there? about point #1, i should clarify here is that, we will use the device event monitor mechanism to detect the hot unplug event. the monitor be enabled by app(or fail-safe driver), and app(fail-safe driver) register the event callback. Once the hot unplug behave be detected, the user's callback could be triggered to let app(fail-safe driver) know the event and manage the process, it will call APIs to stop the device and detach the device from the bus. You also talk about using testpmd as a reference for this, but you don't explain how an application can be notified of a device removal, or even why that is necessary. Since all applications should now be using the proper macros when iterating device lists, and not just assuming devices 0-N are valid, what changes would you see a normal app having to make to be hotplug-safe? we could use app or fail-safe driver to use these mechanism , but at this stage i will firstly use testpmd as a reference. as above reply, testpmd should enable device event mechanism to monitor the device removal, and register callback, the device bdf list is managed by bus and the hoplug fail handler will be process by the eal layer, then the app would be hotplug-safe. is there anything i miss to clarify? please shout. and i think i will detail more later. Regards, /Bruce
[dpdk-dev] [PATCH] bus/dpaa: fix compilation issue with meson build
ccache gcc -Idrivers/drivers@@tmp_rte_pmd_dpaa_sec@sta -Idrivers
In file included from ../drivers/bus/dpaa/include/fsl_usd.h:11,
from ../drivers/crypto/dpaa_sec/dpaa_sec.c:27:
../drivers/bus/dpaa/include/compat.h:53:
error: "__packed" redefined [-Werror]
#define __packed __rte_packed
In file included from /usr/include/bsd/string.h:39,
from ../lib/librte_eal/common/include/rte_string_fns.h:71,
from ../drivers/crypto/dpaa_sec/dpaa_sec.c:25:
/usr/include/bsd/sys/cdefs.h:120: note: this is the location
of the previous definition
# define __packed __attribute__((__packed__))
Cc: sta...@dpdk.org
Fixes: 39f373cf015a ("bus/dpaa: add compatibility and helper macros")
Signed-off-by: Jerin Jacob
---
drivers/bus/dpaa/include/compat.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/bus/dpaa/include/compat.h
b/drivers/bus/dpaa/include/compat.h
index e4b570214..0b49ed5e4 100644
--- a/drivers/bus/dpaa/include/compat.h
+++ b/drivers/bus/dpaa/include/compat.h
@@ -50,7 +50,9 @@
/* Required compiler attributes */
#define __maybe_unused __rte_unused
#define __always_unused__rte_unused
+#ifndef __packed
#define __packed __rte_packed
+#endif
#define noinline __attribute__((noinline))
#define L1_CACHE_BYTES 64
--
2.17.1
Re: [dpdk-dev] [dpdk-stable] [PATCH] eventdev: fix eth port in eth Rx adapter internal function
-Original Message-
> Date: Sun, 3 Jun 2018 12:53:39 +0530
> From: "Rao, Nikhil"
> To: Thomas Monjalon , Jerin Jacob
>
> CC: sta...@dpdk.org, dev@dpdk.org, nikhil@intel.com
> Subject: Re: [dpdk-stable] [PATCH] eventdev: fix eth port in eth Rx adapter
> internal function
> User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
> Thunderbird/52.8.0
>
> On 5/25/2018 2:25 AM, Thomas Monjalon wrote:
> > 23/05/2018 07:51, Jerin Jacob:
> > > -Original Message-
> > > > Date: Wed, 23 May 2018 02:36:42 +0530
> > > > From: Nikhil Rao
> > > > To: jerin.ja...@caviumnetworks.com
> > > > CC: dev@dpdk.org, Nikhil Rao , sta...@dpdk.org
> > > > Subject: [PATCH] eventdev: fix eth port in eth Rx adapter internal
> > > > function
> > > > X-Mailer: git-send-email 1.8.3.1
> > > >
> > > > The dev_id parameter to fill_event_buffer() should be 16 bit,
> > > > also rename to to eth_dev_id to avoid confusion with event device
> > > > id elsewhere in the file.
> > > >
> > > > Fixes: c2189c907dd1 ("eventdev: make ethdev port identifiers 16-bit")
> > > > Cc: sta...@dpdk.org
> > > > Signed-off-by: Nikhil Rao
> > >
> > > Acked-by: Jerin Jacob
>
> Hi Jerin,
>
> Can you please apply this patch to next-eventdev ?
Applied to dpdk-next-eventdev/master. Thanks.
>
> Nikhil
>
> >
> > It doesn't look to be critical.
> > So it is deferred to 18.08 (we minimize risks in -rc6).
> >
>
> >
> >
>
Re: [dpdk-dev] [PATCH] doc/event: improve eventdev library documentation
-Original Message- > Date: Thu, 31 May 2018 15:23:42 -0500 > From: Honnappa Nagarahalli > To: jerin.ja...@caviumnetworks.com > CC: dev@dpdk.org, Honnappa Nagarahalli > Subject: [PATCH] doc/event: improve eventdev library documentation > X-Mailer: git-send-email 2.7.4 > > Add small amount of additional code, use consistent variable names > across code blocks, change the image to represent queues and > CPU cores intuitively. These help improve the eventdev library > documentation. > > Signed-off-by: Honnappa Nagarahalli > Reviewed-by: Gavin Hu > --- Changes looks good to me. Adding Harry for this review as he is the original author of this file. > doc/guides/prog_guide/eventdev.rst | 55 +- > doc/guides/prog_guide/img/eventdev_usage.svg | 1518 > +- > 2 files changed, 570 insertions(+), 1003 deletions(-) > > diff --git a/doc/guides/prog_guide/eventdev.rst > b/doc/guides/prog_guide/eventdev.rst > index ce19997..0203d9e 100644 > --- a/doc/guides/prog_guide/eventdev.rst > +++ b/doc/guides/prog_guide/eventdev.rst > @@ -1,5 +1,6 @@ > .. SPDX-License-Identifier: BSD-3-Clause > Copyright(c) 2017 Intel Corporation. > +Copyright(c) 2018 Arm Limited. > > Event Device Library > > @@ -129,7 +130,7 @@ API Walk-through > > This section will introduce the reader to the eventdev API, showing how to > create and configure an eventdev and use it for a two-stage atomic pipeline > -with a single core for TX. The diagram below shows the final state of the > +with one core each for RX and TX. The diagram below shows the final state of > the I think, we can mention the usage of RX and TX core are API illustration purpose only, In the real case, it is abstracted using Eventdev - Ethdev adapters to hide the difference between various eventdev capabilities to Rx or Tx the packets. or something on similar lines. > > > Egress of Events > diff --git a/doc/guides/prog_guide/img/eventdev_usage.svg > b/doc/guides/prog_guide/img/eventdev_usage.svg > index 7765649..b0792dc 100644 > --- a/doc/guides/prog_guide/img/eventdev_usage.svg > +++ b/doc/guides/prog_guide/img/eventdev_usage.svg > @@ -1,994 +1,546 @@ > License is missing see doc/guides/prog_guide/img/architecture-overview.svg file as reference. With above changes: Acked-by: Jerin Jacob
Re: [dpdk-dev] [RFC] eventdev: event tx adapter APIs
-Original Message- > Date: Fri, 1 Jun 2018 23:47:00 +0530 > From: "Rao, Nikhil" > To: Jerin Jacob > CC: hemant.agra...@nxp.com, dev@dpdk.org, narender.vang...@intel.com, > abhinandan.guj...@intel.com, gage.e...@intel.com, nikhil@intel.com > Subject: Re: [RFC] eventdev: event tx adapter APIs > User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 > Thunderbird/52.8.0 > > > Hi Jerin, Hi Nikhil, > > On 5/30/2018 12:56 PM, Jerin Jacob wrote: > > -Original Message- > > Hi Nikhil, > > I think, it is reasonable to have Tx adapter. > > > > Some top level comments to starts with, > > > > 1) Slow path API looks fine. The only comment is, How about changing > > rte_event_eth_tx_adapter_queue_add() instead of > > rte_event_eth_tx_adapter_queue_start() > > to get align with Rx adapter? > OK. > > > > 2) This my understanding of fastpath > > > > a) Common code will have a extra port(given through adapter create) > > where all workers invoke rte_event_enqueue_burst() to that port and then > > common code > > dequeue from that port and send packet > > using rte_eth_tx_burst() and/or using tx buffering APIs > The workers invoke rte_event_enqueue_burst() to their local port not to the > extra port as you described. The queue ID specified when > enqueuing is linked to the the adapter's port, the adapter reads these > events and transmits mbufs on the > ethernet port and queue specified in these mbufs. The diagram below > illustrates what I just described. > > +--+ > | | ++ > |Worker+-->+port+--+ > | | ++ | ++ > +--+ | +-->+eth0| >| +-++---+ | ++ >+--+ | ++ | +---+ ++ > | Queue +-->+port+-->+Adapter|-->+eth1| >+--+ | ++ | +---+ ++ > +--+ | +-++---+ | ++ > | | ++ | +-->+eth2| > |Worker+-->+port+--+ ++ > | | ++ > +--+ Makes sense. One suggestion here, Since we have ALL type queue and normal queues, Can we move the queue change or sched_type change code from the application and move that down to function pointer abstraction(any way adapter knows which queues to enqueue for), that way we can have same final stage code for ALL type queues and Normal queues. > > > b) If the source queue or sched_type is ORDERED, When it enqueue to the > > extra port it > > will change to atomic/direct to maintain the the ingress order if need. > > > > Couple of issues and a minor change in RFC to fix the issues as a proposal. > > > > Issue 1) I think, Using mbuf private data for such purpose will be a > > problem as > > exiting application already may using for it own needs and there will be > > additional cache > > miss etc on fastpath to get private data. > Instead of using mbuf private data, the eth port and queue can be specified > in > the mbuf itself using mbuf:port and mbuf:hash respectively. Looks good to me. > > > Issue 2) At least on Cavium, We can do so optimization by introducing > > the same RTE_EVENT_ETH_TX_ADAPTER_CAP_INTERNAL_PORT schematics of Rx > > adapter. i.e we don't need extra port to converge all traffic from > > different workers and transmit. > OK. > > > > Considering above two issues2, We would like propose an fastpath API, > > which semantics is almost same rte_ethdev_tx_burst(). > > a) It will get ride of mbuf metadata need > > b) New fastpath API gives driver enough possibilities of optimization if > > possible.(address the issue (2)) > > > > The API can be like, > > > > uint16_t rte_event_eth_tx_adapter_enqueue(uint16_t eth_port_id, uint16_t > > eth_queue_id, uint8_t event_port_id, const struct rte_event ev[], uint16_t > > nb_events); > The worker core will receive events pointing to mbufs that need to be > transmitted to different > ports/queues, as described above. The port and the queue will be populated > in the mbuf and the > API can be as below > > uint16_t rte_event_eth_tx_adapter_enqueue(uint8_t instance_id, uint8_t > event_port_id, const struct rte_event ev[], uint16_t nb_events); > > Let me know if that works for you. Yes. That API works for me. I think, we can leverage "struct rte_eventdev" area for adding new function pointer. Just like enqueue_new_burst, enqueue_forward_burst variants, we can add one more there, so that we can reuse that hot cacheline for all fastpath function pointer case. That would translate to adding "uint8_t dev_id" on the above API. > > > This API would land in driver as function pointer if device has > > RTE_EVENT_ETH_TX_ADAPTER_CAP_INTERNAL_PORT capability. > Agreed. > > If device does not have !RTE_EVENT_ETH_TX_ADAPTER_CAP_INTERNAL_PORT then > > common code
Re: [dpdk-dev] Regression tests for stable releases from companies involved in DPDK
Hello Luca > -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Luca Boccassi > Sent: Thursday, May 31, 2018 3:57 PM > To: dev@dpdk.org > Cc: sta...@dpdk.org; tho...@monjalon.net > Subject: [dpdk-dev] Regression tests for stable releases from companies > involved in DPDK > > Hello all, > > At this morning's release meeting (minutes coming soon from John), we > briefly discussed the state of the regression testing for stable > releases and agreed we need to formalise the process. > > At the moment we have a firm commitment from Intel and Mellanox to test > all stable branches (and if I heard correctly from NXP as well? Please Yes, I confirmed that on call on behalf of NXP. But... > confirm!). AT&T committed to run regressions on the 16.11 branch. Not until 17.05 did NXP's first driver started appearing in the DPDK upstream releases. Somehow, I misunderstood your request for 16.11 with 17.11 stable. [...] - Shreyansh
[dpdk-dev] [PATCH v3] memory: fix segfault on rte_mem_virt2memseg() call with invalid addr
When trying to use it with an address that's not
managed by DPDK it would segfault due to a missing
check. The doc says this function returns either
a pointer or NULL, so let it do so.
Fixes: 66cc45e293ed ("mem: replace memseg with memseg lists")
Cc: anatoly.bura...@intel.com
Cc: sta...@dpdk.org
Signed-off-by: Dariusz Stojaczyk
Acked-by: Anatoly Burakov
---
Changes from v2:
* cleaned up commit msg
Changes from v1:
* removed gerrit change id
* added "git fixline" tags
lib/librte_eal/common/eal_common_memory.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/lib/librte_eal/common/eal_common_memory.c
b/lib/librte_eal/common/eal_common_memory.c
index 4f0688f..ecc5bb2 100644
--- a/lib/librte_eal/common/eal_common_memory.c
+++ b/lib/librte_eal/common/eal_common_memory.c
@@ -536,6 +536,9 @@ virt2memseg(const void *addr, const struct rte_memseg_list
*msl)
void *start, *end;
int ms_idx;
+ if (msl == NULL)
+ return NULL;
+
/* a memseg list was specified, check if it's the right one */
start = msl->base_va;
end = RTE_PTR_ADD(start, (size_t)msl->page_sz * msl->memseg_arr.len);
--
2.7.4
Re: [dpdk-dev] [PATCH v5 2/2] doc: add a guide doc for cross compiling from x86
See my inline comments: > -Original Message- > From: Jerin Jacob > Sent: Thursday, May 31, 2018 3:36 AM > To: Gavin Hu > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v5 2/2] doc: add a guide doc for cross > compiling from x86 > > -Original Message- > > Date: Tue, 29 May 2018 18:43:36 +0800 > > From: Gavin Hu > > To: dev@dpdk.org > > CC: gavin...@arm.com > > Subject: [dpdk-dev] [PATCH v5 2/2] doc: add a guide doc for cross > > compiling from x86 > > X-Mailer: git-send-email 2.1.4 > > > > + 1. EXTRA_CFLAGS and EXTRA_LDFLAGS should be added to include the > NUMA headers and link the library respectively, > > + if the step :ref:`argment_the_cross_toolcain_with_numa_support` was > skipped therefore the toolchain was not > > + argmented with NUMA support. > > + > > + 2. RTE_DEVEL_BUILD has to be disabled, otherwise the numa.h file > > + gets > > If the warnings are from numa.h then please use -isystem > instead of disabling RTE_DEVEL_BUILD. > [Gavin Hu] This is a good advice, I verified it okay and can upload a new patch. > > + a lot of compiling errors of Werror=cast-qual, Werror=strict-prototypes > and Werror=old-style-definition. > > + An example is given below: > > + > > + .. code-block:: console > > + > > + make -j CROSS=aarch64-linux-gnu- CONFIG_RTE_KNI_KMOD=n > CONFIG_RTE_EAL_IGB_UIO=n > > + RTE_DEVEL_BUILD=n EXTRA_CFLAGS="-I/include" > EXTRA_LDFLAGS= > > + "-L/lib -lnuma" > > + > > As discussed earlier, meson cross build instruction is missing. > [Gavin Hu] I reproduced the meson build issue Bruce reported, as shown below. It was not introduced by gcc, nor clang, it was actually introduced by meson.build, see line #65 of http://www.dpdk.org/browse/dpdk/tree/config/meson.build Even worse, "has_argument" is not reliable(refer here: http://mesonbuild.com/Compiler-properties.html#has-argument) for some compilers. This is the case of gcc and clang, which caused the 4 warning options were included in the whole project, either the compiler is gcc or clang, cross or native. This finally caused the unrecognized warning options. I tried to disable the warning options, then the compiling got lots of noisy warnings and errors. To fix this issue, we need to create a meson subproject for pmdinfogen, the change is not little and I am not familiar with this. Any comments are welcome! [265/893] Compiling C object 'buildtools/pmdinfogen/pmdinfogen@exe/pmdinfogen.c.o'. warning: unknown warning option '-Wno-format-truncation' [-Wunknown-warning-option] 1 warning generated. > > > diff --git a/doc/guides/linux_gsg/index.rst > > b/doc/guides/linux_gsg/index.rst index 2a7bdfe..077f930 100644 > > --- a/doc/guides/linux_gsg/index.rst > > +++ b/doc/guides/linux_gsg/index.rst > > @@ -13,6 +13,7 @@ Getting Started Guide for Linux > > intro > > sys_reqs > > build_dpdk > > +cross_build_dpdk_for_arm64 > > linux_drivers > > build_sample_apps > > enable_func > > -- > > 2.1.4 > > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
