Re: [dpdk-dev] [PATCH v2 0/6] fix ethdev device detach
Tested-by : Shachar Beiser The bug is fixed and now there is no crash: testpmd> port stop all Stopping ports... Done testpmd> port close all Closing ports... Done testpmd> port detach 0 Detaching a port... Invalid port 0 Please close port first testpmd> show port info 0 Invalid port 0 Valid port range is [0] testpmd> -Original Message- From: Gaetan Rivet [mailto:gaetan.ri...@6wind.com] Sent: Wednesday, July 26, 2017 4:36 PM To: dev@dpdk.org Cc: Gaetan Rivet ; Thomas Monjalon ; Shachar Beiser ; Adrien Mazarguil ; Nélio Laranjeiro Subject: [PATCH v2 0/6] fix ethdev device detach Device detach in librte_ether is rough right now. - Device hotplug capability is not properly checked - Device state should be set after a successful detach - MLX drivers are lacking the relevant flag - And this flag should actually be removed, thus occuring an API change for v17.11. An announce follows. Without this series on an MLX4 port: testpmd> port close 0 Closing ports... Port 0 is now not stopped Done testpmd> port stop 0 Stopping ports... Checking link statuses... Done testpmd> port close 0 Closing ports... Done testpmd> port detach 0 Detaching a port... testpmd> show port info 0 Segmentation fault (core dumped) With this series: testpmd> port stop 0 Stopping ports... Checking link statuses... Done testpmd> port detach 0 Detaching a port... Please close port first testpmd> port close 0 Closing ports... Done testpmd> port detach 0 Detaching a port... Port '00:03.0' is detached. Now total ports is 0 Done testpmd> show port info 0 Invalid port 0 Valid port range is [0] v2: - remove coredump from patchset Gaetan Rivet (6): ethdev: fix device state on detach ethdev: properly check detach capability net/mlx4: advertize the detach capability net/mlx5: advertize the detach capability app/testpmd: let the user know device detach failed doc: announce ethdev API change for detach flag app/test-pmd/testpmd.c | 9 ++--- doc/guides/rel_notes/deprecation.rst | 6 ++ drivers/net/mlx4/mlx4.c | 1 + drivers/net/mlx5/mlx5.c | 1 + lib/librte_ether/rte_ethdev.c| 11 +-- 5 files changed, 15 insertions(+), 13 deletions(-) -- 2.1.4
Re: [dpdk-dev] [PATCH 1/2] net/mlx5: fix missing packet type calculation
Looks good, Reviewed-by: Sagi Grimberg
Re: [dpdk-dev] [PATCH 2/2] net/mlx5: fix L4 packet type support
Looks good, Reviewed-by: Sagi Grimberg
[dpdk-dev] [PATCH 1/2] crypto/armv8: fix authentication session configuration
From: Srisivasubramanian S
For key sizes greater than digest length, pad with zero rather than
computing hash of the key itself.
Fixes: 169ca3db550c ("crypto/armv8: add PMD optimized for ARMv8 processors")
Cc: sta...@dpdk.org
Signed-off-by: Srisivasubramanian S
---
drivers/crypto/armv8/rte_armv8_pmd.c | 54
drivers/crypto/armv8/rte_armv8_pmd_private.h | 4 +--
2 files changed, 16 insertions(+), 42 deletions(-)
diff --git a/drivers/crypto/armv8/rte_armv8_pmd.c
b/drivers/crypto/armv8/rte_armv8_pmd.c
index c3ba439fc..a5c39c9b7 100644
--- a/drivers/crypto/armv8/rte_armv8_pmd.c
+++ b/drivers/crypto/armv8/rte_armv8_pmd.c
@@ -291,27 +291,14 @@ auth_set_prerequisites(struct armv8_crypto_session *sess,
* Generate authentication key, i_key_pad and o_key_pad.
*/
/* Zero memory under key */
- memset(sess->auth.hmac.key, 0, SHA1_AUTH_KEY_LENGTH);
+ memset(sess->auth.hmac.key, 0, SHA1_BLOCK_SIZE);
- if (xform->auth.key.length > SHA1_AUTH_KEY_LENGTH) {
- /*
-* In case the key is longer than 160 bits
-* the algorithm will use SHA1(key) instead.
-*/
- error = sha1_block(NULL, xform->auth.key.data,
- sess->auth.hmac.key, xform->auth.key.length);
- if (error != 0)
- return -1;
- } else {
- /*
-* Now copy the given authentication key to the session
-* key assuming that the session key is zeroed there is
-* no need for additional zero padding if the key is
-* shorter than SHA1_AUTH_KEY_LENGTH.
-*/
- rte_memcpy(sess->auth.hmac.key, xform->auth.key.data,
- xform->auth.key.length);
- }
+ /*
+* Now copy the given authentication key to the session
+* key.
+*/
+ rte_memcpy(sess->auth.hmac.key, xform->auth.key.data,
+ xform->auth.key.length);
/* Prepare HMAC padding: key|pattern */
auth_hmac_pad_prepare(sess, xform);
@@ -337,27 +324,14 @@ auth_set_prerequisites(struct armv8_crypto_session *sess,
* Generate authentication key, i_key_pad and o_key_pad.
*/
/* Zero memory under key */
- memset(sess->auth.hmac.key, 0, SHA256_AUTH_KEY_LENGTH);
+ memset(sess->auth.hmac.key, 0, SHA256_BLOCK_SIZE);
- if (xform->auth.key.length > SHA256_AUTH_KEY_LENGTH) {
- /*
-* In case the key is longer than 256 bits
-* the algorithm will use SHA256(key) instead.
-*/
- error = sha256_block(NULL, xform->auth.key.data,
- sess->auth.hmac.key, xform->auth.key.length);
- if (error != 0)
- return -1;
- } else {
- /*
-* Now copy the given authentication key to the session
-* key assuming that the session key is zeroed there is
-* no need for additional zero padding if the key is
-* shorter than SHA256_AUTH_KEY_LENGTH.
-*/
- rte_memcpy(sess->auth.hmac.key, xform->auth.key.data,
- xform->auth.key.length);
- }
+ /*
+* Now copy the given authentication key to the session
+* key.
+*/
+ rte_memcpy(sess->auth.hmac.key, xform->auth.key.data,
+ xform->auth.key.length);
/* Prepare HMAC padding: key|pattern */
auth_hmac_pad_prepare(sess, xform);
diff --git a/drivers/crypto/armv8/rte_armv8_pmd_private.h
b/drivers/crypto/armv8/rte_armv8_pmd_private.h
index 679a71af3..d02992a64 100644
--- a/drivers/crypto/armv8/rte_armv8_pmd_private.h
+++ b/drivers/crypto/armv8/rte_armv8_pmd_private.h
@@ -198,8 +198,8 @@ struct armv8_crypto_session {
uint8_t o_key_pad[SHA_BLOCK_MAX]
__rte_cache_aligned;
/**< outer pad (max supported block length) */
- uint8_t key[SHA_AUTH_KEY_MAX];
- /**< HMAC key (max supported length)*/
+ uint8_t key[SHA_BLOCK_MAX];
+
[dpdk-dev] [PATCH 2/2] crypto/armv8: fix HMAC supported key sizes
From: Srisivasubramanian S
For HMAC algorithms (SHAx-HMAC), the supported
key sizes are not a fixed value, but a range between
1 and the block size.
Fixes: 169ca3db550c ("crypto/armv8: add PMD optimized for ARMv8 processors")
Cc: sta...@dpdk.org
Signed-off-by: Srisivasubramanian S
Signed-off-by: Jerin Jacob
---
drivers/crypto/armv8/rte_armv8_pmd_ops.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/crypto/armv8/rte_armv8_pmd_ops.c
b/drivers/crypto/armv8/rte_armv8_pmd_ops.c
index f6f38037e..00297bebb 100644
--- a/drivers/crypto/armv8/rte_armv8_pmd_ops.c
+++ b/drivers/crypto/armv8/rte_armv8_pmd_ops.c
@@ -50,9 +50,9 @@ static const struct rte_cryptodev_capabilities
.algo = RTE_CRYPTO_AUTH_SHA1_HMAC,
.block_size = 64,
.key_size = {
- .min = 16,
- .max = 128,
- .increment = 0
+ .min = 1,
+ .max = 64,
+ .increment = 1
},
.digest_size = {
.min = 20,
@@ -71,9 +71,9 @@ static const struct rte_cryptodev_capabilities
.algo = RTE_CRYPTO_AUTH_SHA256_HMAC,
.block_size = 64,
.key_size = {
- .min = 16,
- .max = 128,
- .increment = 0
+ .min = 1,
+ .max = 64,
+ .increment = 1
},
.digest_size = {
.min = 32,
--
2.13.3
[dpdk-dev] [PATCH] maintainers: update for ARMv8 crypto PMD
Update the maintainers as Zbigniew no longer working for Cavium. Thanks to Zbigniew for his support and development of armv8 crypto driver. Signed-off-by: Jerin Jacob --- MAINTAINERS | 1 - 1 file changed, 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index dc52760b8..05e5456b4 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -517,7 +517,6 @@ T: git://dpdk.org/next/dpdk-next-crypto F: doc/guides/cryptodevs/features/default.ini ARMv8 Crypto PMD -M: Zbigniew Bodek M: Jerin Jacob F: drivers/crypto/armv8/ F: doc/guides/cryptodevs/armv8.rst -- 2.13.3
Re: [dpdk-dev] [pull-request] next-crypto 17.08 rc3
28/07/2017 19:45, Pablo de Lara: > http://dpdk.org/git/next/dpdk-next-crypto Pulled, thanks
Re: [dpdk-dev] [dpdk-stable] [PATCH 2/2] crypto/armv8: fix HMAC supported key sizes
30/07/2017 13:23, Jerin Jacob:
> From: Srisivasubramanian S
>
> For HMAC algorithms (SHAx-HMAC), the supported
> key sizes are not a fixed value, but a range between
> 1 and the block size.
>
> Fixes: 169ca3db550c ("crypto/armv8: add PMD optimized for ARMv8 processors")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Srisivasubramanian S
> Signed-off-by: Jerin Jacob
Series applies, thanks
Re: [dpdk-dev] [PATCH] maintainers: update for ARMv8 crypto PMD
30/07/2017 13:58, Jerin Jacob: > Update the maintainers as Zbigniew no longer working for Cavium. > Thanks to Zbigniew for his support and development of > armv8 crypto driver. > > Signed-off-by: Jerin Jacob Applied, thanks
Re: [dpdk-dev] [PATCH] net/dpaa2: enable Tx congestion state check
24/07/2017 09:31, Hemant Agrawal: > For larger packet size congestion is observed on Tx Queues. > This patch enables Tx Queue congestion state check support. > If congested, try to resend the packet few times. > > Signed-off-by: Nipun Gupta > Signed-off-by: Hemant Agrawal Applied, thanks
Re: [dpdk-dev] [PATCH 1/4] doc: update release notes for DPAA2 eventdev
24/07/2017 09:23, Hemant Agrawal: > announcing the addition of DPAA2 eventdev > > Signed-off-by: Hemant Agrawal Series applied, thanks
Re: [dpdk-dev] [PATCH v3] eal: disable NUMA related warnings on non-NUMA systems
> > Disable multiple NUMA warnings on non-NUMA systems. > > > > "EAL: eal_parse_sysfs_value(): cannot open sysfs value > > /sys/bus/pci/devices/:00:00.0/numa_node > > EAL: numa_node is invalid or not present. Set it 0 as default > > EAL: cannot open /proc/self/numa_maps, consider that all memory is > > in socket_id 0" > > > > Signed-off-by: Hemant Agrawal > > Tested-by: Jerin Jacob Applied, thanks
Re: [dpdk-dev] [PATCH] net/vmxnet3: restore correct filtering
24/07/2017 16:22, Charles (Chas) Williams:
> We should only restore shadow_vfta when hw_vlan_filter is active.
> Otherwise, we should restore the previous filtering behavior.
>
> Fixes: f003fc383487("vmxnet3: enable vlan filtering")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Chas Williams
Any review from VMware please?
Re: [dpdk-dev] [PATCH] bonding: fix segfault when primary slave set
26/07/2017 19:06, Declan Doherty:
> On 26/07/2017 4:50 PM, Tomasz Kulasek wrote:
> > rte_eth_bond_primary_set segfaults for invalid port. This patch moves
> > devices check before use of internal data.
> >
> > Fixes: 4c42498d916d ("net/bonding: allow slaves to also be bonded devices")
> >
> > Signed-off-by: Tomasz Kulasek
>
> Acked-by: Declan Doherty
Please Declan, review patches from other contributors, thanks
[dpdk-dev] [PATCH] lib/gro: fix bitwise overflow issue
When try to get GRO types, expression "1 << i" with type "int" may
overflow. This patch is to fix this issue.
Fixes: e996506a1c07 ("lib/gro: add Generic Receive Offload API framework")
Coverity issue: 158664
Signed-off-by: Jiayu Hu
---
lib/librte_gro/rte_gro.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/librte_gro/rte_gro.c b/lib/librte_gro/rte_gro.c
index 4998b90..7853246 100644
--- a/lib/librte_gro/rte_gro.c
+++ b/lib/librte_gro/rte_gro.c
@@ -81,7 +81,7 @@ rte_gro_ctx_create(const struct rte_gro_param *param)
return NULL;
for (i = 0; i < RTE_GRO_TYPE_MAX_NUM; i++) {
- gro_type_flag = 1 << i;
+ gro_type_flag = 1ULL << i;
if ((param->gro_types & gro_type_flag) == 0)
continue;
@@ -116,7 +116,7 @@ rte_gro_ctx_destroy(void *ctx)
if (gro_ctx == NULL)
return;
for (i = 0; i < RTE_GRO_TYPE_MAX_NUM; i++) {
- gro_type_flag = 1 << i;
+ gro_type_flag = 1ULL << i;
if ((gro_ctx->gro_types & gro_type_flag) == 0)
continue;
destroy_tbl_fn = tbl_destroy_fn[i];
@@ -265,7 +265,7 @@ rte_gro_get_pkt_count(void *ctx)
uint8_t i;
for (i = 0; i < RTE_GRO_TYPE_MAX_NUM; i++) {
- gro_type_flag = 1 << i;
+ gro_type_flag = 1ULL << i;
if ((gro_ctx->gro_types & gro_type_flag) == 0)
continue;
--
2.7.4
Re: [dpdk-dev] [PATCH] net/virtio: fix fail to configure rxq interrupt
On Wed, Jul 19, 2017 at 11:18:23AM +0800, Jiayu Hu wrote:
> When use rte_eth_dev_configure() to enable rx queue interrupt for virtio
> devices, virtio_configure_intr() isn't called to set up the interrupt
> environment, which causes rx queue interrupt setup failed. This patch is
> to fix this issue.
>
> Fixes: 26b683b4f7d0 ("net/virtio: setup Rx queue interrupts")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Jiayu Hu
Applied to dpdk-next-virtio.
Thanks.
--yliu
Re: [dpdk-dev] [PATCH] net/virtio: fix MAC addr not correct read
On Fri, Jul 28, 2017 at 11:01:14PM +, Jianfeng Tan wrote:
> When virtio-net devices are bound to uio_pci_generic, we get
> the wrong mac addr by virtio PMD. The wrong mac addr is a
> addr that is 4-byte left shift of the correct addr.
>
> It's a regression bug introduced by the cleanup patch below.
> The condition of if we set use_msix should be if msix is
> actually enabled. Only to check if there is a capability list
> is not enough. For example, binding a transitional device
> to uio_pci_device would trigger the wrong assignment of use_msix.
>
> To correct that, we also check the flags of msix capability to
> make sure it's enabled.
>
> Fixes: ee1843bd8907 ("net/virtio: remove redundant MSI-X detection")
> Cc: sta...@dpdk.org
> Cc: Zhihong Wang
> Cc: Yuanhan Liu
> Cc: Maxime Coquelin
>
> Reported-by: Vipin Varghese
> Signed-off-by: Jianfeng Tan
Applied to dpdk-next-virtio.
Thanks.
--yliu
Re: [dpdk-dev] [PATCH v3] net/i40e: fix PF notify issue when VF not up
> -Original Message-
> From: Li, Xiaoyun
> Sent: Friday, July 28, 2017 11:48 PM
> To: Wu, Jingjing
> Cc: dev@dpdk.org; Li, Xiaoyun ; sta...@dpdk.org
> Subject: [PATCH v3] net/i40e: fix PF notify issue when VF not up
>
> This patch stops PF from sending messages to inactive VF
> and modifies VF state to active when VF reset is completed.
>
> Fixes: 4861cde46116 ("i40e: new poll mode driver")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Xiaoyun Li
Acked-by: Jingjing Wu
Thanks
Jingjing
[dpdk-dev] [PATCH] net/bonding: validate bonded port id before access its data
Fixes: 4c42498d916d ("net/bonding: allow slaves to also be bonded devices")
Signed-off-by: Herbert Guan
---
drivers/net/bonding/rte_eth_bond_api.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bonding/rte_eth_bond_api.c
b/drivers/net/bonding/rte_eth_bond_api.c
index 824ab4f..6039500 100644
--- a/drivers/net/bonding/rte_eth_bond_api.c
+++ b/drivers/net/bonding/rte_eth_bond_api.c
@@ -514,11 +514,11 @@
{
struct bond_dev_private *internals;
- internals = rte_eth_devices[bonded_port_id].data->dev_private;
-
if (valid_bonded_port_id(bonded_port_id) != 0)
return -1;
+ internals = rte_eth_devices[bonded_port_id].data->dev_private;
+
if (valid_slave_port_id(slave_port_id, internals->mode) != 0)
return -1;
--
1.8.3.1
Re: [dpdk-dev] [PATCH] net/virtio: fix fail to configure rxq interrupt
On Mon, Jul 31, 2017 at 02:47:13AM +, Hu, Jiayu wrote:
> Hi Yuanhan,
>
> When we run l3fwd-power in VM with applying this patch in VM DPDK, QEMU will
> crash. I think this patch can't solve the problem correctly but I haven't
> figured out the reason. I am so sorry about it.
It's okay. But you should reply earlier here, so that I would not apply it.
Regarding the crash, I believe Jianfeng had met a similar issue before. IIRC,
it's about the order of event fd setups (or something like it). You might
want to contact him for more details.
And it's dropped.
--yliu
> > -Original Message-
> > From: Yuanhan Liu [mailto:y...@fridaylinux.org]
> > Sent: Monday, July 31, 2017 10:30
> > To: Hu, Jiayu
> > Cc: dev@dpdk.org; Tan, Jianfeng ; Yao, Lei A
> > ; sta...@dpdk.org
> > Subject: Re: [PATCH] net/virtio: fix fail to configure rxq interrupt
> >
> > On Wed, Jul 19, 2017 at 11:18:23AM +0800, Jiayu Hu wrote:
> > > When use rte_eth_dev_configure() to enable rx queue interrupt for virtio
> > > devices, virtio_configure_intr() isn't called to set up the interrupt
> > > environment, which causes rx queue interrupt setup failed. This patch is
> > > to fix this issue.
> > >
> > > Fixes: 26b683b4f7d0 ("net/virtio: setup Rx queue interrupts")
> > > Cc: sta...@dpdk.org
> > >
> > > Signed-off-by: Jiayu Hu
> >
> > Applied to dpdk-next-virtio.
> >
> > Thanks.
> >
> > --yliu
Re: [dpdk-dev] [PATCH 1/2] eventdev: add event adapter for ethernet Rx queues
> -Original Message-
> From: Jerin Jacob [mailto:jerin.ja...@caviumnetworks.com]
> Sent: Saturday, July 29, 2017 20:43
> To: Rao, Nikhil
> Cc: gage.e...@intel.com; dev@dpdk.org; tho...@monjalon.net;
> bruce.richard...@intel.com; harry.van.haa...@intel.com; Hemant Agrawal
> ; Nipun Gupta ;
> narender.vang...@intel.com; Abhinandan Gujjar
>
> Subject: Re: [PATCH 1/2] eventdev: add event adapter for ethernet Rx queues
>
> -Original Message-
> > Date: Thu, 27 Jul 2017 16:28:29 +0530
> > From: "Rao, Nikhil"
> > To: Jerin Jacob
> > CC: gage.e...@intel.com, dev@dpdk.org, tho...@monjalon.net,
> > bruce.richard...@intel.com, harry.van.haa...@intel.com,
> > hemant.agra...@nxp.com, nipun.gu...@nxp.com,
> narender.vang...@intel.com,
> > Abhinandan Gujjar , nikhil@intel.com
> > Subject: Re: [PATCH 1/2] eventdev: add event adapter for ethernet Rx queues
> > User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0)
> Gecko/20100101
> > Thunderbird/52.2.1
> >
> >
> >
> > In the case of a SW thread we would like to use the servicing weight
> > specified in the queue to do WRR across , in keeping with
>
> OK, then lets work together to address in transparent manner where it
> works for HW and SW.
>
> > the adaper per model, one way to do this is to use the
> > same cfg.service_name in the rte_event_eth_rx_adapter_configure() call.
> >
> > However this creates a few difficulties/inconsistencies:
>
> I agree. If we are thinking about WRR across then above
> proposal implementation creates inconsistencies. On the other side, it create
> challenges
> with HW implementation to have unified adapter API works for both HW and
> SW.
>
> >
> > 1)Service has the notion of a socket id. Multiple event dev IDs can be
> > included in the same service, each event dev has a socket ID -> this seems
> > to be an inconsistency that shouldn’t be allowed by design.
> >
> > 2)Say, the Rx event adapter doesn’t drop packets (could be configurable),
> > i.e, if events cannot be enqueued into the event device, these remain in a
> > buffer, when the buffer fills up packets aren’t dequeued from the eth
> > device.
> >
> > In the simplest case the Rx event adapter service has a single > device, event port> across multiple eth ports, it dequeues from the wrr[]
> > and buffers events, bulk enqueues BATCH_SIZE events into the > event port>.
> >
> > With adapters having different code can be
> > optimized so that adapters that have a common
> can
> > be made to refer to a common enqueue buffer { event dev, event port, buffer
> > } structure but this adds more book keeping in the code.
> >
> > 3)Every adapter can be configured with max_nb_rx ( a max nb of packets that
> > it can process in any invocation) – but the max_nb_rx seems like a service
> > level parameter instead of it being a summation across adapters.
> >
> > 1 & 3 could be solved by restricting the adapters to the same (as in the
> > first rte_event_eth_rx_adapter_configure() call) socket ID, and perhaps
> > using the max value of max_nb_rx or using the same value of max_nb_rx
> across
> > adapters. #2 is doable but has a bit of code complexity to handle the
> > generic case.
> >
> > Before we go there, I wanted to check if there is an alternative possible
> > that would remove the difficulties above. Essentially allow multiple ports
> > within an adapter but avoid the problem of the inconsistent
> > combinations when using multiple ports with a single eventdev.
> >
> > Instead of
> > ==
> > rte_event_eth_rx_adapter_create()
> > rte_event_eth_rx_adapter_get_info();
> > rte_event_eth_rx_adapter_configure();
> > rte_event_eth_rx_adapter_queue_add();
> > ==
> >
> > How about ?
> > ==
> >
> > rte_event_eth_rx_adapter_get_info(uint8_t dev_id, uint8_t eth_port_id,
> > struct rte_event_eth_rx_adap_info *info);
> >
> > struct rte_event_eth_rx_adap_info {
> > uint32_t cap;
> >
> > /* adapter has inbuilt port, no need to create producer port */
> > #define RTE_EVENT_ETHDEV_CAP_INBUILT_PORT (1ULL << 0)
> > /* adapter does not need service function */
> > #define RTE_EVENT_ETHDEV_CAP_NO_SERVICE_FUNC (1ULL << 1)
> >
> > }
> >
> > rte_event_eth_rx_adapter_conf cfg;
> > cfg.event_port = event_port;
> > cfg.service_name = “rx_adapter_service”;
>
> Does application need to specify the service name? IMO, it better a
> component(rx_adapter) defines it name and format and expose in
> rte_event_eth_rx_adapter.h
>
> >
> > // all ports in eth_port_id[] have cap =
> > //!RTE_EVENT_ETHDEV_CAP_INBUILT_PORT
> > // && ! RTE_EVENT_ETHDEV_CAP_NO_SERVICE_FUNC
> > rte_event_eth_rx_adapter_create(dev_id, eth_port_id[], N, id, &cfg);
>
> The downside might be:
> - application has different flow based on based on the capability.
> Listing down a few capabilities/limitation below.
>
> > ===
> > int rte_event_eth_rx_adapter_queue_add() would need a port id in the N>1
> > port case, that can be ignored if the adapter doesn’t need it (N=1).
> >
> > thanks for reading the
