Linux bluetooth development
 help / color / mirror / Atom feed
From: "Tim Monahan-Mitchell" <tmonahan@codeaurora.org>
To: "Gustavo F. Padovan" <gustavo@padovan.org>
Cc: "Peter Krystad" <pkrystad@codeaurora.org>,
	"Kevin Hayes" <kevin@atheros.com>,
	"Marcel Holtmann" <marcel@holtmann.org>,
	"tmonahan@codeaurora.org" <tmonahan@codeaurora.org>,
	"David Vrabel" <david.vrabel@csr.com>,
	"Inga Stotland" <ingas@codeaurora.org>,
	"linux-bluetooth@vger.kernel.org"
	<linux-bluetooth@vger.kernel.org>,
	"rshaffer@codeaurora.org" <rshaffer@codeaurora.org>,
	"johan.hedberg@gmail.com" <johan.hedberg@gmail.com>
Subject: Re: Enhancements to allow l2cap channel to use either AMP or BR/EDR
Date: Tue, 3 Aug 2010 08:40:57 -0500 (CDT)	[thread overview]
Message-ID: <b93d3fcab246c34ed104129b0850495d.squirrel@www.codeaurora.org> (raw)
In-Reply-To: <20100803080719.GD20149@vigoh>

Hi, Gustavo and Marcel,

> Hi Peter,
>
> * Peter Krystad <pkrystad@codeaurora.org> [2010-08-02 18:30:34 -0700]:
>
>>
>> Hi Marcel and Kevin,
>>
>> >> >
>> >> > Agree that it should be done "in background" and that a size
>> >> threshold would be useful.  But who evaluates that threshold?  The
>> >> bluez kernel components, which essentially implement a transport
>> >> driver, should not be examining objects (files, phonebooks, etc) size
>> >> to see if this threshold is met.  Therefore, it would seem Tim's
>> >> suggestion of having the profile send a 'prefer_amp' bit would be
>> >> useful, right?
>> >>
>> >> I would do something like "prefer_amp when over 100kb" or something.
>> >> And
>> >> then the kernel needs to count. Meaning the L2CAP layer could easily
>> >> count this by itself.
>> >
>> > What?  Let's say the effect we want is that if the object is greater
>> > than, say, 10 megabytes, then we want to use AMP for the transfer.
>> > With your scheme, you want the kernel to count up to 10 megabytes,
>> > THEN switch over to AMP?
>> > No, you don't, he says rhetorically.  :)
>>
>> If the policy was defined as "prefer_amp after n seconds" we would get
>> the desired effect without having to do any counting in the kernel.
>
> In both cases we have to take in account the total size of the file, or
> the estimated time of transfer, so we can avoid to move to AMP when the
> transfer is about to end.

Right! Don't want to switch to AMP just to push those last 100 bytes :)

Since the kernel does not know the total object size to be transferred,
(right?), I've yet to come up with any 'threshold' ideas the kernel can
make. Note that the transfer could be one huge file or many small ones.

--
Tim Monahan-Mitchell
Employee of Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

  reply	other threads:[~2010-08-03 13:40 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-02 16:55 Enhancements to allow l2cap channel to use either AMP or BR/EDR tmonahan
2010-08-02 18:53 ` Marcel Holtmann
2010-08-02 22:41   ` Kevin Hayes
2010-08-02 22:58     ` Marcel Holtmann
2010-08-03  0:51       ` Kevin Hayes
     [not found]         ` <B7132A25476D334D9130FE7532F2A56310A0B08A61@SC1EXMB-MBCL.global.athero s.com>
2010-08-03  1:30           ` Peter Krystad
2010-08-03  1:59             ` Marcel Holtmann
2010-08-03  8:07             ` Gustavo F. Padovan
2010-08-03 13:40               ` Tim Monahan-Mitchell [this message]
2010-08-03  1:59         ` Marcel Holtmann
2010-08-03  4:47           ` Kevin Hayes
2010-08-03 12:59   ` David Vrabel
2010-08-03 16:14     ` Marcel Holtmann
  -- strict thread matches above, loose matches on Subject: below --
2010-07-30 18:30 Inga Stotland
2010-08-02 12:04 ` David Vrabel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b93d3fcab246c34ed104129b0850495d.squirrel@www.codeaurora.org \
    --to=tmonahan@codeaurora.org \
    --cc=david.vrabel@csr.com \
    --cc=gustavo@padovan.org \
    --cc=ingas@codeaurora.org \
    --cc=johan.hedberg@gmail.com \
    --cc=kevin@atheros.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=marcel@holtmann.org \
    --cc=pkrystad@codeaurora.org \
    --cc=rshaffer@codeaurora.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox