discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] max capacity per USB channel


From: Eric Blossom
Subject: Re: [Discuss-gnuradio] max capacity per USB channel
Date: Mon, 9 Apr 2007 15:33:19 -0700
User-agent: Mutt/1.5.9i

On Mon, Apr 09, 2007 at 05:42:30PM -0400, George Nychis wrote:
> 
> 
> Eric Blossom wrote:
> >I think there's some confusion here.  When a user requests an rx or tx
> >channel with (cmd-allocate-channel invocation-handle
> >capacity-reservation), they are given a channel on an exclusive basis.
> >The returned channel number is given in the response-allocate-channel
> >message.
> >
> >When they send (cmd-deallocate-channel invocation-handle channel) the
> >server (after checking that this port actually _does_ own channel)
> >frees the channel and gives the associated capacity reservation back to
> >the pool.
> >
> >>So then is it required for the requester to keep track of how much they 
> >>requested to pass to our deallocation method?
> >
> >No, the server keeps track of how much it assigned to each rx and tx
> >channel.
> >
> >Does this make sense?
> 
> OK this is starting to make more sense now.  I just want to make sure I 
> have this 100%.
> 
> Heres a list of statements, tell me if any are false.
> 
> - Once a port owns a channel, no other ports can allocate capacity on it.

Yes.

> - If a channel allocates capacity on a channel, it can make another 
> capacity reservation request which can add additional capacity on to its 
> allocated channel through a second cmd-allocate-channel request.

To keep life simple, I'd say no.  If this turns out to be an issue, we
could add an 

  (adjust-capacity-reservation invocation-handle channel delta-capacity)

request.

> - When a deallocation method is called, the channel is specified and all of 
> the capacity reserved on the channel is free

Yes.

> and the channel is no longer exclusive.

It's no longer assigned to this port, and is available for reassignment


> Why not just check which channel the port owns and deallocate it when 
> receiving a cmd-deallocate-channel, rather than needing to pass the channel 
> parameter?

There's nothing stopping a given port from allocating more than one
channel ;)

Eric




reply via email to

[Prev in Thread] Current Thread [Next in Thread]