Hi Florin, Please see inline.
Regards, Vivek -----Original Message----- From: Florin Coras <fcoras.li...@gmail.com> Sent: Thursday, March 12, 2020 8:09 PM To: Ole Troan <otr...@employees.org> Cc: Vivek Gupta <viv...@benisontech.com>; kusumanjal...@gmail.com; vpp-dev@lists.fd.io Subject: Re: [vpp-dev] Query about internal apps Hi Ole, Vivek, If I understand this right, you’re looking to intercept l2 packets in vpp (supposedly only from certain hosts), process them and maybe generate some return traffic. What is the payload of those l2 packets? Vivek> We are trying to intercept the complete l2 packets, coming on certain interfaces, and pass it on the user application and user application can then process those and forward them to the actual destination. Payload will be the regular ethernet packets. You could write a feature that inspects all traffic on a certain interface and intercepts the packets that you’re interested in. Vivek> However, for these intercepted packets, what should be right way to pass it to the VPP internal application? For the session layer, we would need a transport_connection for L2_proto and pass traffic through the session using the fake tuple lookup. Alternatively, session layer supports pure shared memory transports, i.e., cut-through connections (see slide 16-18 here [1]). For instance, a vpp builtin application could receive data directly over shared memory from an external application. However, currently session layer only knows how to lookup 5-tuples, so the two peers (external app and vpp builtin app) need to agree on a shared “fake” 5-tuple. Regards, Florin [1] https://wiki.fd.io/images/9/9c/Vpp-hoststack-kc-eu19.pdf > On Mar 12, 2020, at 1:09 AM, Ole Troan <otr...@employees.org> wrote: > > Hi Vivek, > >> We are trying to achieve the mechanism, something similar to TAP interface, >> in VPP. >> >> So, the packets coming out of the TAP interface, will be directed directly >> to the application. The application will receive the packets, coming via TAP >> interface, process them and send it down via the Host stack. >> >> Possible options, we could think of are:- >> - Enhance the session layer to provide a L2 transport mechanism and add >> nodes like tap-input and tap-out which would achieve the same. >> - Use the existing session layer by doing a IP/UDP encap and send it to the >> APP, via session layer and use existing mechanism. >> This introduces an overhead of additional encap/decap. >> >> We wanted to check if there is any alternate option to directly transfer the >> packets from the plugin to the VPP App, without even involving the session >> layer and have no additional overhead encap/decap, > > Is this similar to the idea of routing directly to the application? > I.e. give each application an IP address (easier with IPv6), and the > application itself links in whatever transport layer it needs. In a VPP > context the application could sit behind a memif interface. The application > would need some support for IP address assignment, ARP/ND etc. > Userland networking taken to the extreme. ;-) > > Best regards, > Ole
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15769): https://lists.fd.io/g/vpp-dev/message/15769 Mute This Topic: https://lists.fd.io/mt/71885250/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
