Hi Jon, The difference between the two sub-interface create APIs is that create_vlan_subif is typically used for creating a sub-interface for L3 IP forwarding where you just specify two parameters: sw_if_index of the main interface and the VLAN ID. It create a sub-interface using the same VLAN ID as the sub-interface .N value, doing exact match on a dot1q VLAN tag of the specified ID value.
The create_subif API is the generic sub-interface creation API where you can specify sub-interface more flexibly, such as sub-interface ID (so that you can choose to be the same or different to that of VLAN ID), how many VLAN tags, dot1ad or not (i.e. dot1q), exact match or not (i.e. best match with at least that number of VLAN tags), default sub-interface, sub-interface without VLAN tags, etc. With this API there are 10 parameters to specify to provide the ability to create more flexible sub-interface classification for L2 forwarding. More explanation of sub-interface classification of packets can be found in the comments to the sub-interface creation CLI "create sub-interfaces" in src/vnet/interface_cli.c, starting at around line 737, where the CLI also have an abbreviated form matching that of the simpler create_vlan_subif API. As for deleting a VTR operation on an interface, it is achieved using the VTR API using L2_VTR_DISABLED for the parameter vtr_op. I agree with you the "DISABLE" naming may the impression VTR operation is still present but disabled. The fact is that it is deleted and there is no way to "enable" the VTR operation that was "disabled". As for using u32 for all VTR API parameters, I don't know of any justification other than that it was coded this way since day one and never been cleaned up. Both push_dot1q and vtr_op can be u8; tag1 and tag2 can be u16. Regards, John -----Original Message----- From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Jon Loeliger Sent: Friday, June 02, 2017 10:26 AM To: vpp-dev <vpp-dev@lists.fd.io> Subject: [vpp-dev] Subif/VLAN Questions Hey Audience, Guess what! (What?) I have another set of questions! This time, VLAN/Subif related. Start with the easy one: Is the API call create_vlan_subif slated for removal or deprecation? I think it should be. It seems to me to be totally redundant and a subset of the more general API call create_subif. Under the covers, they resolve to an identical SW interface creation function as well. Or have I missed something here? So the mystery question now: Why is there no mechanism to delete an L2 interface VLAN tag rewrite rule? Sure, one can apply a "disable" operation to the subif, but that is not the same as removing the rewrite rule. Is it expected that the user will just remove the whole subif to achieve this effect? And the question of inconsistency: Why does the l2_interface_vlan_tag_rewrite API call only use u32 values, even for fields that are clearly only, say, a u16 or u8? Seems like everywhere else things have been meticulously sized; just not on this call. Thanks, jdl _______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev _______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
