[vpp-dev] How to suspend forwarding on a sw interface? #vnet
Hi VPP Experts, I'm looking for some advice in order to properly implement a CFM (802.1ag) CCM plugin. CCM (Continuity Check Messages) are basic Ethernet keepalive messages -- missing several messages in a row should cause the Ethernet interface or sub-interface [the CFM frames might be VLAN tagged] to be suspended from a forwarding perspective. Injecting the keepalives using a process node, and catching the incoming keepalives with a ethernet_register_input_type- hooked (based on EtherType) node look easy, but *how to properly suspend forwarding in both directions on the sw (sub) interface* when keepalives are missing (while still being able to receive further keepalives of course)? If possible as a pure plugin but I doubt it's possible. Thoughts so far: Inbound direction: * Option 1. Hook a new node before ethernet-input to catch the CFM frames, identify the sub-interface (if tagged frame), drop other frames... but that means re-running all what's already done in ethernet-input (finding the matching sub-interface, etc.). * Option 2. Hook a new node at the beginning of each next arc (IP4, IP6, MPLS, L2...) to drop all packets there. Enable ( vnet_feature_enable_disable ) this node only when CCM reports the link failure. * Option 3. Implement a new vnet_sw_interface_flags_t flag into vnet code to indicate that the interface is suspended, and add checks to ethernet-input with a bypass option for some specific EtherTypes (CFM first). * Note: VNET_SW_INTERFACE_FLAG_PUNT 's description sounds attractive... but I cannot see where and how it's actually used. * Option 4. ? Outbound direction: * Option 1. Implement a new vnet_sw_interface_flags_t flag into vnet code, its corresponding callback, and check this flag along VNET_SW_INTERFACE_FLAG_ADMIN_UP in many locations. * Option 2. Implement VNET_SW_INTERFACE_FLAG_OPER_UP new flag, controlled by FLAG_ADMIN_UP and by CFM, and use it rather than FLAG_ADMIN_UP in callbacks. * Option 3. ? Any advice will be welcome. Thanks, Sylvain -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15713): https://lists.fd.io/g/vpp-dev/message/15713 Mute This Topic: https://lists.fd.io/mt/71854861/21656 Mute #vnet: https://lists.fd.io/mk?hashtag=vnet&subid=1480452 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] Reporting stale tunnel via LINK DOWN event — ok or not?
Hi,
at EMnify we are working to extend GTPU support with features required
in mobile networks. According to GTPU specification, if a received packet
doesn't match an existing tunnel (unknown DIP+TEID), error indication is
sent back. When an error indication is received, we have to tell the control
plane so that it can take action.
Using existing interface state change notifications looks promising.
Is it appropriate to report a stale tunnel via LINK DOWN event, or should we
rather implement a brand-new notification?
Concerning interface state change notifications, I am somewhat puzzled how
to use it properly. Event structure is defined as follows:
define sw_interface_event
{
u32 client_index;
u32 pid;
vl_api_interface_index_t sw_if_index;
vl_api_if_status_flags_t flags;
bool deleted;
};
enum if_status_flags
{
IF_STATUS_API_FLAG_ADMIN_UP = 1,
IF_STATUS_API_FLAG_LINK_UP = 2,
};
I would expect flags to reflect the current interface state, however it is not
the case.
Toggling admin up state will deliver events with flags set to ADMIN_UP or 0.
Toggling link up state will deliver events with flags set to LINK_UP or 0.
It is not possible to tell on the client side whether the link went down (flags
= 0), or
if the interface was brought down administratively (flags = 0).
Any pointers?
Best,
N
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#15714): https://lists.fd.io/g/vpp-dev/message/15714
Mute This Topic: https://lists.fd.io/mt/71855353/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] How to suspend forwarding on a sw interface? #vnet
> On 10 Mar 2020, at 12:42, Sylvain CADILHAC > wrote: > > Hi VPP Experts, > > I'm looking for some advice in order to properly implement a CFM (802.1ag) > CCM plugin. > CCM (Continuity Check Messages) are basic Ethernet keepalive messages -- > missing several messages in a row should cause the Ethernet interface or > sub-interface [the CFM frames might be VLAN tagged] to be suspended from a > forwarding perspective. > Injecting the keepalives using a process node, and catching the incoming > keepalives with a ethernet_register_input_type-hooked (based on EtherType) > node look easy, but how to properly suspend forwarding in both directions on > the sw (sub) interface when keepalives are missing (while still being able to > receive further keepalives of course)? If possible as a pure plugin but I > doubt it's possible. > > Thoughts so far: > > Inbound direction: > • Option 1. Hook a new node before ethernet-input to catch the CFM > frames, identify the sub-interface (if tagged frame), drop other frames... > but that means re-running all what's already done in ethernet-input (finding > the matching sub-interface, etc.). > • Option 2. Hook a new node at the beginning of each next arc (IP4, > IP6, MPLS, L2...) to drop all packets there. Enable > (vnet_feature_enable_disable) this node only when CCM reports the link > failure. > • Option 3. Implement a new vnet_sw_interface_flags_t flag into vnet > code to indicate that the interface is suspended, and add checks to > ethernet-input with a bypass option for some specific EtherTypes (CFM first). > • Note: VNET_SW_INTERFACE_FLAG_PUNT's description sounds > attractive... but I cannot see where and how it's actually used. > • Option 4. ? Some variant of 3 makes most sense here. Adding “inactive” oper state makes sense to me here…. Instead of modifying existing ethernet-input node, you can simply send all packets to error-drop except CFM frames which can go straight to your plugin. I’m fine with adding minimal hooks to make this feature working into the ethernet code in vnet, and rest goes to plugin. > > Outbound direction: > • Option 1. Implement a new vnet_sw_interface_flags_t flag into vnet > code, its corresponding callback, and check this flag along > VNET_SW_INTERFACE_FLAG_ADMIN_UP in many locations. > • Option 2. Implement VNET_SW_INTERFACE_FLAG_OPER_UP new flag, > controlled by FLAG_ADMIN_UP and by CFM, and use it rather than FLAG_ADMIN_UP > in callbacks. > • Option 3. ? inactive state + minor modification of interface-tx code. Here, we can use vector scalar data to pass flag with frame which says “I insist on transmitting this packets even if interface is inactive”. CFM process node simply sets that flag when it ships CFM frames to interface-tx node…. — Damjan-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15715): https://lists.fd.io/g/vpp-dev/message/15715 Mute This Topic: https://lists.fd.io/mt/71854861/21656 Mute #vnet: https://lists.fd.io/mk?hashtag=vnet&subid=1480452 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] Coverity run FAILED as of 2020-03-10 14:00:26 UTC
Coverity run failed today. Current number of outstanding issues are 3 Newly detected: 0 Eliminated: 0 More details can be found at https://scan.coverity.com/projects/fd-io-vpp/view_defects -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15716): https://lists.fd.io/g/vpp-dev/message/15716 Mute This Topic: https://lists.fd.io/mt/71857085/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] How to suspend forwarding on a sw interface? #vnet
Add a node to the device-input feature arc to handle RX processing, including throwing away non-CCM packets received on timed-out (sub)interfaces, and looking for CCM packets. If you clear the admin-up flag on a subinterface / link-up flag on a physical interface, that should quench output without quenching driver-level input. Although a code tour suggests that I’m right about the link-up flag, Damjan (or others) feel free to jump in. I don’t think you’ll need a scanner process. To begin with, I wouldn’t bother trying to avoid doing vlan tag parsing twice. For max performance, poach the relevant bits from ethernet-input and combine with CCM processing. Your feature arc node subsumes ethernet input, and skips it, but only for CCM-enabled interfaces. Should work from a plugin. FWIW... Dave From: vpp-dev@lists.fd.io On Behalf Of Sylvain CADILHAC Sent: Tuesday, March 10, 2020 7:43 AM To: vpp-dev@lists.fd.io Subject: [vpp-dev] How to suspend forwarding on a sw interface? #vnet Hi VPP Experts, I'm looking for some advice in order to properly implement a CFM (802.1ag) CCM plugin. CCM (Continuity Check Messages) are basic Ethernet keepalive messages -- missing several messages in a row should cause the Ethernet interface or sub-interface [the CFM frames might be VLAN tagged] to be suspended from a forwarding perspective. Injecting the keepalives using a process node, and catching the incoming keepalives with a ethernet_register_input_type-hooked (based on EtherType) node look easy, but how to properly suspend forwarding in both directions on the sw (sub) interface when keepalives are missing (while still being able to receive further keepalives of course)? If possible as a pure plugin but I doubt it's possible. Thoughts so far: Inbound direction: * Option 1. Hook a new node before ethernet-input to catch the CFM frames, identify the sub-interface (if tagged frame), drop other frames... but that means re-running all what's already done in ethernet-input (finding the matching sub-interface, etc.). * Option 2. Hook a new node at the beginning of each next arc (IP4, IP6, MPLS, L2...) to drop all packets there. Enable (vnet_feature_enable_disable) this node only when CCM reports the link failure. * Option 3. Implement a new vnet_sw_interface_flags_t flag into vnet code to indicate that the interface is suspended, and add checks to ethernet-input with a bypass option for some specific EtherTypes (CFM first). * Note: VNET_SW_INTERFACE_FLAG_PUNT's description sounds attractive... but I cannot see where and how it's actually used. * Option 4. ? Outbound direction: * Option 1. Implement a new vnet_sw_interface_flags_t flag into vnet code, its corresponding callback, and check this flag along VNET_SW_INTERFACE_FLAG_ADMIN_UP in many locations. * Option 2. Implement VNET_SW_INTERFACE_FLAG_OPER_UP new flag, controlled by FLAG_ADMIN_UP and by CFM, and use it rather than FLAG_ADMIN_UP in callbacks. * Option 3. ? Any advice will be welcome. Thanks, Sylvain -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15717): https://lists.fd.io/g/vpp-dev/message/15717 Mute This Topic: https://lists.fd.io/mt/71854861/21656 Mute #vnet: https://lists.fd.io/mk?hashtag=vnet&subid=1480452 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] Small issue regarding fheap.c in vppinfra
Hi experts, While reading vppinfra/fheap.c, I have a question in fheap_mark_parent that p->parent was set to ~0 after node_remove and add_sibling, so it's not possible to do a cascaded cut. Should we store parent's index before those actions? Thanks a lot! -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15718): https://lists.fd.io/g/vpp-dev/message/15718 Mute This Topic: https://lists.fd.io/mt/71858970/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] Need advice on sw_interface_set_rx_placement() API #vpp
Hi there,
There is a VPP APIs function sw_interface_set_rx_placement(). This function
allows us to set specific worker for the specified queue.
And this function takes worker_id as an argument. worker_id is then translated
to thread_id by using following conversion:
if (is_main)
thread_index = 0;
else
thread_index += vdm->first_worker_thread_index;
thread_index here is a worker_id in reality. Thus before using
sw_interface_set_rx_placement() caller has to calculate worker_id. It is just
number of thread with type "workers" starting from zero. I also see that there
is a function inside VPP which converts thread_id to worker_id :
always_inline u32
vlib_get_worker_index (u32 thread_index)
{
return thread_index - 1;
}
But it is not used anywhere and I am not sure if -1 will be correct in future
or in case if any plugin adds its own threads.
Actually this function is the only API function which uses worker_id as an
argument. sw_interface_rx_placement_details() takes argument with name
worker_id but interprets it as thread_id (e.g. there is code like (worker_id ==
0) ? "main" : "worker" inside this function).
I think it is clear that worker_id is mixed with thread_id through all VPP API
code. In my opinion it is much more convenient for caller and developer to use
just thread_id for all VPP API functions.
So I want to replace worker_id and is_main arguments with single thread_id
argument for sw_interface_set_rx_placement().
My question is: Is it allowed to change API function interface in VPP? Because
I do not see any robust way to use sw_interface_set_rx_placement() function.
Thank you,
Vladimir Isaev
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#15719): https://lists.fd.io/g/vpp-dev/message/15719
Mute This Topic: https://lists.fd.io/mt/71860601/21656
Mute #vpp: https://lists.fd.io/mk?hashtag=vpp&subid=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] Need advice on sw_interface_set_rx_placement() API #vpp
> On 10 Mar 2020, at 17:39, visaev via Lists.Fd.Io
> wrote:
>
> Hi there,
>
> There is a VPP APIs function sw_interface_set_rx_placement(). This function
> allows us to set specific worker for the specified queue.
> And this function takes worker_id as an argument. worker_id is then
> translated to thread_id by using following conversion:
> if (is_main)
> thread_index = 0;
> else
> thread_index += vdm->first_worker_thread_index;
>
> thread_index here is a worker_id in reality. Thus before using
> sw_interface_set_rx_placement() caller has to calculate worker_id. It is just
> number of thread with type "workers" starting from zero. I also see that
> there is a function inside VPP which converts thread_id to worker_id:
> always_inline u32
> vlib_get_worker_index (u32 thread_index)
> {
> return thread_index - 1;
> }
>
This is basically placeholder, as we currently doesn’t have other thread types
except worker threads, but that may change in the future….
>
> But it is not used anywhere and I am not sure if -1 will be correct in future
> or in case if any plugin adds its own threads.
> Actually this function is the only API function which uses worker_id as an
> argument. sw_interface_rx_placement_details() takes argument with name
> worker_id but interprets it as thread_id (e.g. there is code like (worker_id
> == 0) ? "main" : "worker" inside this function).
>
> I think it is clear that worker_id is mixed with thread_id through all VPP
> API code. In my opinion it is much more convenient for caller and developer
> to use just thread_id for all VPP API functions.
> So I want to replace worker_id and is_main arguments with single thread_id
> argument for sw_interface_set_rx_placement().
>
> My question is: Is it allowed to change API function interface in VPP?
> Because I do not see any robust way to use sw_interface_set_rx_placement()
> function.
>
It is intentionally done this way as we don’t want people to assign rx queues
to threads which are not worker threads. I will prefer that this stays as it is…
—
Damjan-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#15720): https://lists.fd.io/g/vpp-dev/message/15720
Mute This Topic: https://lists.fd.io/mt/71860601/21656
Mute #vpp: https://lists.fd.io/mk?hashtag=vpp&subid=1480452
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 with FRR Bring-up - tap interface enable causing crash
Hi Murthy, I have noticed this crash in v20.01 version when router plugin interact with VPP code base during tap interface bring up in the host. I have provided patch, with that it works fine. Thanks, Kausik From: vpp-dev@lists.fd.io On Behalf Of Satya Murthy Sent: Monday, March 9, 2020 10:48 PM To: vpp-dev@lists.fd.io Subject: Re: [vpp-dev] VPP with FRR Bring-up - tap interface enable causing crash Message received from external source. Exercise caution when opening attachments, clicking links, or exchanging information. which fdio release version you are using? -- Thanks & Regards, Murthy -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15721): https://lists.fd.io/g/vpp-dev/message/15721 Mute This Topic: https://lists.fd.io/mt/71738703/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] Reporting stale tunnel via LINK DOWN event — ok or not?
Hi Nick,
It would seem to me rather awkward to send a link-state notification to inform
the CP of a non-existent interface.
I would suggest you use a new notification in which you can include the
DIP+TEID.
The client, via the API, can only affect the admin state of the link, the ‘link
state’ is determined by the environmental factors like is there a cable plugged
in.
You might be interested in the NO_SUCH_TUNNEL handling in IPSec code via the
punt-infra.
/neale
From: on behalf of Nick Zavaritsky
Date: Tuesday 10 March 2020 at 13:22
To: "vpp-dev@lists.fd.io"
Subject: [vpp-dev] Reporting stale tunnel via LINK DOWN event — ok or not?
Hi,
at EMnify we are working to extend GTPU support with features required
in mobile networks. According to GTPU specification, if a received packet
doesn't match an existing tunnel (unknown DIP+TEID), error indication is
sent back. When an error indication is received, we have to tell the control
plane so that it can take action.
Using existing interface state change notifications looks promising.
Is it appropriate to report a stale tunnel via LINK DOWN event, or should we
rather implement a brand-new notification?
Concerning interface state change notifications, I am somewhat puzzled how
to use it properly. Event structure is defined as follows:
define sw_interface_event
{
u32 client_index;
u32 pid;
vl_api_interface_index_t sw_if_index;
vl_api_if_status_flags_t flags;
bool deleted;
};
enum if_status_flags
{
IF_STATUS_API_FLAG_ADMIN_UP = 1,
IF_STATUS_API_FLAG_LINK_UP = 2,
};
I would expect flags to reflect the current interface state, however it is not
the case.
Toggling admin up state will deliver events with flags set to ADMIN_UP or 0.
Toggling link up state will deliver events with flags set to LINK_UP or 0.
It is not possible to tell on the client side whether the link went down (flags
= 0), or
if the interface was brought down administratively (flags = 0).
Any pointers?
Best,
N
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#15722): https://lists.fd.io/g/vpp-dev/message/15722
Mute This Topic: https://lists.fd.io/mt/71855353/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
