Hi Jon, The CLI is intended for human user. One can thus create an interface, use “show int” to see the name of the created interface and use it for subsequent CLIs on that interface.
The API calls expect the caller to specify sw_if_index of an interface to be configured. The interface creation API such as create_loopback will return the sw_if_index of the created loopback interface. Thus, calls following creation of loopback will use the returned sw_if_index in subsequent API calls to configure its IP address or put it in a BD as BVI. There is no assumption needed as interface name is not involved . As for getting the name of interfaces and their sw_if_index, there is the dump_interface_table API which will provide interface names and associated sw_if_index of all interfaces. Regards, John From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Jon Loeliger Sent: Wednesday, February 22, 2017 4:56 PM To: vpp-dev <vpp-dev@lists.fd.io> Subject: [vpp-dev] Loopback Interface Names Folks, So, I want to address this example from Dave's "home gateway" example: loopback create set int l2 bridge loop0 1 bvi set int ip address loop0 192.168.1.1/24<http://192.168.1.1/24> set int state loop0 up Here, lines 2, 3, and 4 all have unspoken knowledge of the effects of line 1. Specifically, it "knows" that "loop0", by name, just got created. One just knows. In VPP land, one issues an API call to create a loopback interface. VPP makes up the name for it ("loop0"), and tells you a new sw_if_index for it. Likely something like 5 or 6 or so, depending on how many other IFs have been made already. In a Popular Router Configuration Language (PRCL), one says interface loopback 0 and it creates the named interface, "Loopback0". But there is a subtle difference, in VPP the name is assumed for subsequent commands, while in PRCL, later commands will need to know the name of the loopback interface. Not assume, know. But without specifying it at creation, one can not know its name for use later. So, I'm proposing a slight modification to the create_loopback API message. My proposal can maintain backward compatibility. Currently: /** \brief Create loopback interface request @param client_index - opaque cookie to identify the sender @param context - sender context, to match reply w/ request @param mac_address - mac addr to assign to the interface if none-zero */ define create_loopback { u32 client_index; u32 context; u8 mac_address[6]; }; I'm proposing adding a field that specifies the actual name of the loopback interface be added. define create_loopback { u32 client_index; u32 context; u8 mac_address[6]; u8 name[32]; }; Pick your favorite upper-bound for name length or substitute a zero-terminated C-string-like name. Don't much care there. But my point is that to achieve some compatibility with PRCL's expected behavior, we'll need them to be named "Loopback<n>", and not "loop<n>". Naturally, if the name isn't supplied by the API caller, the current default name can be allocated. At the bare minimum, the instance number should be supplied in the API call and the VAT command changed to allow the form: loopback create [<n>] For example: > loopback create 2 That way there is an explicit, not assumed, correspondence for the following commands like: > set int l2 bridge loop2 1 bvi Thoughts? jdl
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev