> Thanks for the info. I am not too familiar with rdma interfaces, well at
> least the way vpp is utilizing them. It seems its polling the interfaces
> just like dpdk.

Polling is the default for both dpdk and rdma interfaces. You can set them to 
interrupt mode or adaptive mode (automatically switch between interrupt and 
polling based on the load) mode with 'set interface rx-mode <interface> [queue 
<n>] [polling | interrupt | adaptive]'

> I am also able to see traffic flowing through vpp, however
> its seems I can still interact with the ports via the kernel. This means
> that the interfaces are still being utilized by the kernel yes?

Yes, both dpdk and rdma drivers use a bifurcated model like Linux macvlan: each 
new interface gets a specific mac address and the NIC HW is programmed to steer 
packets based on the dest mac. So Linux netdev gets a mac address and VPP 
interfaces other mac, and you can use them all in parallel.

> However my test traffic is flowing much more efficiently through the
> system than using just the interfaces with a basic linux kernel set up. I
> can only assume dpdk or rdma or a combination of both are being used
> properly. Matt was a great help and shared  this link <https://s3-
> docs.fd.io/vpp/22.10/developer/devicedrivers/rdma.html?highlight=rdma>
> to documentation from vpp on rdma, however I would to read more about how
> the RDMA + DPDK system works. Do you have any other literature or
> documentation I can read?

That's a broad question... Which kind of info are you looking for?

> Also, unrelated question, it appears with startup.conf I can set the
> number of rx/tx ques and size, what is the default values for this? Does
> it use whatever ethtool -l and ethtool -g uses? Or do I need to set to
> maximums for those values to apply?

ethtool parameters are not used for VPP.
For queue size, the defaults should be sane but can be tuned if needs be - 
basically you want it to be big enough to hide your processing latency but not 
bigger.
Number of tx queues defaults to the number of VPP threads by default which is 
the right thing to do.
Number of rx queues defaults to 1 which means only 1 VPP worker thread will 
process packets coming from this interface. Depending on your setup that might 
not be what you want. For example, if you have 4 VPP worker threads and only 1 
interface, you'll probably want the 4 worker threads to process packets. In 
that case you need to create 4 rx queues (1 for each worker).

ben
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21674): https://lists.fd.io/g/vpp-dev/message/21674
Mute This Topic: https://lists.fd.io/mt/92231790/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/1480452/21656/631435203/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to