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.../" where
the "" 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/ or memif-master/.
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-". 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/".
Other thoughts?
Thanks,
jdl
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
