Re: [dpdk-dev] [PATCH v4] eal: refactor rte_eal_init into sub-functions
On (02/02/24 11:21), Thomas Monjalon wrote: > Date: Fri, 02 Feb 2024 11:21:59 +0100 > From: Thomas Monjalon > To: Rahul Gupta > Cc: David Marchand , dev@dpdk.org, > bruce.richard...@intel.com, dmitry.kozl...@gmail.com, > step...@networkplumber.org, sovar...@linux.microsoft.com, > ok...@kernel.org, sujithsan...@microsoft.com, > sowmini.varad...@microsoft.com, krathina...@microsoft.com, > rahulrgupt...@gmail.com > Subject: Re: [dpdk-dev] [PATCH v4] eal: refactor rte_eal_init into > sub-functions > > 29/01/2024 08:55, David Marchand: > > On Mon, Jan 29, 2024 at 6:35 AM Rahul Gupta > > wrote: > > > > Looking at what this patch does.. I am under the impression all you > > > > really need is rte_eal_init without initial probing. > > > > Such behavior can probably be achieved with a allowlist set to a non > > > > existing device (like for example "-a :00:00.0"), then later, use > > > > device hotplug. > > > The patch will be useful to all the adapters irrespective of their > > > host plug support. > > > > I did not say hotplug support is needed. > > If what I described already works, this patch adds nothing. > > I agree with David. > Disabling initial probing should provide what you want. > Did you test his proposal? > > Yes, I was about to reply after testing same, will be done with testing in few days. But I think the bootup time saved by my patch and hot plug patch will be almost same, because apart from FLR (probe()) the extra work done by my patch (i.e. telemetry, rte_service_init() in parallel to mbuf pool creation) are consuming very less bootup time. So in future if more things are added to 2nd part of eal_init (i.e. rte_eal_init_async_setup()), then the bootup time will be less if we use my patch. I think we can defer this patch till then. Thanks, Rahul.
rss calculation as the nic
I am using mellanox Connectx6, dpdk 22
'MT2892 Family [ConnectX-6 Dx] 101d' if=ens5f1 drv=mlx5_core unused=igb_uio
I configure port with multiqueue and split traffic according to ip+port
I want to calculate the hash as the nic do, to be able to load balance traffic
( from another card ) - the information is inside the packet and not in in ip
and transport layer. For this purpose i need to be able to calculate the hash
value as the nic do for the first nic.
Here is the code i use to split traffic to rx queues
/*rte flow*/
const int MAX_PATTERN_IN_FLOW = 10;
const int MAX_ACTIONS_IN_FLOW = 10;
struct rte_flow_attr attr;
struct rte_flow_item pattern[MAX_PATTERN_IN_FLOW];
struct rte_flow_action actions[MAX_ACTIONS_IN_FLOW];
struct rte_flow *flow;
struct rte_flow_error error;
memset(pattern, 0, sizeof(pattern));
memset(actions, 0, sizeof(actions));
/* Set the rule attribute, only ingress packets will be checked. 8< */
memset(&attr, 0, sizeof(struct rte_flow_attr));
attr.ingress = 1;
pattern[0].type = RTE_FLOW_ITEM_TYPE_ETH;
pattern[0].spec = NULL;
pattern[1].type = RTE_FLOW_ITEM_TYPE_IPV4;
pattern[1].spec = NULL;
pattern[2].type = RTE_FLOW_ITEM_TYPE_GRE;
pattern[2].spec = NULL;
pattern[3].type = RTE_FLOW_ITEM_TYPE_ETH;
pattern[3].spec = NULL;
pattern[4].type = RTE_FLOW_ITEM_TYPE_IPV4;
pattern[4].spec = NULL;
pattern[5].type = RTE_FLOW_ITEM_TYPE_UDP;
pattern[5].spec = NULL;
// end the pattern array
pattern[6].type = RTE_FLOW_ITEM_TYPE_END;
struct rte_flow_action_rss rss_conf;
uint16_t queues[pi_nNumRxQueues];
rss_conf.func = RTE_ETH_HASH_FUNCTION_DEFAULT;
uint64_t hf = RTE_ETH_RSS_IP | RTE_ETH_RSS_TCP | RTE_ETH_RSS_UDP |
RTE_ETH_RSS_SCTP;
hf &= pi_devInfo.flow_type_rss_offloads;
rss_conf.types = hf;
rss_conf.queue_num = pi_nNumRxQueues;
for (int nqQueueIndex= 0; nqQueueIndex < pi_nNumRxQueues;
nqQueueIndex++)
queues[nqQueueIndex] = nqQueueIndex;
rss_conf.queue = queues;
rss_conf.key_len = 0;
rss_conf.key = NULL;
rss_conf.level = 2;
// create the drop action
actions[0].type = RTE_FLOW_ACTION_TYPE_RSS;
actions[0].conf = &rss_conf;
actions[1].type = RTE_FLOW_ACTION_TYPE_END;
// validate and create the flow rule
if (rte_flow_validate(pi_nPort, &attr, pattern, actions, &error)==0)
{
flow = rte_flow_create(pi_nPort, &attr, pattern, actions, &error);
if(flow){//success}
else{//error}
}
else {error}
}
And this is how i tried to get the hash value saved in the mbuf, but failed
uint8_t rss_hash_default_key[] = {
0x2c, 0xc6, 0x81, 0xd1,
0x5b, 0xdb, 0xf4, 0xf7,
0xfc, 0xa2, 0x83, 0x19,
0xdb, 0x1a, 0x3e, 0x94,
0x6b, 0x9e, 0x38, 0xd9,
0x2c, 0x9c, 0x03, 0xd1,
0xad, 0x99, 0x44, 0xa7,
0xd9, 0x56, 0x3d, 0x59,
0x06, 0x3c, 0x25, 0xf3,
0xfc, 0x1f, 0xdc, 0x2a,
};
static inline uint32_t
do_softrss(struct rte_mbuf *m)
{
uint32_t input_len;
struct rte_ipv4_tuple ipv4_tuple;
char * pRawPacket = static_cast(rte_pktmbuf_mtod(pi_mbuf, void* ));
IpHeader * pIpHeader = (IpHeader *)(pRawPacket + offsetOfIp);
if(pIpHeader->GetVersion()==4)
{
ipv4_tuple.src_addr =
rte_be_to_cpu_32(pIpHeader->dwSrcAddressBigEndian);
ipv4_tuple.dst_addr =
rte_be_to_cpu_32(pIpHeader->dwDstAddressBigEndian);
ipv4_tuple.sport = *(uint16_t*)(pRawPacket + transportLayerOffset);
ipv4_tuple.dport = *(uint16_t*)(pRawPacket + transportLayerOffset+2);
input_len = RTE_THASH_V4_L3_LEN;
return rte_softrss_be((uint32_t *)&ipv4_tuple, input_len, rss_key_be);
}
return 0;
}
new_rss = do_softrss(mbuf_pointer);
std::cout<< std::hex << mbuf_pointer->hash.rss << " -> " << new_rss << std::dec
<< std::endl;
And i get a different value than the mbuf_pointer->hash.rss
5ed28a5c -> 33eb33eb
974c1896 -> 24e224e2
1edf1638 -> 21752175
8a54c19 -> 80638063
459a6f76 -> 1b351b35
1cdf1d1c -> e53be53b
I understand it is possible to do it, but i don't get the same value ***
ethtool -i ens5f0
driver: mlx5_core
version: 5.8-3.0.7
firmware-version: 22.32.2004 (MT_000437)
expansion-rom-version:
bus-info: :83:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: yes
Re: [PATCH] dmadev: standardize alignment and allocation
Hi Pavan,
Alloc fp_objects from rte_memory is a good idea, but this may cause
the rte_memory memory leak, especially in multi-process scenario.
Currently, there is no mechanism for releasing such a rte_memory which
don't belong to any driver.
So I suggest: maybe we could add rte_mem_align API which alloc from libc
and use in this cases.
BTW: the rte_dma_devices is only used in control-path, so it don't need
use rte_memory API, but I think it could use the new rte_mem_align API.
Thanks
On 2024/2/2 17:06, pbhagavat...@marvell.com wrote:
> From: Pavan Nikhilesh
>
> Align fp_objects based on cacheline size, allocate
> devices and fp_objects memory on hugepages.
>
> Signed-off-by: Pavan Nikhilesh
> ---
> lib/dmadev/rte_dmadev.c | 6 ++
> lib/dmadev/rte_dmadev_core.h | 2 +-
> 2 files changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/lib/dmadev/rte_dmadev.c b/lib/dmadev/rte_dmadev.c
> index 67434c805f43..1fe1434019f0 100644
> --- a/lib/dmadev/rte_dmadev.c
> +++ b/lib/dmadev/rte_dmadev.c
> @@ -143,10 +143,9 @@ dma_fp_data_prepare(void)
>*/
> size = dma_devices_max * sizeof(struct rte_dma_fp_object) +
> RTE_CACHE_LINE_SIZE;
> - ptr = malloc(size);
> + ptr = rte_zmalloc("", size, RTE_CACHE_LINE_SIZE);
> if (ptr == NULL)
> return -ENOMEM;
> - memset(ptr, 0, size);
>
> rte_dma_fp_objs = RTE_PTR_ALIGN(ptr, RTE_CACHE_LINE_SIZE);
> for (i = 0; i < dma_devices_max; i++)
> @@ -164,10 +163,9 @@ dma_dev_data_prepare(void)
> return 0;
>
> size = dma_devices_max * sizeof(struct rte_dma_dev);
> - rte_dma_devices = malloc(size);
> + rte_dma_devices = rte_zmalloc("", size, RTE_CACHE_LINE_SIZE);
> if (rte_dma_devices == NULL)
> return -ENOMEM;
> - memset(rte_dma_devices, 0, size);
>
> return 0;
> }
> diff --git a/lib/dmadev/rte_dmadev_core.h b/lib/dmadev/rte_dmadev_core.h
> index 064785686f7f..e8239c2d22b6 100644
> --- a/lib/dmadev/rte_dmadev_core.h
> +++ b/lib/dmadev/rte_dmadev_core.h
> @@ -73,7 +73,7 @@ struct rte_dma_fp_object {
> rte_dma_completed_tcompleted;
> rte_dma_completed_status_t completed_status;
> rte_dma_burst_capacity_t burst_capacity;
> -} __rte_aligned(128);
> +} __rte_cache_aligned;
>
> extern struct rte_dma_fp_object *rte_dma_fp_objs;
>
>
Re: [PATCH v7 11/19] crypto/armv8: do not use PMD logtype
On 2024/2/3 12:11 PM, Stephen Hemminger wrote:
Driver already has logging macros, just not used in one place.
Fixes: 169ca3db550c ("crypto/armv8: add PMD optimized for ARMv8 processors")
Signed-off-by: Stephen Hemminger
---
drivers/crypto/armv8/rte_armv8_pmd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/armv8/rte_armv8_pmd.c
b/drivers/crypto/armv8/rte_armv8_pmd.c
index 824a2cc7352a..026cdf5105dd 100644
--- a/drivers/crypto/armv8/rte_armv8_pmd.c
+++ b/drivers/crypto/armv8/rte_armv8_pmd.c
@@ -833,8 +833,8 @@ cryptodev_armv8_crypto_uninit(struct rte_vdev_device *vdev)
if (name == NULL)
return -EINVAL;
- RTE_LOG(INFO, PMD,
- "Closing ARMv8 crypto device %s on numa socket %u\n",
+ ARVM8_CRYPTO_LOG_INFO(
Typo to fix. It is ARMV8_CRYPTO_LOG_INFO.
+ "Closing ARMv8 crypto device %s on numa socket %u",
name, rte_socket_id());
cryptodev = rte_cryptodev_pmd_get_named_dev(name);
