Re: [vpp-dev] Query about internal apps

[Florin Coras]

Hi Kusuma, 

Not sure I understand the question. You want to deliver data to internal 
applications (supposedly using the session layer) without going through nodes 
like ip-local? 

If not, what do you mean by “sending through host stack”?

Regards,
Florin

> On Mar 11, 2020, at 11:16 AM, Kusuma DS  wrote:
> 
> Hi, 
> 
> Is there any method to send packets directly to internal apps without sending 
> through Host stack? 
> 
> 
> Regards, 
> Kusuma
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15731): https://lists.fd.io/g/vpp-dev/message/15731
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]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Query about internal apps

[Kusuma DS]

Hi Florin,

I wanted to avoid using session api.
I meant host stack is session apis.

Is there any method to send the data to internal apps?

Regards,
Kusuma

On Wed, 11 Mar, 2020, 11:56 PM Florin Coras,  wrote:

> Hi Kusuma,
>
> Not sure I understand the question. You want to deliver data to internal
> applications (supposedly using the session layer) without going through
> nodes like ip-local?
>
> If not, what do you mean by “sending through host stack”?
>
> Regards,
> Florin
>
> > On Mar 11, 2020, at 11:16 AM, Kusuma DS  wrote:
> >
> > Hi,
> >
> > Is there any method to send packets directly to internal apps without
> sending through Host stack?
> >
> >
> > Regards,
> > Kusuma
> > 
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15732): https://lists.fd.io/g/vpp-dev/message/15732
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]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Query about internal apps

[Vivek Gupta]

Hi Florin,

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,

Please let us know your comments on the same.

Regards,
Vivek

From: vpp-dev@lists.fd.io  On Behalf Of Kusuma DS via 
Lists.Fd.Io
Sent: Thursday, March 12, 2020 12:34 AM
To: Florin Coras 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Query about internal apps

Hi Florin,

I wanted to avoid using session api.
I meant host stack is session apis.

Is there any method to send the data to internal apps?

Regards,
Kusuma

On Wed, 11 Mar, 2020, 11:56 PM Florin Coras, 
mailto:fcoras.li...@gmail.com>> wrote:
Hi Kusuma,

Not sure I understand the question. You want to deliver data to internal 
applications (supposedly using the session layer) without going through nodes 
like ip-local?

If not, what do you mean by “sending through host stack”?

Regards,
Florin

> On Mar 11, 2020, at 11:16 AM, Kusuma DS 
> mailto:kusumanjal...@gmail.com>> wrote:
>
> Hi,
>
> Is there any method to send packets directly to internal apps without sending 
> through Host stack?
>
>
> Regards,
> Kusuma
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15734): https://lists.fd.io/g/vpp-dev/message/15734
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]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Query about internal apps

[Vivek Gupta]

Just to add:-

One other option, we considered, was to make it an external app, and transfer 
the packets via memif interface to the application and in the return path use 
VCL to give it back to VPP.
But then also we will add additional overhead in the send and receive path.

Looking forward to your inputs.

Regards,
Vivek

From: Vivek Gupta
Sent: Thursday, March 12, 2020 9:16 AM
To: kusumanjal...@gmail.com; Florin Coras 
Cc: vpp-dev@lists.fd.io
Subject: RE: [vpp-dev] Query about internal apps

Hi Florin,

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,

Please let us know your comments on the same.

Regards,
Vivek

From: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> 
mailto:vpp-dev@lists.fd.io>> On Behalf Of Kusuma DS via 
Lists.Fd.Io
Sent: Thursday, March 12, 2020 12:34 AM
To: Florin Coras mailto:fcoras.li...@gmail.com>>
Cc: vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] Query about internal apps

Hi Florin,

I wanted to avoid using session api.
I meant host stack is session apis.

Is there any method to send the data to internal apps?

Regards,
Kusuma

On Wed, 11 Mar, 2020, 11:56 PM Florin Coras, 
mailto:fcoras.li...@gmail.com>> wrote:
Hi Kusuma,

Not sure I understand the question. You want to deliver data to internal 
applications (supposedly using the session layer) without going through nodes 
like ip-local?

If not, what do you mean by “sending through host stack”?

Regards,
Florin

> On Mar 11, 2020, at 11:16 AM, Kusuma DS 
> mailto:kusumanjal...@gmail.com>> wrote:
>
> Hi,
>
> Is there any method to send packets directly to internal apps without sending 
> through Host stack?
>
>
> Regards,
> Kusuma
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15735): https://lists.fd.io/g/vpp-dev/message/15735
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]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Query about internal apps

[Florin Coras]

Hi Kasuma, 

Applications that attach to the session layer (through the session api) can 
read/write data, i.e., byte stream or datagrams, that are delivered from/to the 
underlying transports (tcp, udp, quic, tls) via specific session layer apis or 
POSIX-like apis, if they use the vcl library. 

If you want to deliver udp packets to/from a vpp "builtin application" see 
udp_register_dst_port(). On the other hand, if you want to the same with the 
rest of the transport protocol, you’ll have to reimplement them since the ones 
we have are “plugged” into the session layer. 

Regards,
Florin

> On Mar 11, 2020, at 12:03 PM, Kusuma DS  wrote:
> 
> Hi Florin, 
> 
> I wanted to avoid using session api. 
> I meant host stack is session apis. 
> 
> Is there any method to send the data to internal apps? 
> 
> Regards, 
> Kusuma
> 
> On Wed, 11 Mar, 2020, 11:56 PM Florin Coras,  > wrote:
> Hi Kusuma, 
> 
> Not sure I understand the question. You want to deliver data to internal 
> applications (supposedly using the session layer) without going through nodes 
> like ip-local? 
> 
> If not, what do you mean by “sending through host stack”?
> 
> Regards,
> Florin
> 
> > On Mar 11, 2020, at 11:16 AM, Kusuma DS  > > wrote:
> > 
> > Hi, 
> > 
> > Is there any method to send packets directly to internal apps without 
> > sending through Host stack? 
> > 
> > 
> > Regards, 
> > Kusuma
> > 
> 
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15736): https://lists.fd.io/g/vpp-dev/message/15736
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]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Query about internal apps

[Ole Troan]

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 (#15737): https://lists.fd.io/g/vpp-dev/message/15737
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]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Query about internal apps

[Florin Coras]

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? 

You could write a feature that inspects all traffic on a certain interface and 
intercepts the packets that you’re interested in. 

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  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 (#15758): https://lists.fd.io/g/vpp-dev/message/15758
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]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Query about internal apps

[Vivek Gupta]

Hi Ole,

Please see inline.

Regards,
Vivek

-Original Message-
From: otr...@employees.org  
Sent: Thursday, March 12, 2020 1:39 PM
To: Vivek Gupta 
Cc: kusumanjal...@gmail.com; Florin Coras ; 
vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Query about internal apps

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. ;-)
Vivek> It is similar to that. We need the application to define it's own 
routing and packet processing. 
Best regards,
Ole
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#15768): https://lists.fd.io/g/vpp-dev/message/15768
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]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Query about internal apps

[Vivek Gupta]

Hi Florin,

Please see inline.

Regards,
Vivek

-Original Message-
From: Florin Coras  
Sent: Thursday, March 12, 2020 8:09 PM
To: Ole Troan 
Cc: Vivek Gupta ; 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  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]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Query about internal apps

[Florin Coras]

Hi Vivek, 

Inline.

> On Mar 12, 2020, at 11:06 PM, Vivek Gupta  wrote:
> 
> Hi Florin,
> 
> Please see inline.
> 
> Regards,
> Vivek
> 
> -Original Message-
> From: Florin Coras  
> Sent: Thursday, March 12, 2020 8:09 PM
> To: Ole Troan 
> Cc: Vivek Gupta ; 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  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]
-=-=-=-=-=-=-=-=-=-=-=-