From: Johannes Berg <johannes@sipsolutions.net>
To: mpubbise@qti.qualcomm.com
Cc: linux-wireless@vger.kernel.org,
Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
Subject: Re: [RFCv2 2/2] mac80211: Implement data xmit for 802.11 encap offload
Date: Fri, 03 Mar 2017 13:39:14 +0100 [thread overview]
Message-ID: <1488544754.25750.8.camel@sipsolutions.net> (raw)
In-Reply-To: <1488540807-27415-3-git-send-email-mpubbise@qti.qualcomm.com>
> There is a field, no_80211_encap, added to ieee80211_tx_info:control
> to mark if the 802.11 encapsulation is offloaded to driver.
Why is that needed? Since you have a separate TX path (ndo_start_xmit),
wouldn't it make more sense to call into a drv_tx_8023() or something
like that instead?
> There is also a new callback for tx completion status indication
> to handle data frames using 802.11 encap offload.
Maybe you could just use _noskb?
Haven't really looked at the rest all that much, few comments:
* not sure you're handling non-linear frames right, are you assuming
the driver can handle them? probably a fair assumption, but should
be documented
* you seem to also be assuming that the driver not only does all
encryption in HW (which is obviously needed) but also does all the
key lookups etc. - also seems fair, but also should be documented
* similarly for a lot of other (all?) fields in tx_info
* you seem to be assuming that if encap offload is supported then it's
also *desired* for AP/VLAN and client interfaces, if not 4-addr.
This seems ... probably about right, but if drivers don't always
support it? Or support it in more cases? Perhaps we can move the
SUPPORTS_80211_ENCAP flag into a VIF flag instead, so they can do it
more fine-grained?
johannes
next prev parent reply other threads:[~2017-03-03 13:31 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-03 11:33 [RFCv2 0/2] Add new transmit data path for ethernet frame format mpubbise
2017-03-03 11:33 ` [RFCv2 1/2] mac80211: Add provision for 802.11 encap offload mpubbise
2017-03-03 12:29 ` Johannes Berg
2017-03-08 15:49 ` Pubbisetty, Manikanta
2017-03-03 11:33 ` [RFCv2 2/2] mac80211: Implement data xmit " mpubbise
2017-03-03 12:39 ` Johannes Berg [this message]
2017-03-08 15:46 ` Pubbisetty, Manikanta
2017-03-08 21:33 ` Johannes Berg
2017-03-09 9:56 ` Pubbisetty, Manikanta
2017-03-14 14:11 ` Johannes Berg
2017-03-21 5:36 ` Manikanta Pubbisetty
2017-03-31 11:52 ` Johannes Berg
2017-04-11 6:06 ` Manikanta Pubbisetty
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=1488544754.25750.8.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=mpubbise@qti.qualcomm.com \
--cc=vthiagar@qti.qualcomm.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.