You would certainly have to rewrite vnet_create_loopback_interface(...) a little bit. That’s not necessarily a bad thing.
Please brain-police the instance number: flunk attempts to create specific loopback instances (e.g. loop0) more than once, and so forth. Bitmap, plus some upper limit (maybe 16k?) on the loopback instance number. HTH… Dave 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
