Patchwork [RFC] P2P: send GO neg confirm without wait

login
register
mail settings
Submitter Johannes Berg
Date June 1, 2012, 8:46 a.m.
Message ID <1338540384.4884.13.camel@jlt3.sipsolutions.net>
Download mbox | patch
Permalink /patch/162277/
State Accepted
Commit 792c8877c3e9558a6def558c6d35833a00571683
Headers show

Comments

Johannes Berg - June 1, 2012, 8:46 a.m.
From: Johannes Berg <johannes.berg@intel.com>

The GO negotiation confirm frame doesn't need
to be sent with a wait since we don't expect a
response to it.

Signed-hostap: Johannes Berg <johannes.berg@intel.com>
---
 src/p2p/p2p_go_neg.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Jouni Malinen - June 6, 2012, 1:40 p.m.
On Fri, Jun 01, 2012 at 10:46:24AM +0200, Johannes Berg wrote:
> The GO negotiation confirm frame doesn't need
> to be sent with a wait since we don't expect a
> response to it.

Thanks, applied. I was trying to figure out why the wait was there in
the first place, but could not really come up with any good reason for
maintaining this value. I think it ended up coming from the early design
where a hardcoded value was used for all operation and this GO Neg Conf
frame was just never optimized to use something else than the default
200 ms wait. Not that this really should make much of a difference since
the wait is canceled immediately after receiving TX status event from
the driver.
Johannes Berg - June 6, 2012, 1:45 p.m.
On Wed, 2012-06-06 at 16:40 +0300, Jouni Malinen wrote:
> On Fri, Jun 01, 2012 at 10:46:24AM +0200, Johannes Berg wrote:
> > The GO negotiation confirm frame doesn't need
> > to be sent with a wait since we don't expect a
> > response to it.
> 
> Thanks, applied. I was trying to figure out why the wait was there in
> the first place, but could not really come up with any good reason for
> maintaining this value. I think it ended up coming from the early design
> where a hardcoded value was used for all operation and this GO Neg Conf
> frame was just never optimized to use something else than the default
> 200 ms wait. 

Makes sense.

> Not that this really should make much of a difference since
> the wait is canceled immediately after receiving TX status event from
> the driver.

Yes, that's true, it just saves some calculations in mac80211 :-)

johannes

Patch

diff --git a/src/p2p/p2p_go_neg.c b/src/p2p/p2p_go_neg.c
index 2bf48b3..5b723b6 100644
--- a/src/p2p/p2p_go_neg.c
+++ b/src/p2p/p2p_go_neg.c
@@ -1022,7 +1022,7 @@  fail:
 	else
 		freq = dev->listen_freq;
 	if (p2p_send_action(p2p, freq, sa, p2p->cfg->dev_addr, sa,
-			    wpabuf_head(conf), wpabuf_len(conf), 200) < 0) {
+			    wpabuf_head(conf), wpabuf_len(conf), 0) < 0) {
 		wpa_msg(p2p->cfg->msg_ctx, MSG_DEBUG,
 			"P2P: Failed to send Action frame");
 		p2p_go_neg_failed(p2p, dev, -1);