Re: [vpp-dev] VPP: A Terabit Secure Network Data-plane

[hemant via lists.fd.io]

I hope the Cisco router team using the CiscoONE asic is paying attention to
this VPP success.  The Cisco ASR1k router using CPP supports crypto at 100G
with latest CPP asic.  However, how does one get 10 Tbps crypto for the
CiscoONE router?  The only option is I see is using VPP IPSec with 10-15
server machines.  If the Cavium Nitrox is used with its, I think, 400 Gbps
crypto, one needs 25 of them inside the router to support 10 Tbps - these
many asics will suck so much power that the router, and the place the router
is deployed, will burn down.

Hemant

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Maciek
Konstantynowicz (mkonstan) via lists.fd.io
Sent: Wednesday, April 07, 2021 10:02 AM
To: csit-dev ; vpp-dev 
Subject: [vpp-dev] VPP: A Terabit Secure Network Data-plane

https://www.youtube.com/watch?v=ipQQmjzE_g0


smime.p7s
Description: S/MIME cryptographic signature

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19136): https://lists.fd.io/g/vpp-dev/message/19136
Mute This Topic: https://lists.fd.io/mt/81916291/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] VPP: A Terabit Secure Network Data-plane

[hemant via lists.fd.io]

Thanks.  

When do we test IPv6?

For IPv6, if one uses QUIC, did you see my email to vpp-dev recently to change 
clib_memcpy() calls in quic plugin code to clib_memcpy_fast()?

Thanks,

Hemant

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Maciek 
Konstantynowicz (mkonstan) via lists.fd.io
Sent: Wednesday, April 07, 2021 4:50 PM
To: hem...@mnkcg.com
Cc: csit-...@lists.fd.io; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] VPP: A Terabit Secure Network Data-plane

Hi, Arm tests are in CSIT reports e.g.

Taishan:
- ip4 
https://docs.fd.io/csit/rls2101/report/vpp_performance_tests/packet_throughput_graphs/ip4-3n-tsh-x520.html
- ipsec 
https://docs.fd.io/csit/rls2101/report/vpp_performance_tests/packet_throughput_graphs/ipsec-3n-tsh-x520.html

ThunderX2:
- ip4 
https://docs.fd.io/csit/rls2101/report/vpp_performance_tests/packet_throughput_graphs/ip4-2n-tx2-xl710.html

But these are older Arms. No N1/Ampere in LFN FD.io labs yet … been asking for 
a while.

Cheers,
Maciek

> On 7 Apr 2021, at 21:43, hemant via lists.fd.io 
>  wrote:
> 
> Thanks for sharing.  
> 
> Did you test on ARM to see what the performance is?
> 
> Hemant
> 
> -Original Message-
> From: vpp-dev@lists.fd.io  On Behalf Of Maciek 
> Konstantynowicz (mkonstan) via lists.fd.io
> Sent: Wednesday, April 07, 2021 10:02 AM
> To: csit-dev ; vpp-dev 
> Subject: [vpp-dev] VPP: A Terabit Secure Network Data-plane
> 
> https://www.youtube.com/watch?v=ipQQmjzE_g0
> 
> 
> 



smime.p7s
Description: S/MIME cryptographic signature

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19135): https://lists.fd.io/g/vpp-dev/message/19135
Mute This Topic: https://lists.fd.io/mt/81916291/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] VPP: A Terabit Secure Network Data-plane

[Maciek Konstantynowicz (mkonstan) via lists.fd.io]

Hi, Arm tests are in CSIT reports e.g.

Taishan:
- ip4 
https://docs.fd.io/csit/rls2101/report/vpp_performance_tests/packet_throughput_graphs/ip4-3n-tsh-x520.html
- ipsec 
https://docs.fd.io/csit/rls2101/report/vpp_performance_tests/packet_throughput_graphs/ipsec-3n-tsh-x520.html

ThunderX2:
- ip4 
https://docs.fd.io/csit/rls2101/report/vpp_performance_tests/packet_throughput_graphs/ip4-2n-tx2-xl710.html

But these are older Arms. No N1/Ampere in LFN FD.io labs yet … been asking for 
a while.

Cheers,
Maciek

> On 7 Apr 2021, at 21:43, hemant via lists.fd.io 
>  wrote:
> 
> Thanks for sharing.  
> 
> Did you test on ARM to see what the performance is?
> 
> Hemant
> 
> -Original Message-
> From: vpp-dev@lists.fd.io  On Behalf Of Maciek
> Konstantynowicz (mkonstan) via lists.fd.io
> Sent: Wednesday, April 07, 2021 10:02 AM
> To: csit-dev ; vpp-dev 
> Subject: [vpp-dev] VPP: A Terabit Secure Network Data-plane
> 
> https://www.youtube.com/watch?v=ipQQmjzE_g0
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19134): https://lists.fd.io/g/vpp-dev/message/19134
Mute This Topic: https://lists.fd.io/mt/81916291/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] VPP: A Terabit Secure Network Data-plane

[hemant via lists.fd.io]

Thanks for sharing.  

Did you test on ARM to see what the performance is?

Hemant

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Maciek
Konstantynowicz (mkonstan) via lists.fd.io
Sent: Wednesday, April 07, 2021 10:02 AM
To: csit-dev ; vpp-dev 
Subject: [vpp-dev] VPP: A Terabit Secure Network Data-plane

https://www.youtube.com/watch?v=ipQQmjzE_g0


smime.p7s
Description: S/MIME cryptographic signature

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19133): https://lists.fd.io/g/vpp-dev/message/19133
Mute This Topic: https://lists.fd.io/mt/81916291/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] IPSec - Clear packet's classification for SA lookup in VPP

[Manoj Kumar (manojku5) via lists.fd.io]

Hi Benoit,

Packets arriving for different VLAN-IDs – how is that information used for the 
SA lookups and where exactly in the VPP code?
We are also considering same tunnel end points (src-ip, dst-ip) in different 
VRFs. So, packets belonging to different such tunnels shall be able to identify 
the appropriate SAs.

 In tunnel protection mode, the packet classification is done via routing,
By this are you referring to :

  1.  We first create different sub interfaces on VPP – 1:1 mapped to IPSec 
tunnel
  2.  Program the appropriate SA DBs for these sub interfaces
  3.  Then steer the traffic towards the VPP on these sub-interfaces as per the 
tunnel configs.

Like Venu also asked, is there an example config for such scenario?

“Regards
--Manoj
From: Venumadhav Josyula 
Date: Wednesday, 7 April 2021 at 11:23 PM
To: "Benoit Ganne (bganne)" 
Cc: "Manoj Kumar (manojku5)" , "vpp-dev@lists.fd.io" 
, "Dharmarajan Subramanian (dharsubr)" 
, "Srinivas Davuluri (srinud)" , 
"Prashant Anand (prasanan)" 
Subject: Re: [vpp-dev] IPSec - Clear packet's classification for SA lookup in 
VPP

Hi Benoit,

Sorry to poke in the middle
   > - VLANs arrive on different sub-interfaces
   > - each sub-interface is in a different VRF
   > - each VRF has its own tunnel with a default route going through it

We would need something of this sort, can you provide example for the same in 
vpp ?

Thanks,
Regards,
Venu

On Wed, 7 Apr 2021 at 23:12, Benoit Ganne (bganne) via 
lists.fd.io 
mailto:cisco@lists.fd.io>> wrote:
Hi Manoj,

We support 2 main modes:
 - tunnel protection mode: https://wiki.fd.io/view/VPP/IPSec#Protection_Model
 - policy mode: https://wiki.fd.io/view/VPP/IPSec#Policy_Mode

In tunnel protection mode, the packet classification is done via routing, I 
suspect this is what you need, eg.
 - VLANs arrive on different sub-interfaces
 - each sub-interface is in a different VRF
 - each VRF has its own tunnel with a default route going through it

Of course you can build more complex topologies, eg. having multiple tunnels 
per VRF with different routes, etc.

Best
ben

> -Original Message-
> From: vpp-dev@lists.fd.io 
> mailto:vpp-dev@lists.fd.io>> On Behalf Of Manoj Kumar
> (manojku5) via lists.fd.io
> Sent: mercredi 7 avril 2021 19:19
> To: vpp-dev@lists.fd.io
> Cc: Dharmarajan Subramanian (dharsubr) 
> mailto:dhars...@cisco.com>>; Srinivas
> Davuluri (srinud) mailto:sri...@cisco.com>>; Prashant Anand 
> (prasanan)
> mailto:prasa...@cisco.com>>
> Subject: [vpp-dev] IPSec - Clear packet's classification for SA lookup in
> VPP
>
> Hi Team,
>
>
>
> We have some basic queries on the IPSEC support in VPP. Could someone
> please take a look?
>
>
>
> How does the clear packet classification and SA lookup happens in VPP for
> the packet? I mean, what all fields of the IP packet are considered for
> the SA lookup – can it support some L2/VLAN fields as well for this
> lookup?
>
> * Please share some code pointers towards this if possible.
>
>
>
> I came across esp4_encrypt_handoff() in ipsec_handoff.c file but could not
> find the caller for the same. Which code leg calls this?
>
> * This further points to esp4_encrypt_node() and to
> esp_encrypt_inline().
> * Inside esp_encrypt_inline(), I can see the code to access the SA for
> the packet. But looks like that is pre-populated in the packet/frame. Is
> that understanding correct? If yes, can you please point us to the code
> pointers where this is set – is it in the previous graph node before
> “esp4_encrypt_handoff”?
>
> 636   if (is_tun)
>
> 637 {
>
> 638   /* we are on a ipsec tunnel's feature arc */
>
> 639   vnet_buffer (b[0])->ipsec.sad_index =
>
> 640 sa_index0 = ipsec_tun_protect_get_sa_out
>
> 641 (vnet_buffer (b[0])->ip.adj_index[VLIB_TX]);
>
> 642 }
>
> 643   else
>
> 644 sa_index0 = vnet_buffer (b[0])->ipsec.sad_index;
>
> 645
>
>
>
> At a high level, we want to be able to support IPSEC for multiple VRFs and
> we would like to use an L2 encapsulation so that we can classify / find
> the SA for the clear text packet using the IP Header and the L2 fields. Is
> that supported?
>
> If yes, what is the control plane programming requirements for that and
> where is this classification done in the VPP code?
>
>
>
>
>
> Thanks & Regards
>
> --Manoj
>
>




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19132): https://lists.fd.io/g/vpp-dev/message/19132
Mute This Topic: https://lists.fd.io/mt/81921820/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] GTP-U Tunnel Creation only without dst and tteid

[Akash S R]

Hi All,

I am in a condition to alter VPP code for Creating GTP-U Tunnel without dst
address and
tteid(remote) and I will be updating the same later with some values. But,
the main concept
is to Create a Tunnel without it and should be reflected on hw as well
as be shown on VPPCTL.
Please help me on this if any solution is known or working code is
available.

Thanks in Advance!

Thanks and Regards,
Akash

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19131): https://lists.fd.io/g/vpp-dev/message/19131
Mute This Topic: https://lists.fd.io/mt/81922756/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] IPSec - Clear packet's classification for SA lookup in VPP

[Venumadhav Josyula]

Hi Benoit,

Sorry to poke in the middle
   > - VLANs arrive on different sub-interfaces
   > - each sub-interface is in a different VRF
   > - each VRF has its own tunnel with a default route going through it

We would need something of this sort, can you provide example for the same
in vpp ?

Thanks,
Regards,
Venu

On Wed, 7 Apr 2021 at 23:12, Benoit Ganne (bganne) via lists.fd.io  wrote:

> Hi Manoj,
>
> We support 2 main modes:
>  - tunnel protection mode:
> https://wiki.fd.io/view/VPP/IPSec#Protection_Model
>  - policy mode: https://wiki.fd.io/view/VPP/IPSec#Policy_Mode
>
> In tunnel protection mode, the packet classification is done via routing,
> I suspect this is what you need, eg.
>  - VLANs arrive on different sub-interfaces
>  - each sub-interface is in a different VRF
>  - each VRF has its own tunnel with a default route going through it
>
> Of course you can build more complex topologies, eg. having multiple
> tunnels per VRF with different routes, etc.
>
> Best
> ben
>
> > -Original Message-
> > From: vpp-dev@lists.fd.io  On Behalf Of Manoj Kumar
> > (manojku5) via lists.fd.io
> > Sent: mercredi 7 avril 2021 19:19
> > To: vpp-dev@lists.fd.io
> > Cc: Dharmarajan Subramanian (dharsubr) ; Srinivas
> > Davuluri (srinud) ; Prashant Anand (prasanan)
> > 
> > Subject: [vpp-dev] IPSec - Clear packet's classification for SA lookup in
> > VPP
> >
> > Hi Team,
> >
> >
> >
> > We have some basic queries on the IPSEC support in VPP. Could someone
> > please take a look?
> >
> >
> >
> > How does the clear packet classification and SA lookup happens in VPP for
> > the packet? I mean, what all fields of the IP packet are considered for
> > the SA lookup – can it support some L2/VLAN fields as well for this
> > lookup?
> >
> > * Please share some code pointers towards this if possible.
> >
> >
> >
> > I came across esp4_encrypt_handoff() in ipsec_handoff.c file but could
> not
> > find the caller for the same. Which code leg calls this?
> >
> > * This further points to esp4_encrypt_node() and to
> > esp_encrypt_inline().
> > * Inside esp_encrypt_inline(), I can see the code to access the SA
> for
> > the packet. But looks like that is pre-populated in the packet/frame. Is
> > that understanding correct? If yes, can you please point us to the code
> > pointers where this is set – is it in the previous graph node before
> > “esp4_encrypt_handoff”?
> >
> > 636   if (is_tun)
> >
> > 637 {
> >
> > 638   /* we are on a ipsec tunnel's feature arc */
> >
> > 639   vnet_buffer (b[0])->ipsec.sad_index =
> >
> > 640 sa_index0 = ipsec_tun_protect_get_sa_out
> >
> > 641 (vnet_buffer (b[0])->ip.adj_index[VLIB_TX]);
> >
> > 642 }
> >
> > 643   else
> >
> > 644 sa_index0 = vnet_buffer (b[0])->ipsec.sad_index;
> >
> > 645
> >
> >
> >
> > At a high level, we want to be able to support IPSEC for multiple VRFs
> and
> > we would like to use an L2 encapsulation so that we can classify / find
> > the SA for the clear text packet using the IP Header and the L2 fields.
> Is
> > that supported?
> >
> > If yes, what is the control plane programming requirements for that and
> > where is this classification done in the VPP code?
> >
> >
> >
> >
> >
> > Thanks & Regards
> >
> > --Manoj
> >
> >
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19130): https://lists.fd.io/g/vpp-dev/message/19130
Mute This Topic: https://lists.fd.io/mt/81921820/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] IPSec - Clear packet's classification for SA lookup in VPP

[Benoit Ganne (bganne) via lists.fd.io]

Hi Manoj,

We support 2 main modes:
 - tunnel protection mode: https://wiki.fd.io/view/VPP/IPSec#Protection_Model
 - policy mode: https://wiki.fd.io/view/VPP/IPSec#Policy_Mode

In tunnel protection mode, the packet classification is done via routing, I 
suspect this is what you need, eg.
 - VLANs arrive on different sub-interfaces
 - each sub-interface is in a different VRF
 - each VRF has its own tunnel with a default route going through it

Of course you can build more complex topologies, eg. having multiple tunnels 
per VRF with different routes, etc.

Best
ben

> -Original Message-
> From: vpp-dev@lists.fd.io  On Behalf Of Manoj Kumar
> (manojku5) via lists.fd.io
> Sent: mercredi 7 avril 2021 19:19
> To: vpp-dev@lists.fd.io
> Cc: Dharmarajan Subramanian (dharsubr) ; Srinivas
> Davuluri (srinud) ; Prashant Anand (prasanan)
> 
> Subject: [vpp-dev] IPSec - Clear packet's classification for SA lookup in
> VPP
> 
> Hi Team,
> 
> 
> 
> We have some basic queries on the IPSEC support in VPP. Could someone
> please take a look?
> 
> 
> 
> How does the clear packet classification and SA lookup happens in VPP for
> the packet? I mean, what all fields of the IP packet are considered for
> the SA lookup – can it support some L2/VLAN fields as well for this
> lookup?
> 
> * Please share some code pointers towards this if possible.
> 
> 
> 
> I came across esp4_encrypt_handoff() in ipsec_handoff.c file but could not
> find the caller for the same. Which code leg calls this?
> 
> * This further points to esp4_encrypt_node() and to
> esp_encrypt_inline().
> * Inside esp_encrypt_inline(), I can see the code to access the SA for
> the packet. But looks like that is pre-populated in the packet/frame. Is
> that understanding correct? If yes, can you please point us to the code
> pointers where this is set – is it in the previous graph node before
> “esp4_encrypt_handoff”?
> 
> 636   if (is_tun)
> 
> 637 {
> 
> 638   /* we are on a ipsec tunnel's feature arc */
> 
> 639   vnet_buffer (b[0])->ipsec.sad_index =
> 
> 640 sa_index0 = ipsec_tun_protect_get_sa_out
> 
> 641 (vnet_buffer (b[0])->ip.adj_index[VLIB_TX]);
> 
> 642 }
> 
> 643   else
> 
> 644 sa_index0 = vnet_buffer (b[0])->ipsec.sad_index;
> 
> 645
> 
> 
> 
> At a high level, we want to be able to support IPSEC for multiple VRFs and
> we would like to use an L2 encapsulation so that we can classify / find
> the SA for the clear text packet using the IP Header and the L2 fields. Is
> that supported?
> 
> If yes, what is the control plane programming requirements for that and
> where is this classification done in the VPP code?
> 
> 
> 
> 
> 
> Thanks & Regards
> 
> --Manoj
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19129): https://lists.fd.io/g/vpp-dev/message/19129
Mute This Topic: https://lists.fd.io/mt/81921820/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] IPSec - Clear packet's classification for SA lookup in VPP

[Manoj Kumar (manojku5) via lists.fd.io]

Hi Team,

We have some basic queries on the IPSEC support in VPP. Could someone please 
take a look?

How does the clear packet classification and SA lookup happens in VPP for the 
packet? I mean, what all fields of the IP packet are considered for the SA 
lookup – can it support some L2/VLAN fields as well for this lookup?

  *   Please share some code pointers towards this if possible.

I came across esp4_encrypt_handoff() in ipsec_handoff.c file but could not find 
the caller for the same. Which code leg calls this?

  *   This further points to esp4_encrypt_node() and to esp_encrypt_inline().
  *   Inside esp_encrypt_inline(), I can see the code to access the SA for the 
packet. But looks like that is pre-populated in the packet/frame. Is that 
understanding correct? If yes, can you please point us to the code pointers 
where this is set – is it in the previous graph node before 
“esp4_encrypt_handoff”?
636   if (is_tun)
637 {
638   /* we are on a ipsec tunnel's feature arc */
639   vnet_buffer (b[0])->ipsec.sad_index =
640 sa_index0 = ipsec_tun_protect_get_sa_out
641 (vnet_buffer (b[0])->ip.adj_index[VLIB_TX]);
642 }
643   else
644 sa_index0 = vnet_buffer (b[0])->ipsec.sad_index;
645

At a high level, we want to be able to support IPSEC for multiple VRFs and we 
would like to use an L2 encapsulation so that we can classify / find the SA for 
the clear text packet using the IP Header and the L2 fields. Is that supported?
If yes, what is the control plane programming requirements for that and where 
is this classification done in the VPP code?


Thanks & Regards
--Manoj


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19128): https://lists.fd.io/g/vpp-dev/message/19128
Mute This Topic: https://lists.fd.io/mt/81921820/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] Faster PAPI

[Paul Vinciguerra]

>
> Do you mean this line?
>   vpp_transport_shmem.VppTransport.read = read_map_domains_get_mock
>
> I do not like it that much.
> I mean, it works for make test, as it is in the same git repository as
> PAPI code,
> so make test can be accommodated for any big PAPI edit in the same Gerrit
> Change.
> We want to avoid such tight coupling with any code outside VPP repo
> (which includes code inside CSIT repo).


That is actually not tightly coupled.  I just selected that as a sample of
a stream type message so folks could see I tested samples of all the
variants:
"map_domains_get": {
"reply": "map_domains_get_reply",
"stream": true,
"stream_msg": "map_domain_details"
}

We could rename them as NOT_map_domains_get.  It was selected because the
map api uses the new stream/cursor logic.

Yes, the monkey patching is tightly coupled to the transport code. It could
be replaced with a MockTransport but that code isn't present here.


On Wed, Apr 7, 2021 at 11:38 AM Vratko Polak -X (vrpolak - PANTHEON TECH
SRO at Cisco)  wrote:

> Finally, this got back high enough in my TODO list.
>
>
>
> > Have you looked at [0]?
>
> > [0] https://gerrit.fd.io/r/c/vpp/+/30350
>
>
>
> Do you mean this line?
>
>   vpp_transport_shmem.VppTransport.read = read_map_domains_get_mock
>
>
>
> I do not like it that much.
>
> I mean, it works for make test, as it is in the same git repository as
> PAPI code,
>
> so make test can be accommodated for any big PAPI edit in the same Gerrit
> Change.
>
> We want to avoid such tight coupling with any code outside VPP repo
>
> (which includes code inside CSIT repo).
>

>
> As you said:
>
> Poking in the values is an ingenious way to go about solving the problem,
> but it is going to make the systems too tightly coupled and create a
> maintenance headache.
>
>
>
> > Have you seen [0]?
>
> > [0] https://gerrit.fd.io/r/c/vpp/+/30361
>
>
>
> That looks better.
>
> You can have MakeTestMockTransport defined somewhere in tests/,
>
> and use that when appropriate.
>
> It may take a while to make vpp_papi APIs clean,
>
> as different transports have different requirements and capabilities,
>
> but definitely a step in the right direction.
>
>
>
> For a socket transport variant suitable for high performance,
>
> I imagine something like [3].
>
> Marked as WiP, as it is poorly documented and not tested at all yet.
>
> Based on master, as 30361 is not merged yet (and needs a rebase).
>
>
>
> With 30361, the new transport code from 31920 could be in CSIT,
>
> but I imagine other users may want to use it too
>
> (not probable for MakeTestMockTransport).
>
>
>
> What do you think?
>
>
>
> > Can I suggest that if you want to use the binary api (vapi) instead of
> papi, that you look at swig.  [1]
>
> > [1] http://www.swig.org/
>
>
>
> Not sure vapi+swig gives big enough performance benefit.
>
> In CSIT we want to keep all Python stuff in one machine (with Robot tests),
>
> and using socket (forwarded via SSH) to talk to a plain VPP machine.
>
>
>
> If we consider putting custom code onto the VPP machine,
>
> the range of possibilities increase considerably
>
> (extreme example: CSIT could start building its own VPP plugin
>
> to do direct C calls, similarly to what CLI and VAT code in VPP does).
>
>
>
> Vratko.
>
>
>
> [3] https://gerrit.fd.io/r/c/vpp/+/31920
>
>
>
> *From:* Paul Vinciguerra 
> *Sent:* Thursday, 2021-February-04 05:09
> *To:* Paul Vinciguerra 
> *Cc:* Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) <
> vrpo...@cisco.com>; Ole Troan (otroan) ; Peter Mikus -X
> (pmikus - PANTHEON TECH SRO at Cisco) ;
> csit-...@lists.fd.io; vpp-dev@lists.fd.io
> *Subject:* Re: [vpp-dev] Faster PAPI
>
>
>
> Following up on Peter's comments in the changeset,
>
>
>
> Have you seen [0]?  It separates out the transports, so that you can
> implement/subclass your own without poking in values from your executor.
> Poking in the values is an ingenious way to go about solving the problem,
> but it is going to make the systems too tightly coupled and create a
> maintenance headache.  Even if we write unit tests against papi, we cannot
> anticipate how you might redefine the logic.  It looks relatively
> straightforward to move your methods into a new or subclassed transport.
>
>
>
> Can I suggest that if you want to use the binary api (vapi) instead of
> papi, that you look at swig.  [1]
>
>
>
> [0] https://gerrit.fd.io/r/c/vpp/+/30361
>
> [1] http://www.swig.org/
>
>
>
> On Wed, Feb 3, 2021 at 11:08 AM Paul Vinciguerra via lists.fd.io  vinciconsulting@lists.fd.io> wrote:
>
> Hi Vratko.
>
>
>
> Have you looked at [0]?
>
>
>
> [0] https://gerrit.fd.io/r/c/vpp/+/30350
>
>
>
> On Wed, Feb 3, 2021 at 9:44 AM Vratko Polak -X (vrpolak - PANTHEON TECH
> SRO at Cisco)  wrote:
>
> > Hello people interested in PAPI (VPP's Python API client library).
>
>
>
> Hello again.
>
> This is an update e-mail, adding some information,
>
> while still asking basically the same questi

Re: [vpp-dev] Faster PAPI

[Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco) via lists.fd.io]

Finally, this got back high enough in my TODO list.

> Have you looked at [0]?
> [0] https://gerrit.fd.io/r/c/vpp/+/30350

Do you mean this line?
  vpp_transport_shmem.VppTransport.read = read_map_domains_get_mock

I do not like it that much.
I mean, it works for make test, as it is in the same git repository as PAPI 
code,
so make test can be accommodated for any big PAPI edit in the same Gerrit 
Change.
We want to avoid such tight coupling with any code outside VPP repo
(which includes code inside CSIT repo).

As you said:
Poking in the values is an ingenious way to go about solving the problem, but 
it is going to make the systems too tightly coupled and create a maintenance 
headache.

> Have you seen [0]?
> [0] https://gerrit.fd.io/r/c/vpp/+/30361

That looks better.
You can have MakeTestMockTransport defined somewhere in tests/,
and use that when appropriate.
It may take a while to make vpp_papi APIs clean,
as different transports have different requirements and capabilities,
but definitely a step in the right direction.

For a socket transport variant suitable for high performance,
I imagine something like [3].
Marked as WiP, as it is poorly documented and not tested at all yet.
Based on master, as 30361 is not merged yet (and needs a rebase).

With 30361, the new transport code from 31920 could be in CSIT,
but I imagine other users may want to use it too
(not probable for MakeTestMockTransport).

What do you think?

> Can I suggest that if you want to use the binary api (vapi) instead of papi, 
> that you look at swig.  [1]
> [1] http://www.swig.org/

Not sure vapi+swig gives big enough performance benefit.
In CSIT we want to keep all Python stuff in one machine (with Robot tests),
and using socket (forwarded via SSH) to talk to a plain VPP machine.

If we consider putting custom code onto the VPP machine,
the range of possibilities increase considerably
(extreme example: CSIT could start building its own VPP plugin
to do direct C calls, similarly to what CLI and VAT code in VPP does).

Vratko.

[3] https://gerrit.fd.io/r/c/vpp/+/31920

From: Paul Vinciguerra 
Sent: Thursday, 2021-February-04 05:09
To: Paul Vinciguerra 
Cc: Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) ; 
Ole Troan (otroan) ; Peter Mikus -X (pmikus - PANTHEON TECH 
SRO at Cisco) ; csit-...@lists.fd.io; vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Faster PAPI

Following up on Peter's comments in the changeset,

Have you seen [0]?  It separates out the transports, so that you can 
implement/subclass your own without poking in values from your executor.  
Poking in the values is an ingenious way to go about solving the problem, but 
it is going to make the systems too tightly coupled and create a maintenance 
headache.  Even if we write unit tests against papi, we cannot anticipate how 
you might redefine the logic.  It looks relatively straightforward to move your 
methods into a new or subclassed transport.

Can I suggest that if you want to use the binary api (vapi) instead of papi, 
that you look at swig.  [1]

[0] https://gerrit.fd.io/r/c/vpp/+/30361
[1] http://www.swig.org/

On Wed, Feb 3, 2021 at 11:08 AM Paul Vinciguerra via 
lists.fd.io 
mailto:vinciconsulting@lists.fd.io>>
 wrote:
Hi Vratko.

Have you looked at [0]?

[0] https://gerrit.fd.io/r/c/vpp/+/30350

On Wed, Feb 3, 2021 at 9:44 AM Vratko Polak -X (vrpolak - PANTHEON TECH SRO at 
Cisco) mailto:vrpo...@cisco.com>> wrote:
[cid:image001.gif@01D72BCD.5A99FC10]
> Hello people interested in PAPI (VPP's Python API client library).

Hello again.
This is an update e-mail, adding some information,
while still asking basically the same questions.

Since my first e-mail, there was some private communication,
mostly related to reasons the vanilla performance is not good,
and how improvements to VAT [2] can help.

> The exact code change is [0], but that may be hard to review.

The current patch set [3] is a little better.

> For that I have created [1], which shows the changed VPP PAPI code.

Still mostly unfinished, I need to familiarize better with shmem transport.

The main inputs came from Peter, who expressed
dislike [4] on how brittle the fast binary message generation is,
and he prefers "we will call a vector operation and PAPI just executes it".

Let me summarize the current options as I see them.

1. Keep the status quo.
That means using VAT for some operations (e.g. adding multiple routes [5]),
and creating "exec scripts" [6] for operations without VAT one-liner.
Pros: No work needed, good speed, old VPP versions are supported.
Cons: Relying on VAT functionality (outside API compatibility rules).

2. Support "vector operations" in VPP via binary API.
This will probably need a new VPP plugin to host the implementations.
Pros: Fast speed, small CSIT work, guarded by API compatibility rules.
Cons: New VPP plugin of questionable usefulness outside CSIT,
plugin maintainer needed, old VPP versions not supported.

3. VPP PAPI improvements only.
No

Re: [vpp-dev] Can tcp4 packet bypass ip4-lookup node ?

[Florin Coras]

Hi Yacan, 

At this point, only ipv6 link local packets end up in ip-rewrite. Because of 
the v4/v6 symmetry we have arcs for both address families. 

With respect to the two questions. First, tcp doesn’t cache the dpo for the 
remote ip because that would require tracking the dpo (in case it changes) and 
some of the apis involved are not thread safe. You can find some remnants of 
those attempts in tcp.c (eg tcp_connection_stack_on_fib_entry) although they’re 
compiled out and probably bit rotten at this point. 

Nonetheless, as you already found out, tcp-output can redirect packets to a 
custom node and provide some opaque context (next_node_opaque) but currently 
there are no apis for setting these two values. That is, the two are currently 
meant for vpp builtin applications that have access to the tcp connection. Does 
that fit your usecase? Otherwise, I am planning to add some apis that would 
allow vcl to change transport parameters soon.

Regards,
Florin

> On Apr 7, 2021, at 1:56 AM, liuyacan  wrote:
> 
> 
> Hi VPP experts,
> 
>  The command "show node tcp4-output" tell me that  ip4-lookup and 
> ip4-rewrite 
>  are both possible  nodes for  Tx  packets. But I never saw the count of 
> ip4-rewrite 
>  greater than zero 
>  The function tcp_output_handle_packet()  checks  tc0's next_node_index 
> to 
>  determine which node is appropriate, But I can not find any place that 
> modify 
>   the filed.. 
>
>   My question is can tcp_connection_t store the FIB lookup result so that 
> subsequent 
>   packets are able to bypass  ip4-lookup node ?
> 
> Best Regards,
> Yacan
> 
>   
>
> 
> 
> 
> 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19125): https://lists.fd.io/g/vpp-dev/message/19125
Mute This Topic: https://lists.fd.io/mt/81911146/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] VPP: A Terabit Secure Network Data-plane

[Maciek Konstantynowicz (mkonstan) via lists.fd.io]

https://www.youtube.com/watch?v=ipQQmjzE_g0

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19124): https://lists.fd.io/g/vpp-dev/message/19124
Mute This Topic: https://lists.fd.io/mt/81916291/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] About cnat FIB

[liuyacan]

Hi Nathan,       Currently our App is VRF-based, maybe we can also put them      in the default VRF.      Thank you for all your assistance!Best Regards,Yacan
 

On 4/7/2021 20:02，Nathan Skrzypczak wrote： 


Hi Yacan,That's interesting, we're actually using it for a kube-proxy replacement too [0],but with CNAT rules being handled in the main VRF. I'd be curious of thenetworking model you're targeting.On the cnat evolution, if it's only adding the ability to create FIB-based VIPsessions in a specific FIB, that would be fairly easy. But if you aim at supporting all kube-proxy use-cases, you might require some additional evolutions.Kind regards,-Nathan[0] https://github.com/projectcalico/vpp-dataplaneLe mer. 7 avr. 2021 à 04:40, liuyacan  a écrit :







Hi  Nathan,   We hope to use CNAT to play the role of kube-proxy.     Since our applications specifies namespaces,  so we want CNAT rules    to take effect in different FIB tables.Best Regards,Yacan

 

 

On 4/6/2021 20:59，Nathan Skrzypczak wrote： 


Hi Yacan,There is no particular reason, just that the code for CNAT is quite new, andwe never implemented vrf support. I don't see any blocker to add it if you need it.What is the use-case you would like to support ? By specifying a table ID, do youmean for matching traffic ? Also for the rewrite ? Maybe DNATing to a differenttable ?Best regards,-NathanLe mar. 6 avr. 2021 à 11:23, liuyacan  a écrit :








Hi,         We observed that CNAT translation rule now can only be set in the default table for v4 and v6.     Why is there such a restriction ? Best Regards,Yacan




 

















-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19123): https://lists.fd.io/g/vpp-dev/message/19123
Mute This Topic: https://lists.fd.io/mt/81885640/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] About cnat FIB

[Nathan Skrzypczak]

Hi Yacan,

That's interesting, we're actually using it for a kube-proxy replacement
too [0],
but with CNAT rules being handled in the main VRF. I'd be curious of the
networking model you're targeting.

On the cnat evolution, if it's only adding the ability to create FIB-based
VIP
sessions in a specific FIB, that would be fairly easy. But if you aim at
supporting all kube-proxy use-cases, you might require some additional
evolutions.

Kind regards,
-Nathan

[0] https://github.com/projectcalico/vpp-dataplane

Le mer. 7 avr. 2021 à 04:40, liuyacan  a écrit :

> Hi  Nathan,
>
>We hope to use CNAT to play the role of kube-proxy.
>Since our applications specifies namespaces,  so we want CNAT rules
>to take effect in different FIB tables.
>
> Best Regards,
> Yacan
>
> On 4/6/2021 20:59，Nathan Skrzypczak
>  wrote：
>
> Hi Yacan,
>
> There is no particular reason, just that the code for CNAT is quite new,
> and
> we never implemented vrf support. I don't see any blocker to add it if you
> need it.
>
> What is the use-case you would like to support ? By specifying a table ID,
> do you
> mean for matching traffic ? Also for the rewrite ? Maybe DNATing to a
> different
> table ?
>
> Best regards,
> -Nathan
>
>
>
> Le mar. 6 avr. 2021 à 11:23, liuyacan  a
> écrit :
>
>> Hi,
>>
>> We observed that CNAT translation rule now can only be set in the
>> default table for v4 and v6.
>> Why is there such a restriction ?
>>
>> Best Regards,
>> Yacan
>>
>>
>>
>> 
>>
>>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19122): https://lists.fd.io/g/vpp-dev/message/19122
Mute This Topic: https://lists.fd.io/mt/81885640/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] how to build VPP v21.06-rc0 with mellanox DPDK PMD

[Július Milan]

Hi folks

I am trying to build recent VPP v21.06-rc0 with DPDK enabled MLX5 PMD.
I found it was possible for VPP v18.07 as described here:
https://fd.io/docs/vpp/v2101/usecases/vppinazure.html
But in meantime both DPDK and VPP changed a bit.
What are the actual commands?

Thanks
Julius

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19121): https://lists.fd.io/g/vpp-dev/message/19121
Mute This Topic: https://lists.fd.io/mt/81911579/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] Can tcp4 packet bypass ip4-lookup node ?

[liuyacan]

Hi VPP experts,     The command "show node tcp4-output" tell me that  ip4-lookup and ip4-rewrite      are both possible  nodes for  Tx  packets. But I never saw the count of ip4-rewrite      greater than zero      The function tcp_output_handle_packet()  checks  tc0's next_node_index to      determine which node is appropriate, But I can not find any place that modify       the filed..            My question is can tcp_connection_t store the FIB lookup result so that subsequent       packets are able to bypass  ip4-lookup node ?      Best Regards,Yacan         
 




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19120): https://lists.fd.io/g/vpp-dev/message/19120
Mute This Topic: https://lists.fd.io/mt/81911146/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-