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

Reply via email to