Hi Marcel, > -----Original Message----- > From: linux-bluetooth-owner@xxxxxxxxxxxxxxx [mailto:linux-bluetooth- > owner@xxxxxxxxxxxxxxx] On Behalf Of Marcel Holtmann > Sent: 20 September 2011 14:05 > To: Gustavo Padovan > Cc: Luiz Augusto von Dentz; linux-bluetooth@xxxxxxxxxxxxxxx > Subject: Re: [RFC 3/5 v2] Bluetooth: make use sk_priority to priritize > RFCOMM packets > > Hi Gustavo, > > > > Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@xxxxxxxxx> > > > --- > > > net/bluetooth/rfcomm/core.c | 51 +++++++++++++++++++++++++++++-- > ----------- > > > net/bluetooth/rfcomm/sock.c | 2 + > > > 2 files changed, 37 insertions(+), 16 deletions(-) > > > > > > diff --git a/net/bluetooth/rfcomm/core.c > b/net/bluetooth/rfcomm/core.c > > > index 85580f2..bfc6bce 100644 > > > --- a/net/bluetooth/rfcomm/core.c > > > +++ b/net/bluetooth/rfcomm/core.c > > > @@ -65,7 +65,8 @@ static DEFINE_MUTEX(rfcomm_mutex); > > > > > > static LIST_HEAD(session_list); > > > > > > -static int rfcomm_send_frame(struct rfcomm_session *s, u8 *data, > int len); > > > +static int rfcomm_send_frame(struct rfcomm_session *s, u8 *data, > int len, > > > + u32 priority); > > > static int rfcomm_send_sabm(struct rfcomm_session *s, u8 dlci); > > > static int rfcomm_send_disc(struct rfcomm_session *s, u8 dlci); > > > static int rfcomm_queue_disc(struct rfcomm_dlc *d); > > > @@ -747,19 +748,34 @@ void rfcomm_session_getaddr(struct > rfcomm_session *s, bdaddr_t *src, bdaddr_t *d > > > } > > > > > > /* ---- RFCOMM frame sending ---- */ > > > -static int rfcomm_send_frame(struct rfcomm_session *s, u8 *data, > int len) > > > +static int rfcomm_send_frame(struct rfcomm_session *s, u8 *data, > int len, > > > + u32 priority) > > > { > > > struct socket *sock = s->sock; > > > + struct sock *sk = sock->sk; > > > struct kvec iv = { data, len }; > > > struct msghdr msg; > > > > > > - BT_DBG("session %p len %d", s, len); > > > + BT_DBG("session %p len %d priority %u", s, len, priority); > > > + > > > + if (sk->sk_priority != priority) { > > > + lock_sock(sk); > > > + sk->sk_priority = priority; > > > + release_sock(sk); > > > + } > > > > > > memset(&msg, 0, sizeof(msg)); > > > > > > return kernel_sendmsg(sock, &msg, &iv, 1, len); > > > } > > > > > > +static int rfcomm_send_cmd(struct rfcomm_session *s, struct > rfcomm_cmd *cmd) > > > +{ > > > + BT_DBG("%p cmd %u", s, cmd->ctrl); > > > + > > > + return rfcomm_send_frame(s, (void *) cmd, sizeof(*cmd), > HCI_PRIO_MAX); > > > > > > What's the idea here? Prioritize commands over data? But does this > really > > happen? Because we have only one queue to receive the data in L2CAP. > There > > is no separation between data and cmd there. > > > > Also, did you check if we can send RFCOMM commands and data out of > order? > > > > I really would like to rewrite l2cap-rfcomm iteraction before adding > new > > features here. > > lets just forget RFCOMM for now and make SO_PRIORITY setsockopt calls > return an error code. Priority on RFCOMM links is also rather pointless > since they all go via the same L2CAP PSM anyway. You would end up > prioritizing all RFCOMM connections over any other L2CAP connection. > > So if you try to prioritize HFP then you also prioritize PBAP in the > end > and we are back where we started. We could implement the 27.007 > priority > support inside RFCOMM, but that seems even more pointless endeavor. > > What we really want is prioritized L2CAP links and hopefully in the > future everything moves over to use L2CAP directly anyway and RFCOMM > will be slowly dying out. > > Regards > > Marcel Yep: One of the motivations for OBEX over L2CAP is to sort out the mess of the RFCOMM mux on top of the L2CAP mux. When OBEX profiles run over their own L2CAP channels (which can be separately prioritized), it will leave behind "only" HFP which would have almost exclusive use of RFCOMM (and of course PAN to displace DUN...) So, I agree: leave RFCOMM as is, and encourage OBEX over L2CAP implementations of OBEX profiles as a solution to prioritization. Tim ________________________________ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. ��.n��������+%������w��{.n�����{��� �^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
