On Sun, Jan 14, 2018 at 12:10 PM, Damjan Marion (damarion) < damar...@cisco.com> wrote:
> > master 1: > create memif id 33 master socket /tmp/memif1.sock > > Interface name: memif-0/33 > Here! You know that because you had to look at "show int" or "show memif". What if earlier allocations of memif had happened to create a new socket? You don't know the "0" part of that name unless you look. Or rely on a very specific API call sequence ordering. > master 2: > create memif id 33 master socket /tmp/memif2.sock > > Interface name: memif-0/33 > No, it is a new socket, and a new pool index, so this one is named "memif1/33". And *that* is precisely the problem I am having to prevent here. Also, there are no dashes in these names despite your using them with me on every example you have sent me. vpp# create memif id 33 master socket /tmp/memif1.sock vpp# show memif interface memif0/33 id 33 mode ethernet file /tmp/memif1.sock flags listener-fd 28 conn-fd 0 num-s2m-rings 0 num-m2s-rings 0 buffer-size 0 vpp# create memif id 33 master socket /tmp/memif2.sock vpp# vpp# show memif interface memif0/33 id 33 mode ethernet file /tmp/memif1.sock flags listener-fd 28 conn-fd 0 num-s2m-rings 0 num-m2s-rings 0 buffer-size 0 interface memif1/33 id 33 mode ethernet file /tmp/memif2.sock flags listener-fd 29 conn-fd 0 num-s2m-rings 0 num-m2s-rings 0 buffer-size 0 > slave: > create memif id 33 slave socket /tmp/memif1.sock > create memif id 33 slave socket /tmp/memif2.sock > > Interface names: memif-0/33, memif-1/33 No. vpp# create memif id 33 slave socket /tmp/memif1.sock create memif: Interface with same id already exists > I _think_ you don't understand my issue here. I am in no way > > questioning the underlying implementation, nor am I questioning > > having the index-mappings that you use. > > > > My issue is in the names that get exposed to the user and when > > they become knowable. > > > > > In order to make your mechanisms work, it relies on having to reveal > > or expose the names mid-setup and then proceeding with the rest > > of the setup commands. > > > > > Possible area for improvement is adding explicit "create memif listener > <filename> <id XXX>" > > cli and API so > > you can better control assignment mapping of file_id to actual AF_UNIX > socket. > > > > OK, that is equivalent to my third suggestion, I think. Pre-allocating > the sockets > > in a known order so that they have known index numbers. In advance. > > If you don't allow for the creation of the (socket-name to socket-index) > mapping in advance > > of creating the memif itself, then the name of the memif effectively > becomes something > > unwieldly like "memif /path/to/socket/foo.sock id 23" everywhere. > > > > Today file_id is simply index to the pool of memif files. > > > > I know. And that is the problem. You have exposed an unreliable > allocation > > result to be the only authoritative and yet unknowable user identifier. > And here > > by "user" I mean any other "API user". In no way can the user say "Make > an > > item for me and call it <X>." > > > > Beside that, i don't see what else we can do to make your life easier.... > > > > I think the problem stems from the fact that you expose the socket index > > to the user visible names, and there is no way of knowing what those > > values will be. > > > > I think the whole problem can be avoid by simply exposing a memif name > > with just the one id that is used during creation of the memif. From an > > implementation standpoint, I think it is pretty easy to add to the > current > > implementation. > > - Add a hash in memif_main mapping user memif id to socket_index(*) > > - The uniqueness test during creation needs to be modified to check > > for the id within the global mapping, > > - When the memif is made, add the id to socket_index to the new hash > > - When the memif is removed, remove the id from the new hash > > > > Then only expose to the user the global memif id, and not the > socket_index too. > > The user supplied the id in the first place during creation, so we > satisfy the > > need to be able to say "Make a <thing> for me and call it <X>." So now > > the user knows that the corresponding SW IF will be named "memif-<id>" > > without having to guess or rely on API call ordering. > > > I dont like this proposal, it adds another ID to the game or limits us for > using same > id on 2 different socket files. No, I don't think it does limit anything like that. The underlying implementation can remain the same, and the connection set ups can remain. It's just the name of the interface that gets created is in a single global namespace like "memif%d". > Just like with loopback interfaces then, we really need to have > predictable > > naming creation mechanisms in every aspect of the API presented by VPP. > > If "create memif socket file <file> id <id> [master|slave|" > works for you i would suggest that we go that way. > I'm not able to use the CLI, so I want to see the API form. Like I said, I think this means that we effectively name the memif by its (full socket path name, id) pair all the time. It's really the wrong approach. Fundamentally, the user should never need to have the "socket" aspect of the underlying implementation exposed to him. Call it anything else and you'll see what I mean. Say, "grouping", so that we place various masters and slaves into the same "grouping". So scenario above will look like: > > master 1: > create memif socket file /tmp/memif1.sock socket-id 11 server > Note, I added "socket-" here ----------------^^^^ Otherwise it conflicts with regular memif id. HTH, jdl
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
