On Wed, Mar 16, 2016 at 10:22:05AM +0200, Panu Matilainen wrote: > On 03/16/2016 10:19 AM, Ferruh Yigit wrote: > >On 3/16/2016 7:26 AM, Panu Matilainen wrote: > >>On 03/14/2016 05:32 PM, Ferruh Yigit wrote: > >>>On 3/9/2016 11:17 AM, Ferruh Yigit wrote: > >>>>This patch sent to keep record of latest status of the work. > >>>> > >>>> > >>>>This is slow data path communication implementation based on existing KNI. > >>>> > >>>>Difference is: librte_kni converted into a PMD, kdp kernel module is > >>>>almost > >>>>same except all control path functionality removed and some > >>>>simplification done. > >>>> > >>>>Motivation is to simplify slow path data communication. > >>>>Now any application can use this new PMD to send/get data to Linux kernel. > >>>> > >>>>PMD supports two communication methods: > >>>> > >>>>1) KDP kernel module > >>>>PMD initialization functions handles creating virtual interfaces (with > >>>>help of > >>>>kdp kernel module) and created FIFO. FIFO is used to share data between > >>>>userspace and kernelspace. This is default method. > >>>> > >>>>2) tun/tap module > >>>>When KDP module is not inserted, PMD creates tap interface and transfers > >>>>packets using tap interface. > >>>> > >>>>In long term this patch intends to replace the KNI and KNI will be > >>>>depreciated. > >>>> > >>> > >>>Self-NACK: Will work on another option that does not introduce new > >>>kernel module. > >>> > >> > >>Hmm, care to elaborate a bit? The second mode of this PMD already was > >>free of external kernel modules. Do you mean you'll be just removing > >>mode 1) from the PMD or looking at something completely different? > >> > >>Just thinking that tun/tap PMD sounds like a useful thing to have, I > >>hope you're not abandoning that. > >> > > > >It will be KNI PMD. > >Plan is to have something like KDP, but with existing KNI kernel module. > >There will be tun/tap support as fallback. > > Hum, now I'm confused. I was under the impression everybody hated KNI and > wanted to get rid of it, and certainly not build future solutions on top of > it? > KNI has it's issues - mainly: a) not being upstream and b) having large amounts of code to do port management in it, that is best handled by other means - but the code for transferring packets between kernel space and userspace is more performant and scalable than TUN/TAP, so we need to keep that around unless/until we can get TUN/TAP to reach the same performance levels.
Now, we are thinking of some ways in which that can be achieved, but any such solution is going to be a bit out, so making any driver for transferring packets from user->kernel and vice versa might as well take advantage of KNI as well as TUN/TAP so as to allow those who want the extra performance to have it. Regards, /Bruce
