Hi Vivek, Inline.
> On Mar 12, 2020, at 11:06 PM, Vivek Gupta <viv...@benisontech.com> wrote: > > 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. FC: If you could deliver data directly to the builtin application, would you still need L2 framing? Do you plan to intercept just a subset of the L2 frames on an interface or all? Also, can the source of those frames be changed to use vcl? If not, your only option is to intercept packets somewhere in vpp. > > 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. FC: A transport is needed if the two peers must exchange data over network interfaces. Cut through connections have no transport protocol framing as they’re just shared memory buffers over which data can be exchanged with whatever framing the two peer apps decide (or no framing at all). Regards, Florin > > 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 (#15777): https://lists.fd.io/g/vpp-dev/message/15777 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] -=-=-=-=-=-=-=-=-=-=-=-
