Jon, Each memif connection between master and slave is uniquely identified by AF_UNIX socket and ID pair. This is first law of memif :)
On unix side AF_UNIX socket is identified by filename in the filesystem but that is too long so in VPP each AF_UNIX socket have assigned file_id and that index is used in memif interface name. So as you described, memif interface is formatted as follows: memif-<file_id>/<interface id> You cannot have 2 VPP instances listening on the same AF_UNIX socket, so only one VPP instance can be listener. Because of that you cannot configure both master and slave to use same AF_UNIX socket. This is simply how system works. On other side it is perfectly fine to have one slave connected to 2 different masters where both connections have same interface ID. That's why interface name is constructed out of 2 numbers. Having only interface_id in interface name will simply not work in this case. 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. Today file_id is simply index to the pool of memif files. Beside that, i don't see what else we can do to make your life easier.... Thanks, Damjan On 13 Jan 2018, at 15:33, Jon Loeliger <j...@netgate.com<mailto:j...@netgate.com>> wrote: Hi VPPeople, I am working on adding memif support to our system and need to design some User Interface pieces for it. I am having a bit of a hard time with one naming aspect of the memif components. Each memif entry has a unique u32 id assigned to it. Each memif entry requires a socket as part of its setup. Each memif entry can be either a slave or a master role. Each memif entry has a corresponding SW IF as well. The SW IF name is created using the template "memif%d/%d" where the first %d is the pool index of the socket's filename, and the second %d is the unique id. There is a default socket filename that is used when no socket name is provided in a "memif_create" API call. I am able to create either "master" or "slave" entries with unique ids, but not both using the default socket. Changing the socket name allows both master and slave entries to be created. Eventually, some experimentation lead me to believe that there must be an underlying problem with using the same socket for master and for slave entries. In fact, reading some of the code, I found src/plugins/memif/memif.c, line 585: /* existing socket file can be either master or slave but cannot be both */ OK. So if both master and slave entries might be present in the system, specifying the socket filename is required at some point. In the User Interface that I have, I allow a user to declare that they want to make a memif and state attributes about it. Specifically, I allow them to make a role "slave" or "master", and set some queue sizes and lengths. The User shouldn't ever care about some underlying socket file name here. (It is purely an implementation detail they don't care about.) Later, the User should be able to specify attributes about the corresponding SW IF for the memif. However, there is no way for the user to know (predict with certainty) the name of that SW interface. They can get close, but there is no way to know for sure. It will be something like "memif.../<id>" where the "<id>" part is a unique number they provided in the memif declaration and setup earlier. However, the User cannot predict the socket number. And lest you say something like "but creating the memif instance returns the sw_if_index, and you can use that to lookup the SW IF's name", understand that this is NOT necessarily an interactive system. We have to be able to set up batch configuration without screen scraping the results. The user has to be able to reliably predict the corresponding SW IF name. So let's ask some questions and posit some solutions. I'm willing to grant that different sockets are needed for the master and slave roles. Are there ever more than two sockets needed for all of the memif instances? Is it good enough to have one slave, and one master socket? If so, then we can just use the role to map an instance to a socket and have the corresponding SW IF name be, say, memif-slave/<id> or memif-master/<id>. Right now, as implemented, the "unique id" is not "for all memifs". It is for "each {master,slave" group, though. That is one can have "unique id 23" as both master and slave. More accurately, the id need only be unique within a given socket pool index. (And we know there will be different sockets for masters and for slaves.) So we could totally change this looser uniqueness requirement (per socket) to "for all memif instances". With this approach, we could use the unique id to, well, uniquely identify the SW IF using a name like "memif-<id>". We'd have to keep a mapping to socket within the memif entry (but that is already done!) We just wouldn't place the socket pool index in part of the SW IF name. Another solution would be to pre-allocate memif sockets with named socket entries that the User could control. For example, allow a user to pre-allocate a socket called "slave_sock" to file "/var/run/vpp/slave.sock". And then within the memif entry, use the _name_ of the socket, not the filename of the socket. Now the user knows that the SW IF would be named "memif-slave_sock/<id>". Other thoughts? Thanks, jdl _______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io<mailto: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
