[RFC] P2P: send GO neg confirm without wait

Submitted by Johannes Berg on June 1, 2012, 8:46 a.m.

Details

Message ID 1338540384.4884.13.camel@jlt3.sipsolutions.net
State Accepted
Commit 792c8877c3e9558a6def558c6d35833a00571683
Headers show

Commit Message

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(-)

Comments

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 hide | download patch | download mbox

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);