Re: [vpp-dev] Alphabetic PCI Major address

[Damjan Marion via Lists.Fd.Io]

slightly related: not sure if people notified, but recently I added option to 
specify interface name from the startup.conf.

i.e. 
dpdk {
  dev :12:00.0 { name eth0 }
  dev :12:00.1 { name eth1 }
}

An then config looks like:

set int ip address eth0 172.16.0.1/24
set int ip address eth1 172.16.1.1/24

much easier to type and reuse configs on different nics

-- 
Damjan

> On 14 Dec 2018, at 21:26, sheckman  wrote:
> 
> Yes...I just figured that out:-[
> 
> Thanks,
> Steve
> 
> On 12/14/2018 03:18 PM, Dave Barach (dbarach) wrote:
>> Yes, it can. The interface is called “HundredGigabitEthernetaf/­4/2” not 
>> “HundredGigabitEthernetaf/04/2”
>>  
>> The interface name is (u8 *) vector which is exact-matched, not parsed in 
>> any way which would make 04 equivalent to 4.
>>  
>> D.
>>  
>> From: vpp-dev@lists.fd.io   
>>  On Behalf Of sheckman
>> Sent: Friday, December 14, 2018 2:52 PM
>> To: vpp-dev@lists.fd.io 
>> Subject: [vpp-dev] Alphabetic PCI Major address
>>  
>> Can VPP (or VPP CLI) handle PCI addresses that start with "A-F"?
>>  
>> # lshw -c network -businfo | grep af
>> pci@:af:00.0   enp175s0f0  network
>> MT28800 Family [ConnectX-5]
>> pci@:af:00.1   enp175s0f1  network
>> MT28800 Family [ConnectX-5]
>> pci@:af:00.2   enp175s0f2  network
>> MT28800 Family [ConnectX-5 
>> Virtual Function]
>> pci@:af:04.2   enp175s4f2  network
>> MT28800 Family [ConnectX-5 
>> Virtual Function]
>>  
>> vpp# set interface mtu: unknown input `2000 HundredGigabitEthernetaf/...'
>> show interface
>>Name   IdxState  MTU 
>> (L3/IP4/IP6/MPLS) Counter  Count
>> HundredGigabitEthernet18/4/2  2 down 2000/0/0/0
>> HundredGigabitEthernetaf/4/2  3 down 9000/0/0/0
>> local00 down 0/0/0/0
>> tuntap-0  1  up 0/0/0/0   rx 
>> packets 2
>> rx bytes  96
>> drops  2
>> ip62
>> vpp# set interface mtu 2000 HundredGigabitEthernetaf/04/2
>> set interface mtu: unknown input `2000 HundredGigabitEthernetaf/...'
>>  
>> Thanks,
>>  
>> Steve Heckman
>>  
>> Arris
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> 
> View/Reply Online (#11620): https://lists.fd.io/g/vpp-dev/message/11620 
> 
> Mute This Topic: https://lists.fd.io/mt/28755737/675642 
> 
> Group Owner: vpp-dev+ow...@lists.fd.io 
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub 
>   [dmar...@me.com 
> ]
> -=-=-=-=-=-=-=-=-=-=-=-

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

View/Reply Online (#11625): https://lists.fd.io/g/vpp-dev/message/11625
Mute This Topic: https://lists.fd.io/mt/28755737/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] Alphabetic PCI Major address

[Stephen Hemminger]

On Sun, 16 Dec 2018 11:40:42 +0100
"Damjan Marion via Lists.Fd.Io"  wrote:

> slightly related: not sure if people notified, but recently I added option to 
> specify interface name from the startup.conf.
> 
> i.e. 
> dpdk {
>   dev :12:00.0 { name eth0 }
>   dev :12:00.1 { name eth1 }
> }
> 
> An then config looks like:
> 
> set int ip address eth0 172.16.0.1/24
> set int ip address eth1 172.16.1.1/24
> 
> much easier to type and reuse configs on different nics
> 

Cool.
How does that work when DPDK unbinds the network device.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11626): https://lists.fd.io/g/vpp-dev/message/11626
Mute This Topic: https://lists.fd.io/mt/28755737/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] Alphabetic PCI Major address

[Damjan Marion via Lists.Fd.Io]

> On 16 Dec 2018, at 21:46, Stephen Hemminger  
> wrote:
> 
> 
> On Sun, 16 Dec 2018 11:40:42 +0100
> "Damjan Marion via Lists.Fd.Io"  > wrote:
> 
>> slightly related: not sure if people notified, but recently I added option 
>> to specify interface name from the startup.conf.
>> 
>> i.e. 
>> dpdk {
>>  dev :12:00.0 { name eth0 }
>>  dev :12:00.1 { name eth1 }
>> }
>> 
>> An then config looks like:
>> 
>> set int ip address eth0 172.16.0.1/24
>> set int ip address eth1 172.16.1.1/24
>> 
>> much easier to type and reuse configs on different nics
>> 
> 
> Cool.
> How does that work when DPDK unbinds the network device.

This doesn't have anything with linux interface names. 
It is just arbitrary string, it can be foo0 and foo1 instead...


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

View/Reply Online (#11627): https://lists.fd.io/g/vpp-dev/message/11627
Mute This Topic: https://lists.fd.io/mt/28755737/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] Alphabetic PCI Major address

[sheckman]

Awesome! I wish that was there from day 1. Now I'm not so embarrased I 
asked...;)

What release did it make it into?

Steve



Sent from BlueMail
On Dec 16, 2018, at 3:55 PM, Damjan Marion 
mailto:dmar...@me.com>> wrote:


On 16 Dec 2018, at 21:46, Stephen Hemminger < 
step...@networkplumber.org> wrote:


On Sun, 16 Dec 2018 11:40:42 +0100
"Damjan Marion via Lists.Fd.Io" < 
dmarion=me@lists.fd.io > wrote:

slightly related: not sure if people notified, but recently I added option to 
specify interface name from the startup.conf.

i.e.
dpdk {
 dev :12:00.0 { name eth0 }
 dev :12:00.1 { name eth1 }
}

An then config looks like:

set int ip address eth0 172.16.0.1/24
set int ip address eth1 172.16.1.1/24

much easier to type and reuse configs on different nics


Cool.
How does that work when DPDK unbinds the network device.

This doesn't have anything with linux interface names.
It is just arbitrary string, it can be foo0 and foo1 instead...


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

View/Reply Online (#11628): https://lists.fd.io/g/vpp-dev/message/11628
Mute This Topic: https://lists.fd.io/mt/28755737/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 vpn

[xulang]

Hi all,
How can we use IPSEC VPN to protect multi subnetworks.
Such as  10.11.0.0/16  and 192.168.0.0/16.
Do they negotiate this information through IKEV2 AUTH procedure? 
And the code show that there is only one TS per profile, how can that protect 
multi subnet.




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

View/Reply Online (#11629): https://lists.fd.io/g/vpp-dev/message/11629
Mute This Topic: https://lists.fd.io/mt/28779640/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] Feature arc and ordering graph nodes in an existing feature arc.

[raju]

Thanks Neale for the reply.

<< have you defined my_next_node as an arc out of my_node, e.g.; >>



Yes, I have defined this. But as I said, in cases when I don't have
.runs_before vnet_feature_next (...) in my_node is ip4-lookup and when I
have this .runs_before the function vnet_feature_next (...) gives
my_next_node. Only difference is .runs_before.


Also, want to understand how to use this ip4_reassembly_feature in some
other cases like IP-in-IP cases to reassemble inner IP fragments.


Thanks







On Fri, Dec 14, 2018 at 7:38 PM Neale Ranns (nranns) 
wrote:

>
>
>
>
> *De : * au nom de raju 
> *Date : *vendredi 14 décembre 2018 à 14:58
> *À : *vpp-dev 
> *Objet : *[vpp-dev] Feature arc and ordering graph nodes in an existing
> feature arc.
>
>
>
> Hi
>
> I am trying to add a feature (say 'my_node') to ip4_unicast arc.
>
> Goal is just like ip4_gtpu_bypass to by pass the IP stack and process
> packets that are of my interest and if packets received are of not my
> interest give it back to the ip layer.
>
> At the same time I am trying to use ip4 reassembly on the interface using
> CLI. (vppctl set interface reassembly GigabitEthernet13/0/0 on).
>
>
>
> So expected graph
>
>
> For packets of my interest :
>
> dpdk-input --> ip4-input --> ip4-reassembly-feature --> my_node
> -->my_next_node  
>
> Packets that are of not my interest :
>
> dpdk-input --> ip4-input --> ip4-reassembly-feature --> my_node -->
> ip4_lookup --> 
>
>
>
> Q1. How are the feature nodes ordered in an arc ?
>
> I tried to order these two feature my-node and
> ip4-reassembly-feature using .runs_after like below and was able to
> get ip4-reassembly-feature before my-node. And with out using .runs_after,
> the order was other way. (my-node --> ip4-reassembly-feature).
>
>
>
> VNET_FEATURE_INIT (my_node, static) = {
>
>   .arc_name = "ip4-unicast",
>
>   .node_name = "my_node",
>
> [nr]
>
>   .runs_before = VNET_FEATURES ("ip4-lookup"),<< this you don’t
> need, since ip4-lookup is always last
>
>   .runs_after = VNET_FEATURES ("ip4-reassembly-feature"),
>
> };
>
>
>
> Is this correct way of doing?
>
>
>
> [nr] yes
>
>
>
> Does the order of feature nodes in an arc depend on the order of enabling
> these using the function 'vnet_feature_enable_disable' ?
>
>
>
> [nr] no. only runs_before and runs_after are used to determine ordering.
>
>
>
> Q2.
>
> With the above code, I could get my intent working with normal packets of
> my interest.
>
> But for packets that are of not my interest I am not able to route them
> back to ip4-lookup, instead packets come to my-next-node that succeeds
> my-node.  I use the function 'vnet_feature_next' to get the next feature in
> the arc by default .
>
> that meaning to say
>
> For packets of my interest next = my_next_node
>
> and for packets that are not of my interest next is taken
> from vnet_feature_next(vnet_buffer(b0)->sw_if_index[VLIB_RX], &next, b0);
>
>
>
> have you defined my_next_node as an arc out of my_node, e.g.;
>
>
>
> VLIB_REGISTER_NODE (my_node) = {
>
>   .name = "my-node",
>
>   .vector_size = sizeof (u32),
>
>
>
>   .format_trace = format_ip4_rewrite_trace,
>
>
>
>   .n_next_nodes = 1,
>
>   .next_nodes = {
>
> [0] = "my-next-node",
>
>   },
>
> };
>
>
>
>
>
> /Neale
>
>
>
>
>
> Sorry for the long writings.
>
> Please advice.
>
>
>
> Thanks
>
>
>
>
>
>
>
>
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11630): https://lists.fd.io/g/vpp-dev/message/11630
Mute This Topic: https://lists.fd.io/mt/28752628/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] Alphabetic PCI Major address

[Jim Thompson]

> On Dec 16, 2018, at 3:52 PM, sheckman  wrote:
> 
> Awesome! I wish that was there from day 1. Now I'm not so embarrased I 
> asked...;)
> 
> What release did it make it into?

It’s only three weeks old, so it will be in 19.01.
https://gerrit.fd.io/r/#/c/16219/ 

Jim


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

View/Reply Online (#11631): https://lists.fd.io/g/vpp-dev/message/11631
Mute This Topic: https://lists.fd.io/mt/28755737/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] Build fails on CentOS with VMBus.

[Damjan Marion via Lists.Fd.Io]

-- 
Damjan

> On 11 Dec 2018, at 18:13, Stephen Hemminger  
> wrote:
> 
> On Mon, 10 Dec 2018 09:32:26 -0800
> Damjan Marion  wrote:
> 
>> Stephen,
>> 
>> Can you make this dependency optional? CMake detect presence of libuuid and 
>> then
>> conditionally compile vmbus code?
>> 
>> In some cases that library might not be present, specially in some embedded 
>> cases...
>> 
>> That will also allow us to merge that code immediately and later we can fix 
>> different distros.
>> 
> 
> I would rather not make anything optional. We already have enough options
> (like Mellanox) and every distribution even embedded has libuuid because
> libuuid is part of ext2 utilities. The other way would be to expose the clone
> of UUID which is in DPDK already.
> 
> Part of the problem is that CMake options are static not dynamically detected.

Please explain... We already dynamically detect presence of different libraries 
in CMake...


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

View/Reply Online (#11632): https://lists.fd.io/g/vpp-dev/message/11632
Mute This Topic: https://lists.fd.io/mt/28668850/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-