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? 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
