Hi Marcel, On 7/27/12, Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote: > Hi Manoj, > >> >> These patches allows L2CAP socket user to reserve bandwidth in >> >> percentage. Underlying socket reserves calculated number of >> >> HCI credits for this L2CAP channel. >> > >> > this description is by far not enough. Explain why you are doing this. >> > And make it a detailed description. Preferable with hcidump traces >> > showing why this makes a difference at all. >> > >> This patch simply adds an additional L2CAP socket option for reserving >> bandwidth. >> The reserved bandwidth would result into reserving calculated number >> of ACL data credits. Thus the L2CAP channels without this option set >> would not be able to use all available ACL buffers in controller. This >> would ensure that whenever an L2CAP channel with this option set has >> data to send, it does not starve or wait because of other channels >> already using all controller buffers. >> >> Above explanation is most suitable in case when simultaneous AVDTP >> streaming channels and other channels (e.g. OPP, PBAP etc) are in >> action. Such an arrangement for reserving credits would allow AVDTP >> stream to flow to controller without any obstacle from simultaneous >> traffic and help removing glitches in music streaming over Bluetooth. >> Please suggest if this description is sufficient and if I should push >> patch-set again. > > and what is the problem with using SO_PRIORITY for this? > One problem which I have faced using SO_PRIORITY is explained below. Suppose we have 2 links A & B and link A has higher priority than link B. And outgoing data transfer is active on both links. Now if device on link A goes far, there would be lot of failures and number of re-transmissions would increase for link A. Consequently at any time host would have significant number of packets for link A, getting accumulated due to poor quality of link.But since link A packets have higher priority, link B packets would suffer infinitely as long as link A packet queue in host is non-empty. Thus link B protocols may fail due to timers expiring and finally disconnection at upper layers. Second problem: We have two links similar to above scenario. Say link A is being used by AVDTP and link B is being used by OBEX. Host can come across a situation where all controller buffers are used by OBEX and AVDTP is waiting for a free buffer. Now due to some reason (e.g. distance) OBEX link B goes weak. This results into delay in transmission of OBEX packets already held by controller and consequently AVDTP packets also get delayed which causes glitches in music streaming and user experience goes bad. These are the basic problems which I have faced and hence felt necessity of a similar but different mechanism and came up with this solution. This solution fixes both of the problems explained above. Based on the explanation above your suggestion is required further. > Regards > > Marcel > > > Best regards, Manoj -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
