Re: [vpp-dev] Some L2 Bridge API Questions
Hi Jon, Yes, you are right. There is no API to change the aging interval of a BD. It seems when MAC aging support was added to VPP, a new CLI but no API was added to change the aging value of a BD. It should be fairly straightforward to add this new API except we are now in API freeze for 17.04 release. Without a new API, I suppose the only way to change MAC aging in a BD is to use the bridge_domain_add_del API to specify all the feature flags and MAC aging value to overwrite the current BD setting. Regards, John From: Jon Loeliger [mailto:j...@netgate.com] Sent: Wednesday, March 15, 2017 3:56 PM To: John Lo (loj) Cc: vpp-dev Subject: Re: [vpp-dev] Some L2 Bridge API Questions John, So, I see that, when creating a bridge domain using the API call bridge_domain_add_del, one can specify some feature flags of the domain as well as the mac-age parameter. Later, it looks like one can alter the feature flags using the API call bridge_flags, changing one or more features to be enabled or disabled on the fly. However, it looks like there is no mechanism to alter just the mac-age parameter. So, a few questions. Is one expected to re-issue the bridge domain "add" request again, with all the same flag-bits, but with the new mac-age value? Or is this just a missing API call that is yet to be added? In particular, I notice that the code in src/vnet/l2/l2_bd.c has a command to set a new mac-age, but it doesn't make an API call to do so; instead it appears to go directly to the underlying implementation to affect a change. Any advice here? Thanks, jdl ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
Re: [vpp-dev] Some L2 Bridge API Questions
John, So, I see that, when creating a bridge domain using the API call bridge_domain_add_del, one can specify some feature flags of the domain as well as the mac-age parameter. Later, it looks like one can alter the feature flags using the API call bridge_flags, changing one or more features to be enabled or disabled on the fly. However, it looks like there is no mechanism to alter just the mac-age parameter. So, a few questions. Is one expected to re-issue the bridge domain "add" request again, with all the same flag-bits, but with the new mac-age value? Or is this just a missing API call that is yet to be added? In particular, I notice that the code in src/vnet/l2/l2_bd.c has a command to set a new mac-age, but it doesn't make an API call to do so; instead it appears to go directly to the underlying implementation to affect a change. Any advice here? Thanks, jdl ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
Re: [vpp-dev] Some L2 Bridge API Questions
Hi Jon, Making the API call using the sw_if_index of the interface with enable=0 will remove the interface from the bridge domain. The interface will then be back in L3 mode, as I implied from my original reply. Regards, John From: Jon Loeliger [mailto:j...@netgate.com] Sent: Tuesday, March 14, 2017 3:23 PM To: John Lo (loj) Cc: vpp-dev Subject: Re: [vpp-dev] Some L2 Bridge API Questions On Tue, Mar 14, 2017 at 1:50 PM, John Lo (loj) mailto:l...@cisco.com>> wrote: Hi Jon, Hi John, You make a valid point about the name chosen for the API param “enable”. Rather than argue about the best name, let me describe how it works. Sure! The API is intended to enable or disable an interface in L2 bridging mode. By disable, or enable=0, it will put the interface back to L3 mode which is the default mode for an interface. If the API is called with enable=1 while the interface is already in L2 bridging mode, the code would actually perform a disable followed by enable of the interface’s current bridging mode as specified. Ah, OK. So at that time (the re-enable), and differing parameter would being to take effect. So simply re-issuing the API call with the new parameters and an "enable" will be sufficient. So there isn't a way to remove the bridge from the interface once it has been associated the first time? Or will that be accomplished by actually removing the bridge from the bridge table? Even if the bridge_domain ID is left dangling on the interface? I take your point and will remember to update its comment in the API file, including fix the typo for “bridge”. Thanks! jdl ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
Re: [vpp-dev] Some L2 Bridge API Questions
On Tue, Mar 14, 2017 at 1:50 PM, John Lo (loj) wrote: > Hi Jon, > Hi John, > You make a valid point about the name chosen for the API param “enable”. > Rather than argue about the best name, let me describe how it works. > Sure! > The API is intended to enable or disable an interface in L2 bridging mode. > By disable, or enable=0, it will put the interface back to L3 mode which is > the default mode for an interface. If the API is called with enable=1 > while the interface is already in L2 bridging mode, the code would actually > perform a disable followed by enable of the interface’s current bridging > mode as specified. > Ah, OK. So at that time (the re-enable), and differing parameter would being to take effect. So simply re-issuing the API call with the new parameters and an "enable" will be sufficient. So there isn't a way to remove the bridge from the interface once it has been associated the first time? Or will that be accomplished by actually removing the bridge from the bridge table? Even if the bridge_domain ID is left dangling on the interface? > I take your point and will remember to update its comment in the API file, > including fix the typo for “bridge”. > Thanks! jdl ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
Re: [vpp-dev] Some L2 Bridge API Questions
Hi Jon, You make a valid point about the name chosen for the API param “enable”. Rather than argue about the best name, let me describe how it works. The API is intended to enable or disable an interface in L2 bridging mode. By disable, or enable=0, it will put the interface back to L3 mode which is the default mode for an interface. If the API is called with enable=1 while the interface is already in L2 bridging mode, the code would actually perform a disable followed by enable of the interface’s current bridging mode as specified. I take your point and will remember to update its comment in the API file, including fix the typo for “bridge”. Regards, John From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Jon Loeliger Sent: Tuesday, March 14, 2017 2:27 PM To: vpp-dev Subject: [vpp-dev] Some L2 Bridge API Questions Hi folks, I have a few questions about the sw_interface_set_l2_bridge API message. Now, some people have called me a "pedantic ass", to my face even, so I can handle that. :-) And I wouldn't want to disappoint, so here we go... From commit 374e2c5fc30a5bfabfd2eb6c2d3ca5797402af16, line 640 of src/vpp/api/vpe.api: 640 /** \brief Interface bridge mode request 641 @param client_index - opaque cookie to identify the sender 642 @param context - sender context, to match reply w/ request 643 @param rx_sw_if_index - the interface 644 @param bd_id - bridge domain id 645 @param bvi - Setup interface as a bvi, bridge mode only 646 @param shg - Shared horizon group, for bridge mode only 647 @param enable - Enable beige mode if not 0, else set to L3 mode 648 */ 649 define sw_interface_set_l2_bridge 650 { 651u32 client_index; 652u32 context; 653u32 rx_sw_if_index; 654u32 bd_id; 655u8 shg; 656u8 bvi; 657u8 enable; 658 }; I want to pick on the "u8 enable" field. First, the easy one: Line 647 has a typo for "bridge", right? OK, good. But let's talk about "enable/disable" versus "add/del". Is this really an enable/disable flag? So once "added" to the interface at rx_sw_if_index, there is no removing it? Or did "disable" really remove it? Many of the other API calls have an "is_add" field. Is there really no way to remove it once added? How is one expected to change a flag on this bridge? For example, to change the BVI from "false" to "true" after it has been established, ("enabled", right?) does one just re-issue the same API call again with the new bvi "true" value? Or should the bridge be "disabled", flag changed, and then re-"enabled"? Or even the interface shutdown, changed, and then brought back up? Thanks, jdl ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
[vpp-dev] Some L2 Bridge API Questions
Hi folks, I have a few questions about the sw_interface_set_l2_bridge API message. Now, some people have called me a "pedantic ass", to my face even, so I can handle that. :-) And I wouldn't want to disappoint, so here we go... >From commit 374e2c5fc30a5bfabfd2eb6c2d3ca5797402af16, line 640 of src/vpp/api/vpe.api: 640 /** \brief Interface bridge mode request 641 @param client_index - opaque cookie to identify the sender 642 @param context - sender context, to match reply w/ request 643 @param rx_sw_if_index - the interface 644 @param bd_id - bridge domain id 645 @param bvi - Setup interface as a bvi, bridge mode only 646 @param shg - Shared horizon group, for bridge mode only 647 @param enable - Enable beige mode if not 0, else set to L3 mode 648 */ 649 define sw_interface_set_l2_bridge 650 { 651u32 client_index; 652u32 context; 653u32 rx_sw_if_index; 654u32 bd_id; 655u8 shg; 656u8 bvi; 657u8 enable; 658 }; I want to pick on the "u8 enable" field. First, the easy one: Line 647 has a typo for "bridge", right? OK, good. But let's talk about "enable/disable" versus "add/del". Is this really an enable/disable flag? So once "added" to the interface at rx_sw_if_index, there is no removing it? Or did "disable" really remove it? Many of the other API calls have an "is_add" field. Is there really no way to remove it once added? How is one expected to change a flag on this bridge? For example, to change the BVI from "false" to "true" after it has been established, ("enabled", right?) does one just re-issue the same API call again with the new bvi "true" value? Or should the bridge be "disabled", flag changed, and then re-"enabled"? Or even the interface shutdown, changed, and then brought back up? Thanks, jdl ___ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev