From: Alexander Duyck <alexander.h.duyck@intel.com>
To: netdev <netdev@vger.kernel.org>,
David Miller <davem@davemloft.net>,
Eric Dumazet <eric.dumazet@gmail.com>,
Ben Hutchings <bhutchings@solarflare.com>,
Stephen Hemminger <shemminger@vyatta.com>
Subject: Question on the use of ETH_P_CONTROL
Date: Wed, 24 Apr 2013 11:17:50 -0700 [thread overview]
Message-ID: <517821CE.207@intel.com> (raw)
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
next reply other threads:[~2013-04-24 18:18 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-24 18:17 Alexander Duyck [this message]
2013-04-29 17:42 ` Question on the use of ETH_P_CONTROL David Miller
2013-04-29 20:55 ` Alexander Duyck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=517821CE.207@intel.com \
--to=alexander.h.duyck@intel.com \
--cc=bhutchings@solarflare.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=shemminger@vyatta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.