Re: [vpp-dev] Questions about AF_PACKET and VNET_DEVICE_CLASS Functions

[Damjan Marion]

> On 20 Mar 2017, at 20:25, Jon Loeliger  wrote:
> 
> 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”?

If I remember correctly mac_addr_change_function is optional callback
for interfaces which need to do some special work when mac address is changed.
DPDK is such change as we need to call rte_eth_dev_default_mac_addr_set DPDK 
API.
as AF_PACKET doesn’t need to do any special work, it is not defined.

So what are you asking should simply work, have you tried "set interface mac 
address” CLI?


>  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

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] Questions about AF_PACKET and VNET_DEVICE_CLASS Functions

[Jon Loeliger]

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