[dpdk-dev] [RFC 0/2] slow data path communication between DPDK port and Linux
On Fri, Jan 22, 2016 at 06:15:40PM +0100, Thomas Monjalon wrote: > 2016-01-22 16:56, Ferruh Yigit: > > On Fri, Jan 22, 2016 at 05:31:45PM +0100, Thomas Monjalon wrote: > > > Hi Ferruh, > > > > > > Not commenting the implementation, just the method. > > > > > > 2016-01-22 16:00, Ferruh Yigit: > > > > 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. > > > > > > Is there a chance to submit such kernel module on LKML instead of DPDK? > > > We should avoid maintaining some out-of-tree modules. > > > > The ones I have sent are not generic enough to be in Linux tree. > > I've not read the details. > What is missing to be generic? > > > We already maintain kni kernel module, > > Yes it is painful and not accepted in some Linux distros. > > > these patches are part of effort to make > > kni more maintainable, by separation of concerns, removing network drivers > > from it, > > and simplifying some of code. > > Your patch is not removing KNI unfortunately ;) > One step at a time. :-) I think we all want to get there.
[dpdk-dev] [RFC 0/2] slow data path communication between DPDK port and Linux
2016-01-22 16:56, Ferruh Yigit: > On Fri, Jan 22, 2016 at 05:31:45PM +0100, Thomas Monjalon wrote: > > Hi Ferruh, > > > > Not commenting the implementation, just the method. > > > > 2016-01-22 16:00, Ferruh Yigit: > > > 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. > > > > Is there a chance to submit such kernel module on LKML instead of DPDK? > > We should avoid maintaining some out-of-tree modules. > > The ones I have sent are not generic enough to be in Linux tree. I've not read the details. What is missing to be generic? > We already maintain kni kernel module, Yes it is painful and not accepted in some Linux distros. > these patches are part of effort to make > kni more maintainable, by separation of concerns, removing network drivers > from it, > and simplifying some of code. Your patch is not removing KNI unfortunately ;) > For this patch set, tun/tap interface can be alternative, and it looks like it > removes out-of-tree kernel module requirement, unless people want current > FIFO implementation because of better performance. > > For control path, unfortunately I am not aware of any solution without > out-of-tree > kernel module support. > > Thanks, > ferruh
[dpdk-dev] [RFC 0/2] slow data path communication between DPDK port and Linux
Hi Ferruh, Not commenting the implementation, just the method. 2016-01-22 16:00, Ferruh Yigit: > 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. Is there a chance to submit such kernel module on LKML instead of DPDK? We should avoid maintaining some out-of-tree modules.
[dpdk-dev] [RFC 0/2] slow data path communication between DPDK port and Linux
On Fri, Jan 22, 2016 at 05:31:45PM +0100, Thomas Monjalon wrote: > Hi Ferruh, > > Not commenting the implementation, just the method. > > 2016-01-22 16:00, Ferruh Yigit: > > 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. > > Is there a chance to submit such kernel module on LKML instead of DPDK? > We should avoid maintaining some out-of-tree modules. The ones I have sent are not generic enough to be in Linux tree. We already maintain kni kernel module, these patches are part of effort to make kni more maintainable, by separation of concerns, removing network drivers from it, and simplifying some of code. For this patch set, tun/tap interface can be alternative, and it looks like it removes out-of-tree kernel module requirement, unless people want current FIFO implementation because of better performance. For control path, unfortunately I am not aware of any solution without out-of-tree kernel module support. Thanks, ferruh
[dpdk-dev] [RFC 0/2] slow data path communication between DPDK port and Linux
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 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. Sample usage: 1) Transfer any packet received from NIC that bound to DPDK, to the Linux kernel a) insert kdp kernel module insmod build/kmod/rte_kdp.ko b) bind NIC to the DPDK using dpdk_nic_bind.py c) ./testpmd --vdev eth_kdp0 c1) testpmd show two ports, one of them physical, other virtual ... Configuring Port 0 (socket 0) Port 0: 00:00:00:00:00:00 Configuring Port 1 (socket 0) ... Checking link statuses... Port 0 Link Up - speed 1 Mbps - full-duplex Port 1 Link Up - speed 1 Mbps - full-duplex Done c2) This will create "kdp0" Linux interface $ ip l show kdp0 21: kdp0: mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff d) Linux port can be used for data d1) $ ifconfig kdp0 1.0.0.2 $ ping 1.0.0.1 PING 1.0.0.1 (1.0.0.1) 56(84) bytes of data. 64 bytes from 1.0.0.1: icmp_seq=1 ttl=64 time=0.789 ms 64 bytes from 1.0.0.1: icmp_seq=2 ttl=64 time=0.881 ms d2) $ tcpdump -nn -i kdp0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on kdp0, link-type EN10MB (Ethernet), capture size 262144 bytes 15:01:22.407506 IP 1.0.0.1 > 1.0.0.2: ICMP echo request, id 40016, seq 18, length 64 15:01:22.408521 IP 1.0.0.2 > 1.0.0.1: ICMP echo reply, id 40016, seq 18, length 64 2) Data travels between virtual Linux interfaces pass from DPDK application, application can alter data a) insert kdp kernel module insmod build/kmod/rte_kdp.ko b) No physical NIC involved c) ./testpmd --vdev eth_kdp0 --vdev eth_kdp1 c1) testpmd show two ports, both of them are virtual ... Configuring Port 0 (socket 0) Port 0: 00:00:00:00:00:00 Configuring Port 1 (socket 0) Port 1: 00:00:00:00:00:00 Checking link statuses... Port 0 Link Up - speed 1 Mbps - full-duplex Port 1 Link Up - speed 1 Mbps - full-duplex Done c2) This will create "kdp0" and "kdp1" Linux interfaces $ ip l show kdp0; ip l show kdp1 22: kdp0: mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 23: kdp1: mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff d) Data travel between virtual ports pass from DPDK application $ifconfig kdp0 1.0.0.1 $ifconfig kdp1 1.0.0.2 d1) $ ping 1.0.0.1 PING 1.0.0.1 (1.0.0.1) 56(84) bytes of data. 64 bytes from 1.0.0.1: icmp_seq=1 ttl=64 time=3.57 ms 64 bytes from 1.0.0.1: icmp_seq=2 ttl=64 time=1.85 ms 64 bytes from 1.0.0.1: icmp_seq=3 ttl=64 time=1.89 ms d2) $ tcpdump -nn -i kdp0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on kdp0, link-type EN10MB (Ethernet), capture size 262144 bytes 15:20:51.908543 IP 1.0.0.2 > 1.0.0.1: ICMP echo request, id 41234, seq 1, length 64 15:20:51.909570 IP 1.0.0.1 > 1.0.0.2: ICMP echo reply, id 41234, seq 1, length 64 15:20:52.909551 IP 1.0.0.2 > 1.0.0.1: ICMP echo request, id 41234, seq 2, length 64 15:20:52.910577 IP 1.0.0.1 > 1.0.0.2: ICMP echo reply, id 41234, seq 2, length 64 Ferruh Yigit (2): kdp: add kernel data path kernel module kdp: add virtual PMD for kernel slow data path communication config/common_linuxapp | 9 +- drivers/net/Makefile | 3 +- drivers/net/kdp/Makefile | 60 +++ drivers/net/kdp/rte_eth_kdp.c | 405 +++ drivers/net/kdp/rte_kdp.c | 365 + drivers/net/kdp/rte_kdp.h | 113 drivers/net/kdp/rte_kdp_fifo.h | 91 drivers/net/kdp/rte_pmd_kdp_version.map| 4 + lib/librte_eal/common/include/rte_log.h| 3 +- lib/librte_eal/linuxapp/Makefile | 5 +- lib/librte_eal/linuxapp/eal/Makefile | 3 +- .../linuxapp/eal/include/exec-env/rte_kdp_common.h | 138 + lib/librte_eal/linuxapp/kdp/Makefile | 56 ++ lib/librte_eal/linuxapp/kdp/compat.h | 29 ++ lib/librte_eal/linuxapp/kdp/kdp_dev.h | 85 +++ lib/librte_eal/linuxapp/kdp/kdp_fifo.h | 94 lib/librte_eal/linuxapp/kdp/kdp_misc.c | 463 + lib/librte_eal/linuxapp/kdp/kdp_net.c | 578 + mk/rte.app.mk | 3 +- 19 files changed, 2501 insertions(+), 6 deletions(-)
