Re: [PATCH] testsuite: dpdk: Add l2fwd example which is based on DPDK.

From: Jan Kiszka <jan.kiszka@siemens.com>
To: "Chen, Hongzhan" <hongzhan.chen@intel.com>,
	"xenomai@lists.linux.dev" <xenomai@lists.linux.dev>
Subject: Re: [PATCH] testsuite: dpdk: Add l2fwd example which is based on DPDK.
Date: Tue, 31 Jan 2023 08:26:58 +0100	[thread overview]
Message-ID: <32e8a845-7f5b-3e0e-db97-087e123a662f@siemens.com> (raw)
In-Reply-To: <BY5PR11MB427681AA9D23FEFA04E1748CF2D09@BY5PR11MB4276.namprd11.prod.outlook.com>

On 31.01.23 06:10, Chen, Hongzhan wrote:
> 
> 
>> -----Original Message-----
>> From: Jan Kiszka <jan.kiszka@siemens.com>
>> Sent: Thursday, January 19, 2023 1:44 AM
>> To: Chen, Hongzhan <hongzhan.chen@intel.com>; xenomai@lists.linux.dev
>> Subject: Re: [PATCH] testsuite: dpdk: Add l2fwd example which is based on
>> DPDK.
>>
>> On 18.01.23 14:05, Hongzhan Chen wrote:
>>> The L2 Forwarding sample application(l2fwd) is a simple
>>> example of packet processing using the Data Plane
>>> Development Kit (DPDK).
>>
>> Can you elaborate a bit on the envisioned use cases here and go more
>> into details in the accompanied documentation? The latter only describes
>> the "how", not at all the "why" (or "which use cases"). Some words on
>> the threading model (or limitations of it) would surely be good as well
>> ("how can I integrate this pattern into a real application?").
>>
>> Regarding the patch itself, you should go over it again and eliminate
>> debugging left-overs as well as unrelated changes (there is one at least
>> in testsuite/Makefile.am). The way of the integration looks fine to me
>> in principle.
>>
>> BTW, what prevents the usage of the VFIO driver so far?
> 
> I have not looked into and tried VFIO driver so far. Last time you told me that we may need to
> develop or port VFIO related drivers if we want to use VFIO-based dpdk in Xenomai but UIO-based 
> does not such issue. I maybe misunderstood what you guided. If the main difference between uio and vfio is that vfio is capable of programming the platform's IOMMU as described in [1], after vfio init, there is no linux syscall involved during receiving and transmitting packets just as UIO case, we can do same thing for VFIO with ported l2fwd.

I haven't looked into VFIO myself, but the key question is whether some
userspace activity in the primary domain could trigger mapping activity
of the driver in the secondary one. If not, VFIO should be fine. If so,
and that was the case for some RTnet drivers, we would need to avoid
that. I was just wondering if you explored the path already and could
share your experience.

Jan

> 
> Regards
> 
> Hongzhan Chen
> 
> [1]: https://spdk.io/doc/userspace.html#:~:text=The%20primary%20difference%20between%20uio,User%20Space%20for%20full%20details.
>>
>> Jan
>>
>> --
>> Siemens AG, Technology
>> Competence Center Embedded Linux
> 

-- 
Siemens AG, Technology
Competence Center Embedded Linux