Folks,
I am trying to understand a bit more about the "host" interface
for some AF_PACKET interfaces.
Currently, there is a single API call to create an AF_PACKET interface.
It simultaneously sets the HW_ADDR (ie, MAC address) of the interface
to either user-specified value, or a randomly generated value.
I'd like to separate the two steps, or at the very least, be able to set
the MAC address in a separate API call that isn't the initial CREATE call.
Why? Imagine the sequence of commands that might look like this:
# interface host fred
# mac 11:22:33:44:55:66
# no shutdown
# exit
So, at the time of "interface host fred", we'd like to cause the interface
to be created, but the MAC isn't really available yet. Then later, when
we see the "mac ...." line, we'd like to set, or change, the MAC with the
new user-supplied value.
In the case of a "normal" or DPDK interface, the VNET_DEVICE_CLASS
functions specify a .mac_addr_change_function. Roughly from
src/plugins/dpdk/device/device.c lines 774 or so:
VNET_DEVICE_CLASS (dpdk_device_class) = {
.mac_addr_change_function = dpdk_set_mac_address,
};
That's all well and good.
Naturally, no such mac_addr_change_function exists for the
AF_PACKET device class.
My question is: Is there a fundamental reason that prevents such
a function from being written, or is it a case of simply "we just haven't
gotten to that detail yet"? The latter case implying that someone
could actually achieve a MAC addr change on the AF_PACKET
interface, if an enterprising young engineer were to, say, write a new
API function to get there.
So, yeah, I know the actual MAC might not be really important, but
maybe the user is trying to match some external requirement or so?
I don't know.
Thoughts?
jdl
_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
