How to perform packet en/decryption on Bluefield-2 without Crypto-enabled

Hi all,

I’m trying to perform AES-128-GCM decryption on incoming UDP packets on Bluefield 2. However, the Bluefield 2 I’m working on doesn’t have Crypto-enabled. Thus, I would like to ask how should I perform this task with the ARM cores using Software (C lib) ?

To my understanding, flow_fwd_target forwards packets to kernel for processing, but I’m unclear on how to modify the kernel function to perform the decryption and re-inject packets to a pipe for further forwarding.

Thank you!

why do you send packets to kernerl? I hink you should recv pkts by dpdk and decrypt them use c code/libs with the ARM cores !

Thank you so much for the timely response. Would you be so kind to point me to a source so I can begin reading? I’m new to dpdk/doca/Bluefield.

em, that’s a difficult task if you konw few about odpdk/doca/Bluefield! Maybe you could start with reading the doca samples which is location at DPU’S filesystem path: “/opt/mellanox/doca/samples/doca_flow”

Actually, I have been playing around with those samples for a while. I got the flow_shared_counter sample working recently, so I understand the flow matching, and forwarding packets to a designated pipe. However, I’m unclear on how to grep the packet content and perform the decryption before forwarding them to a designated pipe.

According to your earlier reply, the part that I’m struggling with is “recv pkts by dpdk”.

I config OVS to have 2 bridges, and flow_shared_counter sample simply forwards UDP packets between sf4 and sf5.

Screenshot 2024-03-20 at 4.35.57 PM

Firstly ,you must create an rss pipe on s4 to forward pkts to cpu, this could be done by set like this


and this

if have only one pipe in s4 or s5 doca port , you must set ”pipe_cfg.attr.is_root = true“, otherwise you will not recv the packets by dpdk/cpu

1 Like

if you want pass pkts between s4 and s5 , their representor sf4 and sf5 must be included in the same bridge

1 Like

you can only recv or send pkts with s4 and s5 through dpdk/cpu in the doca app, not their representors sf4 and sf5, you app’s dpdk args should include this " -a auxiliary:mlx5_core.sf.4 -a auxiliary:mlx5_core.sf.5"

1 Like

Awesome, I get what you’re instructing. And then, when packets get forwarded to RSS pipe, what function should I modify to get access to packet content to perform the decryption?

Yes, I noticed the fact that tcpdump won’t get any packet from interface sf4 and sf5 when the doca application is running. The packets can only be received by the doca app.

in doca app, you recv pkts through the dpdk pmd interface "rte_eth_rx_burst "and send pkts by using “rte_eth_tx_burst”, search the two func in the doca samples , you will get the usage detaily!

1 Like

I got it working, thank you so much for the guidance. It wasn’t that hard to do given the correct direction to read. I have one final question about the performance.

Can you please confirm? if I have only 1 RSS queue, then the decryption and forwarding will be performed by only 1 ARM core.

If this is the case, will creating more RSS queues and distributing the packets evenly between queues help to improve the performance? Since we would utilize all 8 ARM cores in parallel.

Yes!Generally speaking,the more the cores/queue you use, the better the performace !if the pkts are distributed averagly enough! But the throughput
could be not 8 times if use all of the arms! because another important factor is the ddr memory read/write speed, There must be a limit value for this!

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.