Question on the use of ETH_P_CONTROL

Question on the use of ETH_P_CONTROL

[Alexander Duyck]

I have a wired Ethernet driver that will need to support a user space
application with UIO access and a network device.  The network device
will need a way to send raw frames with some descriptor data to and from
the user space application.  The frames are not meant to be routed and
are not meant for this host, only for the user space application.  After
doing some digging I came across the definition for ETH_P_CONTROL, which
seems to be a good solution for my current issue.

My thought is to do something like this for Rx control frames:
	eth_type_trans(skb);
	skb->protocol = htons(ETH_P_CONTROL);
	skb->mac_header -= sizeof(struct desc_hdr);
	desc_hdr = (struct desc_hdr *)skb_mac_header(skb);
	desc_hdr->val = val;

For frames received from the user space application I would essentially
just leave the descriptor header on and notify the hardware that it is
present for any frames received that have ETH_P_CONTROL as their protocol.

Then all that is left is for the user space to allocate a raw packet
socket and bind it to our interface specifying the control protocol so
that it can send and receive just the control frames.

I'm looking for any thoughts, issues, or concerns with this approach.

Thanks,

Alex

Re: Question on the use of ETH_P_CONTROL

[David Miller]

From: Alexander Duyck <alexander.h.duyck@intel.com>
Date: Wed, 24 Apr 2013 11:17:50 -0700

> I have a wired Ethernet driver that will need to support a user space
> application with UIO access and a network device.  The network device
> will need a way to send raw frames with some descriptor data to and from
> the user space application.  The frames are not meant to be routed and
> are not meant for this host, only for the user space application.  After
> doing some digging I came across the definition for ETH_P_CONTROL, which
> seems to be a good solution for my current issue.
> 
> My thought is to do something like this for Rx control frames:
> 	eth_type_trans(skb);
> 	skb->protocol = htons(ETH_P_CONTROL);
> 	skb->mac_header -= sizeof(struct desc_hdr);
> 	desc_hdr = (struct desc_hdr *)skb_mac_header(skb);
> 	desc_hdr->val = val;
> 
> For frames received from the user space application I would essentially
> just leave the descriptor header on and notify the hardware that it is
> present for any frames received that have ETH_P_CONTROL as their protocol.
> 
> Then all that is left is for the user space to allocate a raw packet
> socket and bind it to our interface specifying the control protocol so
> that it can send and receive just the control frames.
> 
> I'm looking for any thoughts, issues, or concerns with this approach.

I looked this over briefly a few nights ago, and the only other place I
see this used is the hostap driver.  hostap is a big body of code that
does lot of things in unique and rather ad-hoc ways.

hostap was written in an environment where interfaces and
infrastructure for what it wanted to do didn't exist, so the author
just did his own thing in each and every such instance.

I want to encourage you to steer away from that kind of approach.

Although I'm cautiously skeptical, you may not end up being the only
other person trying to push descriptors into the kernel from userspace
and then trigger device TX/RX.  If every driver makes it's own control
plane for this, wait for troubles...

Re: Question on the use of ETH_P_CONTROL

[Alexander Duyck]

On 04/29/2013 10:42 AM, David Miller wrote:
> From: Alexander Duyck <alexander.h.duyck@intel.com>
> Date: Wed, 24 Apr 2013 11:17:50 -0700
>
>> I have a wired Ethernet driver that will need to support a user space
>> application with UIO access and a network device.  The network device
>> will need a way to send raw frames with some descriptor data to and from
>> the user space application.  The frames are not meant to be routed and
>> are not meant for this host, only for the user space application.  After
>> doing some digging I came across the definition for ETH_P_CONTROL, which
>> seems to be a good solution for my current issue.
>>
>> My thought is to do something like this for Rx control frames:
>> 	eth_type_trans(skb);
>> 	skb->protocol = htons(ETH_P_CONTROL);
>> 	skb->mac_header -= sizeof(struct desc_hdr);
>> 	desc_hdr = (struct desc_hdr *)skb_mac_header(skb);
>> 	desc_hdr->val = val;
>>
>> For frames received from the user space application I would essentially
>> just leave the descriptor header on and notify the hardware that it is
>> present for any frames received that have ETH_P_CONTROL as their protocol.
>>
>> Then all that is left is for the user space to allocate a raw packet
>> socket and bind it to our interface specifying the control protocol so
>> that it can send and receive just the control frames.
>>
>> I'm looking for any thoughts, issues, or concerns with this approach.
> I looked this over briefly a few nights ago, and the only other place I
> see this used is the hostap driver.  hostap is a big body of code that
> does lot of things in unique and rather ad-hoc ways.
>
> hostap was written in an environment where interfaces and
> infrastructure for what it wanted to do didn't exist, so the author
> just did his own thing in each and every such instance.
>
> I want to encourage you to steer away from that kind of approach.
>
> Although I'm cautiously skeptical, you may not end up being the only
> other person trying to push descriptors into the kernel from userspace
> and then trigger device TX/RX.  If every driver makes it's own control
> plane for this, wait for troubles...

Actually I have already steered somewhat away from the original idea I
had.  I am now looking at putting the control traffic on a separate
non-Ethernet netdev that would have a custom header that includes the
control information for the frame.  It would would use the same approach
where the custom header would come before the Ethernet header as I was
doing above.  That addresses several issues since I realized I cannot
mix Ethernet and non-Ethernet protocols on the same device.

For the transmit side I can just generate dummy control data for any
non-raw packets that are routed to the interface.  That should let me
just open a standard raw socket and have everything work as expected.

Thanks,

Alex