On Tue, Sep 02, 2014 at 04:04:14PM +0200, Daniel Mack wrote: > Hi Felipe, > > On 08/29/2014 10:46 PM, Felipe Balbi wrote: > > On Wed, Aug 27, 2014 at 07:09:03PM +0200, Daniel Mack wrote: > >> Restructure some code to make it easier to read. > >> > >> While at it, return -ENOMEM instead of -EINVAL if > >> usb_ep_alloc_request() fails, and omit the logging in such cases > >> (the mm core will complain loud enough). > >> > >> Signed-off-by: Daniel Mack <zonque@xxxxxxxxx> > >> --- > > > > does this depend on anything ? It doesn't apply to my testing/next > > > > The reason it doesn't apply is that you already applied v6 of my series > to your testing/next tree: > > > https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/commit/?h=testing/next&id=c52425b > > The currently pending discussion is about how to determine the size of > the packets sent down to the host, and it only affects the last patch in > the series. To summarize, here are the two approaches to do this: > > > 1) We pre-calculate a pattern of lengths which is then followed when > sending the packets. This is what Jassi implemented in his alternative > approach to my version here: > > http://www.spinics.net/lists/linux-usb/msg112913.html > > This idea comes at the price of storing the pre-calculated sequence and > track its state, which currently means adding 163 unsigned ints to the that's quite a lot :-) The version is this thread uses only 5 unsigned ints though. > device's private structs. This, however could be reduced by only storing > the pattern for the capture side and by using u8 or u16 instead of > unsigned int for the pattern store. I haven't yet tested this version, > though. > > 2) We keep track of the number of sent bytes and do an ad-hoc > determination on how big the next packet should be, each time we send > one to the host. This is what my v6 does, which you already have in your > tree. This comes at the price of storing and maintaining 5 unsigned ints > for keeping track of the current state and some pre-calculated numbers > (so we don't have to do that for every packet), plus some calculations > to be done for every packet. If we want to go for this solution, we > don't have to add any patch on top. > > So, ultimately, it's a matter of trade-off, memory footprint vs. > maintenance of 3 more state variables vs. some calculation done for each > of the packets (~1000 per second). > > I really don't feel like arguing over this much, but my impression is > that the currently applied version is more comprehensible, and the > overhead caused by the calculation is not measurable (we do a lot more > of such arithmetic in the snd-usb driver for each packet). > > So, decide for yourself which way to go, and let us know if you want any > further action to be taken. I like the version on this thread better and will keep it that way. thanks -- balbi
Attachment:
signature.asc
Description: Digital signature
