Hi Marcel, On 7/24/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. > Regards > > Marcel > > > -- > 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 > 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
