Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
Am Dienstag, 22. Mai 2007 17:23 schrieb Alan Stern: On Tue, 22 May 2007, Laurent Pinchart wrote: The usb_buffer_alloc name is misleading. Many USB driver developers believe it is a generic purpose buffer allocator. I'd like to change usb_buffer_alloc to make it a general purpose allocator. A parameter would tell the function to just allocate memory (default behaviour) or to allocate a DMA coherent mapping as well. We could even pass the URB pointer to the function to set the URB_TRANSFER_NO_DMA_MAP automatically (although usb_buffer_alloc can be used to allocate the setup buffer, so the API might have to be a little different). It would be simpler and less objectionable to just change the name of the routine. If it were called usb_alloc_coherent_DMA_buffer() then people wouldn't be tempted to think it was a general-purpose allocator. I thought a bit about this. Maybe there _is_ room for an allocator that will provide memory the HCD can get at, but without the full overhead of allocating a coherent buffer. Regards Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Wednesday 23 May 2007, Oliver Neukum wrote: I thought a bit about this. Maybe there _is_ room for an allocator that will provide memory the HCD can get at, but without the full overhead of allocating a coherent buffer. kmalloc() does exactly that... - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
Am Mittwoch, 23. Mai 2007 10:48 schrieb David Brownell: On Wednesday 23 May 2007, Oliver Neukum wrote: I thought a bit about this. Maybe there _is_ room for an allocator that will provide memory the HCD can get at, but without the full overhead of allocating a coherent buffer. kmalloc() does exactly that... How? It isn't passed the dma_mask. Regards Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
Am Montag, 21. Mai 2007 23:36 schrieb David Brownell:
On Monday 21 May 2007, Oliver Neukum wrote:
Am Mittwoch, 16. Mai 2007 16:41 schrieb David Brownell:
in that when you have
pre-allocated all buffers and all USB host controller descriptors, you
will
never get in the situation of not being able to allocate transfer
descriptors
on the fly, like done on Linux.
That's not a failure mode that's been often observed on Linux. (Never,
in my own experience... which I admit has not focussed on that particular
type of stress load.) So it's hard to argue that it should motivate a
redesign of core APIs.
We are seeing report of the networking stack exhausting the atomic
pool. They are rare these days, but do exist.
But transfer descriptors don't come from there.
Never, ever, even if the pool is exhausted?
static struct uhci_td *uhci_alloc_td(struct uhci_hcd *uhci)
{
dma_addr_t dma_handle;
struct uhci_td *td;
td = dma_pool_alloc(uhci-td_pool, GFP_ATOMIC, dma_handle);
if (!td)
return NULL;
Admittedly unlikely, but impossible?
Regards
Oliver
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
Am Dienstag, 22. Mai 2007 15:28 schrieb Laurent Pinchart: I'd like to change usb_buffer_alloc to make it a general purpose allocator. A parameter would tell the function to just allocate memory (default behaviour) Nope. What for? We avoid such flags if we can. If you need two version, create two functions. And before that, what's the advantage over kmalloc? Regards Oliver -- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) This signature is a legal requirement - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Friday 18 May 2007, David Brownell wrote: On Thursday 17 May 2007, Hans Petter Selasky wrote: Isn't that the job of usb_buffer_alloc(), to allocate memory in blocks of PAGE_SIZE bytes? Not at all. The size parameter is in bytes, and the utility code it calls goes to some lengths to *avoid* that kind of wastage. As they say: UTSL! The original reason to have such routines was to allocate small buffers for HID devices on systems where DMA map/unmap operations were absurdly expensive on such small buffers. (Think IOMMU ops across a slowish bus.) The usb_buffer_alloc name is misleading. Many USB driver developers believe it is a generic purpose buffer allocator. I'd like to change usb_buffer_alloc to make it a general purpose allocator. A parameter would tell the function to just allocate memory (default behaviour) or to allocate a DMA coherent mapping as well. We could even pass the URB pointer to the function to set the URB_TRANSFER_NO_DMA_MAP automatically (although usb_buffer_alloc can be used to allocate the setup buffer, so the API might have to be a little different). Is it right understood that the Linux USB stack does currently not use scatter and gathering? To me it seems like that, hence in the URB Linux only has a single DMA address value. Let me guess -- you didn't read my response on that topic ... ? Laurent Pinchart - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Tue, 22 May 2007, Laurent Pinchart wrote: The usb_buffer_alloc name is misleading. Many USB driver developers believe it is a generic purpose buffer allocator. I'd like to change usb_buffer_alloc to make it a general purpose allocator. A parameter would tell the function to just allocate memory (default behaviour) or to allocate a DMA coherent mapping as well. We could even pass the URB pointer to the function to set the URB_TRANSFER_NO_DMA_MAP automatically (although usb_buffer_alloc can be used to allocate the setup buffer, so the API might have to be a little different). It would be simpler and less objectionable to just change the name of the routine. If it were called usb_alloc_coherent_DMA_buffer() then people wouldn't be tempted to think it was a general-purpose allocator. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Tuesday 22 May 2007, Oliver Neukum wrote: Am Dienstag, 22. Mai 2007 15:28 schrieb Laurent Pinchart: I'd like to change usb_buffer_alloc to make it a general purpose allocator. A parameter would tell the function to just allocate memory (default behaviour) Nope. What for? We avoid such flags if we can. If you need two version, create two functions. Ok And before that, what's the advantage over kmalloc? Buffer allocation could then be fine-tuned using information that USB device drivers should care about. For instance, on systems with a PIO HCD, buffers could be vmalloc'ed. My idea was to have a general purpose URB buffer allocation function that all (most?) drivers could use, with flags (or another function) for specific cases. usb_buffer_alloc is currently used by some drivers when they should use kmalloc. The function is documented as a general purpose URB buffer allocator. Even if we fixed all drivers today to use kmalloc when they should, I'm pretty sure some new drivers will use usb_buffer_alloc. The alternative is to clearly document that URB buffer allocation should be done with kmalloc, and rename usb_buffer_alloc to usb_alloc_coherent_dma_buffer like Alan suggests. Even then some people might still use it when they shouldn't. Some USB drivers developers have no knowledge of DMA, and will just look around for anything that looks like a buffer allocator. Providing a general-purpose buffer allocator would in my opinion help avoiding those mistakes. Laurent Pinchart - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
Am Dienstag, 22. Mai 2007 18:10 schrieb Laurent Pinchart: My idea was to have a general purpose URB buffer allocation function that all (most?) drivers could use, with flags (or another function) for specific cases. usb_buffer_alloc is currently used by some drivers when they should use kmalloc. The function is documented as a general purpose URB buffer allocator. Even if we fixed all drivers today to use kmalloc when they should, I'm pretty sure some new drivers will use usb_buffer_alloc. We have an all purpose allocator for the whole kernel. It is called kmalloc. If you don't like that for psychological reason, rename the alternative. Regards Oliver -- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) This signature is a legal requirement - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
Am Donnerstag, 17. Mai 2007 20:39 schrieb Pete Zaitcev: I think we should remove those local_irq_save's, and leave just the guarantee that it won't be re-entered (currently such a guarantee is inherited from the Linux's interrupt handling, and we'll only need to make it explicit if any HCDs start using softirq when calling the giveback routine). I'm poking your memory in case there's actually a good reason for it which I forgot. If you do this 1. all drivers need to be audited for simple 'spin_lock()' 2. Doing so will make the common code path needlessly slower 3. If any HCD calls the callback from interrupt, you'll need to take a lock and disable interrupts anyway Regards Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
Am Mittwoch, 16. Mai 2007 20:43 schrieb Hans Petter Selasky: The lock that you are holding during submission is the same lock that is protecting the callback. Actually you can end up calling the __usbd_callback() prematurely in my new USB stack, but that is handled just fine, through some recurse bits: That code needs to be shot, staked through the heart, burned and buried in holy ground. If an operation fails, you return an error. What do you think happens if the callback tries to repair the error and fails to do so? Regards Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Monday 21 May 2007 13:37, Oliver Neukum wrote: Am Mittwoch, 16. Mai 2007 20:43 schrieb Hans Petter Selasky: The lock that you are holding during submission is the same lock that is protecting the callback. Actually you can end up calling the __usbd_callback() prematurely in my new USB stack, but that is handled just fine, through some recurse bits: That code needs to be shot, staked through the heart, burned and buried in holy ground. If an operation fails, you return an error. What do you think happens if the callback tries to repair the error and fails to do so? You have to back out and start some watchdog timer. Typically when you get an error you start the clear-stall transfer. If that fails you back out and rely on a watchdog timer to start the transfer again later. Of course this won't go into an infinite loop :-) --HPS - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
Am Mittwoch, 16. Mai 2007 19:38 schrieb Alan Stern: It doesn't save code. You need to check for the memory when you allocate it, no matter when that is done. Yes, but it is a difference doing it once at attach or doing it every time you start a transfer. Above you said it saves code. That is wrong. Not necessarily. Dealing with an allocation error in open() is much easier than dealing with a failure to resubmit an URB in a completion handler. Regards Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
Am Mittwoch, 16. Mai 2007 16:41 schrieb David Brownell: in that when you have pre-allocated all buffers and all USB host controller descriptors, you will never get in the situation of not being able to allocate transfer descriptors on the fly, like done on Linux. That's not a failure mode that's been often observed on Linux. (Never, in my own experience... which I admit has not focussed on that particular type of stress load.) So it's hard to argue that it should motivate a redesign of core APIs. We are seeing report of the networking stack exhausting the atomic pool. They are rare these days, but do exist. Transfer descriptors are an artifact of one kind of host controller; it'd be wrong to assume all HCDs use them. True. The related issue that's been discussed is how to shrink submit paths, giving lower overhead. The obvious way would be to shift more work into usb_alloc_urb() It would imply binding an URB to an endpoint at allocation. Regards Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
Am Mittwoch, 16. Mai 2007 19:33 schrieb Alan Stern: All devices need to allocate some memory, even if they are not used. That is just the way it is. If you want to save memory, then USB has the advantage that you can unplug the device and save resources. Of course all devices need memory. But there's a big difference between preallocating 4 KB and preallocating 512 KB. And if you start telling people they can save memory by unplugging their USB devices, they'll just laugh at you. Saving memory is the OS's job, not the user's. If this is the problem do the allocation in usb_alloc_urb(). This way a driver can choose to use preallocation by reusing URBs or not reusing them. In any case allocating a single data structure is faster than at a minimum two data structures. Regards Oliver - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Monday 21 May 2007, Oliver Neukum wrote: Am Mittwoch, 16. Mai 2007 16:41 schrieb David Brownell: in that when you have pre-allocated all buffers and all USB host controller descriptors, you will never get in the situation of not being able to allocate transfer descriptors on the fly, like done on Linux. That's not a failure mode that's been often observed on Linux. (Never, in my own experience... which I admit has not focussed on that particular type of stress load.) So it's hard to argue that it should motivate a redesign of core APIs. We are seeing report of the networking stack exhausting the atomic pool. They are rare these days, but do exist. But transfer descriptors don't come from there. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Thu, 17 May 2007 17:37:22 -0700, David Brownell [EMAIL PROTECTED] wrote: As it happens, USB callbacks cannot be interrupted. That's a somewhat artificial restriction; in theory there's no reason we couldn't allow interrupts. Do you remember why we're doing this? I did not touch that part since the attempt to keep usb-lock across the callback (read: years back). [...] I understand the points a-c above. The question is, why do we do local_irq_save across the URB callback? It seems to be completely non-functional. Where is that done? The HCDs just seem to call usb_hcd_giveback_urb() after dropping their internal spinlock (except the u132 one, which has always been kind of dubious and acts unmaintained). And that routine doesn't do a local_irq_save. Absolutely right, I'm being an idiot here. I think I looked at root hub code in the rush to the FreedomHEC preparations. We do not have local_irq_save in the giveback routine. So, when Alan wrote USB callbacks cannot be interrupted, he meant normal no-reentrancy guarantees, and not that the interrupts are disabled. -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Saturday 19 May 2007, Pete Zaitcev wrote: On Thu, 17 May 2007 17:37:22 -0700, David Brownell [EMAIL PROTECTED] wrote: As it happens, USB callbacks cannot be interrupted. That's a somewhat artificial restriction; in theory there's no reason we couldn't allow interrupts. Do you remember why we're doing this? I did not touch that part since the attempt to keep usb-lock across the callback (read: years back). [...] I understand the points a-c above. The question is, why do we do local_irq_save across the URB callback? It seems to be completely non-functional. Where is that done? The HCDs just seem to call usb_hcd_giveback_urb() after dropping their internal spinlock (except the u132 one, which has always been kind of dubious and acts unmaintained). And that routine doesn't do a local_irq_save. Absolutely right, I'm being an idiot here. I think I looked at root hub code in the rush to the FreedomHEC preparations. We do not have local_irq_save in the giveback routine. So, when Alan wrote USB callbacks cannot be interrupted, he meant normal no-reentrancy guarantees, and not that the interrupts are disabled. And by normal no-reentrancy you mean the normal guarantee that each IRQ handler won't be re-entered while it's running. I observe that we don't register PCI IRQ handlers with IRQF_DISABLED, so it's possible that some *other* IRQ happens while it's running; but most of the non-PCI irq handlers are registered with that flag set. That seems potentially buglike to me; it's legit for any IRQ handler to submit an URB. Which would then cause them to try grabbing the spinlock held by the HCD's IRQ handler, if that other IRQ handler happened to fire when the HCD's IRQ handler was running. So maybe we should always register with IRQF_DISABLED, unattractive though that could be in terms of latencies ... or, somehow try to define a rule whereby URBs can't be submitted in certain IRQ contexts. - Dave - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Sat, 19 May 2007, David Brownell wrote: Absolutely right, I'm being an idiot here. I think I looked at root hub code in the rush to the FreedomHEC preparations. We do not have local_irq_save in the giveback routine. So, when Alan wrote USB callbacks cannot be interrupted, he meant normal no-reentrancy guarantees, and not that the interrupts are disabled. No, I really meant that interrupts are disabled. It's possible that I was wrong... And by normal no-reentrancy you mean the normal guarantee that each IRQ handler won't be re-entered while it's running. I observe that we don't register PCI IRQ handlers with IRQF_DISABLED, so it's possible that some *other* IRQ happens while it's running; but most of the non-PCI irq handlers are registered with that flag set. That seems potentially buglike to me; it's legit for any IRQ handler to submit an URB. Which would then cause them to try grabbing the spinlock held by the HCD's IRQ handler, if that other IRQ handler happened to fire when the HCD's IRQ handler was running. So maybe we should always register with IRQF_DISABLED, unattractive though that could be in terms of latencies ... or, somehow try to define a rule whereby URBs can't be submitted in certain IRQ contexts. Or better still, always acquire the HCD's spinlock with spin_lock_irqsave(). That's what uhci-hcd does, even though ehci-hcd and ohci-hcd don't. Of course, if we don't use IRQF_DISABLED then we would have to verify that none of the callbacks rely on interrupts being disabled. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Saturday 19 May 2007, Alan Stern wrote: On Sat, 19 May 2007, David Brownell wrote: Absolutely right, I'm being an idiot here. I think I looked at root hub code in the rush to the FreedomHEC preparations. We do not have local_irq_save in the giveback routine. So, when Alan wrote USB callbacks cannot be interrupted, he meant normal no-reentrancy guarantees, and not that the interrupts are disabled. No, I really meant that interrupts are disabled. It's possible that I was wrong... And by normal no-reentrancy you mean the normal guarantee that each IRQ handler won't be re-entered while it's running. I observe that we don't register PCI IRQ handlers with IRQF_DISABLED, so it's possible that some *other* IRQ happens while it's running; but most of the non-PCI irq handlers are registered with that flag set. That seems potentially buglike to me; it's legit for any IRQ handler to submit an URB. Which would then cause them to try grabbing the spinlock held by the HCD's IRQ handler, if that other IRQ handler happened to fire when the HCD's IRQ handler was running. So maybe we should always register with IRQF_DISABLED, unattractive though that could be in terms of latencies ... or, somehow try to define a rule whereby URBs can't be submitted in certain IRQ contexts. Or better still, always acquire the HCD's spinlock with spin_lock_irqsave(). That's what uhci-hcd does, even though ehci-hcd and ohci-hcd don't. That's because they were written to assume IRQF_DISABLED was set. I don't know when that irq request mode was changed. Of course, if we don't use IRQF_DISABLED then we would have to verify that none of the callbacks rely on interrupts being disabled. AFAIK they've always been allowed to assume that. - Dave - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
Hi, If you are interested, the files are: http://www.turbocat.net/~hselasky/isdn4bsd/sources/src/sys/dev/usb/usb_compat_linux.c http://www.turbocat.net/~hselasky/isdn4bsd/sources/src/sys/dev/usb/usb_compat_linux.h It is almost finished now. And it is not very much code. --HPS - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Fri, 18 May 2007, Hans Petter Selasky wrote: Hi, If you are interested, the files are: http://www.turbocat.net/~hselasky/isdn4bsd/sources/src/sys/dev/usb/usb_compat_linux.c http://www.turbocat.net/~hselasky/isdn4bsd/sources/src/sys/dev/usb/usb_compat_linux.h It is almost finished now. And it is not very much code. It occurred to me last night that you could accomplish what you want without any change to the Linux drivers at all. Just change the FreeBSD stack so that it preallocates one or two transfers for every endpoint at the time the endpoint is enabled -- that is, whenever the stack sends a Set-Configuration or Set-Interface request. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Friday 18 May 2007 16:26, Alan Stern wrote: On Fri, 18 May 2007, Hans Petter Selasky wrote: Hi, If you are interested, the files are: http://www.turbocat.net/~hselasky/isdn4bsd/sources/src/sys/dev/usb/usb_co mpat_linux.c http://www.turbocat.net/~hselasky/isdn4bsd/sources/src/sys/dev/usb/usb_co mpat_linux.h It is almost finished now. And it is not very much code. It occurred to me last night that you could accomplish what you want without any change to the Linux drivers at all. Just change the FreeBSD stack so that it preallocates one or two transfers for every endpoint at the time the endpoint is enabled -- that is, whenever the stack sends a Set-Configuration or Set-Interface request. That is correct. But where do I get information about the buffer-size to use? Choosing the wrong buffer size can limit performance or waste memory. --HPS - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Fri, 18 May 2007, Hans Petter Selasky wrote: It occurred to me last night that you could accomplish what you want without any change to the Linux drivers at all. Just change the FreeBSD stack so that it preallocates one or two transfers for every endpoint at the time the endpoint is enabled -- that is, whenever the stack sends a Set-Configuration or Set-Interface request. That is correct. But where do I get information about the buffer-size to use? Choosing the wrong buffer size can limit performance or waste memory. Yes, that is a problem. It's made even worse by the fact that the drivers themselves frequently do not know in advance the buffer sizes they will use. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
Hi, On Thursday 17 May 2007 06:38, David Brownell wrote: On Wednesday 16 May 2007, Hans Petter Selasky wrote: Hi, On Wednesday 16 May 2007 20:20, David Brownell wrote: URB submission has other failure possibilities than lack of memory. Those other things have to be checked for regardless. Yes, but that is because you allow too many parameters in the URB to be changed between USB transfers. No; it's because unforeseen events can occur. For example, the device may have been unplugged or suspended. On FreeBSD it will never happen that you call the equivalent of usb_submit_urb() after that the device has detached! It must be something terribly wrong in the Linux USB stack if the callbacks are alive after that you have detached a USB device. How does that work then ... driver must grab a lock, check whether the device has disconnected, then submit the request and drop the lock? Sounds like needless slowdowns. Each USB device has its own lock. There are some tricks there. 1) usbd_transfer_start() is always called like this: usbd_transfer_start(sc-sc_xfer[x]); 2) sc-sc_xfer[x] is set to zero at detach holding the private lock of the USB device driver. All subsequent calls to usbd_transfer_start(), if any, will fail. So there's a race on SMP, where sc-sc_xfer[x] may be referenced on one CPU while another is nulling it. The lock you showed is inside usbd_transfer_start(), where it can't do any good. It is an assert statement. The priv_mtx lock must be locked before you call usbd_transfer_start(). There is no race on SMP. 3) usbd_transfer_start() is always non-blocking. In other words a single lock is held across the call. Like usb_submit_urb() then, except that the disconnect race is handled by being buggy rather than by reporting a fault at submit time... Ok. ... Because if there's no lock against async disconnect events, then it's trivial to have the disconnect logic underway on one CPU while another CPU does real work, submitting an I/O request. We solve this in one of two ways: 1) Using a mutex. At detach we lock the mutex stopping all transfers. 2) Using a thread. At detach we teardown and wait for the thread to exit. But there's that race above, so it's not solved. If you need to do Async stuff, then you have to do it in a separate thread or in a so-called task-queue. Else you are in for great trouble! That was the big sin in the old USB stack on FreeBSD: Calling synchronous USB callbacks from everywhere, like ioctl/read/write - callbacks. Is that a problem on Linux also? On Linux I see no locks used in the USB drivers, so they are solely protected by interrupt-level mechanisms. My rule is that: Synchronous or blocking calls _must_ happen in a config thread that you can wait for. Else asynchronous calls on pre-allocated transfers can happen anywhere. The problem clearly appears on Linux SMP because: a) No locks are in the USB drivers (then they must be all so-called Giant locked) b) You don't pre-allocate transfers, resulting in synchronous/blocking calls everywhere, and no-one thinks about what can happen then :-) --HPS - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On FreeBSD it will never happen that you call the equivalent of usb_submit_urb() after that the device has detached! It must be something terribly wrong in the Linux USB stack if the callbacks are alive after that you have detached a USB device. How does that work then ... driver must grab a lock, check whether the device has disconnected, then submit the request and drop the lock? Sounds like needless slowdowns. Each USB device has its own lock. There are some tricks there. ... So there's a race on SMP, where sc-sc_xfer[x] may be referenced on one CPU while another is nulling it. The lock you showed is inside usbd_transfer_start(), where it can't do any good. It is an assert statement. The priv_mtx lock must be locked before you call usbd_transfer_start(). There is no race on SMP. I see; I was expecting a response like yes, driver must grab lock and that step was omitted from your response. If you need to do Async stuff, then you have to do it in a separate thread or in a so-called task-queue. Else you are in for great trouble! That was the big sin in the old USB stack on FreeBSD: Calling synchronous USB callbacks from everywhere, like ioctl/read/write - callbacks. Is that a problem on Linux also? All callbacks are async. At one point there were some bugs associated with callers that accidentally placed racey restrictions on when the callbacks could occur -- i.e. expected them at some point after a call returned, rather than any point after the call was issued -- but such bugs seem to be largely fixed now. (Hard to be sure though.) On Linux I see no locks used in the USB drivers, Look again, then! Driver-private locks are all over the place. so they are solely protected by interrupt-level mechanisms. Maybe you mean caller-transparent mechanisms? Synchronous calls use mutexes (or for old code, semaphores) internally. Async ones use spinlocks. My rule is that: Synchronous or blocking calls _must_ happen in a config thread that you can wait for. Else asynchronous calls on pre-allocated transfers can happen anywhere. Well *obviously* blocking calls require a schedulable context, and others don't. We don't restrict things to config threads. The problem clearly appears on Linux SMP because: a) No locks are in the USB drivers (then they must be all so-called Giant locked) Nope; I don't have an idea why you overlook all the mutex and spinlock calls in the drivers. There's the legacy big kernel lock but not much uses that any more. b) You don't pre-allocate transfers, resulting in synchronous/blocking calls everywhere, and no-one thinks about what can happen then :-) You should learn more about the stack before making such sweeping (and wrong) statements. - Dave - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Thu, 17 May 2007, Hans Petter Selasky wrote: If you need to do Async stuff, then you have to do it in a separate thread or in a so-called task-queue. Else you are in for great trouble! That was the big sin in the old USB stack on FreeBSD: Calling synchronous USB callbacks from everywhere, like ioctl/read/write - callbacks. Is that a problem on Linux also? It's hard to answer; your use of terminology is peculiar. The word synchronous does not mean capable of blocking; it means that the routine waits until a result is received. It is not directly related to whether the routine runs in a process context (which can sleep) vs. an atomic context (one which isn't allowed to sleep). Referring to a callback as synchronous doesn't make sense. A callback doesn't send a message -- it _receives_ a message -- and hence it doesn't need to wait for any result. In Linux, the USB callbacks are generally atomic. Does that answer your question? On Linux I see no locks used in the USB drivers, so they are solely protected by interrupt-level mechanisms. That's an awfully strange thing to say. No locks used in the USB drivers? Good lord, they are full of locks! Semaphores, mutexes, spinlocks -- you name it, it's in there. My rule is that: Synchronous or blocking calls _must_ happen in a config thread that you can wait for. Else asynchronous calls on pre-allocated transfers can happen anywhere. What distinguishes a config thread from any other kind of thread? What distingishes threads you can wait for from threads you can't wait for? What's wrong with a config thread that you can't wait for making a blocking call? Who cares if you can't wait for it? -- the thread will still carry out the call okay. The problem clearly appears on Linux SMP because: What problem? Or should I say, Which problem? a) No locks are in the USB drivers (then they must be all so-called Giant locked) You must be living in some sort of fantasy land if you really believe this. Or else you're looking at a version of Linux from 8 years ago. b) You don't pre-allocate transfers, resulting in synchronous/blocking calls everywhere, and no-one thinks about what can happen then :-) Your reasoning is illogical. Why does allocation have to be blocking? In code paths which can't block, we do non-blocking late allocation. And we do think about what can happen. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Thursday 17 May 2007 16:35, Alan Stern wrote: On Thu, 17 May 2007, Hans Petter Selasky wrote: If you need to do Async stuff, then you have to do it in a separate thread or in a so-called task-queue. Else you are in for great trouble! That was the big sin in the old USB stack on FreeBSD: Calling synchronous USB callbacks from everywhere, like ioctl/read/write - callbacks. Is that a problem on Linux also? It's hard to answer; your use of terminology is peculiar. The word synchronous does not mean capable of blocking; it means that the routine waits until a result is received. It is not directly related to whether the routine runs in a process context (which can sleep) vs. an atomic context (one which isn't allowed to sleep). I meant blocking USB transfers, there. For example when you want to do a control transfer and wait for it to finish. Referring to a callback as synchronous doesn't make sense. A callback doesn't send a message -- it _receives_ a message -- and hence it doesn't need to wait for any result. Right. In Linux, the USB callbacks are generally atomic. Does that answer your question? Yes. So you protect the callback with a lock to make it atomic? On Linux I see no locks used in the USB drivers, so they are solely protected by interrupt-level mechanisms. That's an awfully strange thing to say. No locks used in the USB drivers? Good lord, they are full of locks! Semaphores, mutexes, spinlocks -- you name it, it's in there. Ok, Ok. I'm not the Linux expert. My rule is that: Synchronous or blocking calls _must_ happen in a config thread that you can wait for. Else asynchronous calls on pre-allocated transfers can happen anywhere. What distinguishes a config thread from any other kind of thread? What distingishes threads you can wait for from threads you can't wait for? What's wrong with a config thread that you can't wait for making a blocking call? Who cares if you can't wait for it? -- the thread will still carry out the call okay. You can use any thread you like, as long as you make sure it is gone before the detach routine of the USB device in question returns. The problem clearly appears on Linux SMP because: What problem? Or should I say, Which problem? a) No locks are in the USB drivers (then they must be all so-called Giant locked) You must be living in some sort of fantasy land if you really believe this. Or else you're looking at a version of Linux from 8 years ago. b) You don't pre-allocate transfers, resulting in synchronous/blocking calls everywhere, and no-one thinks about what can happen then :-) Your reasoning is illogical. Why does allocation have to be blocking? Memory allocation is blocking in that way it might have to flush out memory pages to a harddisk, before those pages can be allocated by something in the kernel. Of course there exists no-wait options that you can pass to malloc, but I wouldn't rely too much on those flags unless you are allocating from a pre-defined memory pool, where you know that there is memory reserved for you. In code paths which can't block, we do non-blocking late allocation. And we do think about what can happen. Good. --HPS - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Thursday 17 May 2007 16:20, David Brownell wrote: On FreeBSD it will never happen that you call the equivalent of usb_submit_urb() after that the device has detached! It must be something terribly wrong in the Linux USB stack if the callbacks are alive after that you have detached a USB device. How does that work then ... driver must grab a lock, check whether the device has disconnected, then submit the request and drop the lock? Sounds like needless slowdowns. Each USB device has its own lock. There are some tricks there. ... So there's a race on SMP, where sc-sc_xfer[x] may be referenced on one CPU while another is nulling it. The lock you showed is inside usbd_transfer_start(), where it can't do any good. It is an assert statement. The priv_mtx lock must be locked before you call usbd_transfer_start(). There is no race on SMP. I see; I was expecting a response like yes, driver must grab lock and that step was omitted from your response. If you need to do Async stuff, then you have to do it in a separate thread or in a so-called task-queue. Else you are in for great trouble! That was the big sin in the old USB stack on FreeBSD: Calling synchronous USB callbacks from everywhere, like ioctl/read/write - callbacks. Is that a problem on Linux also? All callbacks are async. At one point there were some bugs associated with callers that accidentally placed racey restrictions on when the callbacks could occur -- i.e. expected them at some point after a call returned, rather than any point after the call was issued -- but such bugs seem to be largely fixed now. (Hard to be sure though.) On Linux I see no locks used in the USB drivers, Look again, then! Driver-private locks are all over the place. so they are solely protected by interrupt-level mechanisms. Maybe you mean caller-transparent mechanisms? Synchronous calls use mutexes (or for old code, semaphores) internally. Async ones use spinlocks. My rule is that: Synchronous or blocking calls _must_ happen in a config thread that you can wait for. Else asynchronous calls on pre-allocated transfers can happen anywhere. Well *obviously* blocking calls require a schedulable context, and others don't. We don't restrict things to config threads. The problem clearly appears on Linux SMP because: a) No locks are in the USB drivers (then they must be all so-called Giant locked) Nope; I don't have an idea why you overlook all the mutex and spinlock calls in the drivers. There's the legacy big kernel lock but not much uses that any more. b) You don't pre-allocate transfers, resulting in synchronous/blocking calls everywhere, and no-one thinks about what can happen then :-) You should learn more about the stack before making such sweeping (and wrong) statements. Ok, thanks for clearing it up. You obviously know more about the Linux USB stack than I do. In between: I would like introduce a new USB API call, so that my pre-allocate model will work better with your USB API. For example I want something like this: void usb_setup_endpoint(struct usb_device *usb, struct usb_interface *ui, struct usb_host_endpoint *uhe, uint32_t bufsize, uint32_t unused0, uint32_t unused1, uint32_t unused2); On FreeBSD this function will pre-allocate one or two USB transfers for an endpoint using the given bufsize argument. Those FreeBSD USB transfers will then be used to do all the Linux USB transfers. This function can block and must have a context. On linux you will probably use uint32_t uhe, hence I will do it like this: struct usb_host_endpoint * usb_find_host_endpoint(struct usb_device *dev, uint8_t type, uint8_t dir); #define usb_sndctrlpipe(dev,endpoint) \ usb_find_host_endpoint(dev, PIPE_CONTROL, (endpoint) | USB_DIR_OUT) Whether usb_sndctrlpipe() returns a pointer or uint32_t, will be hidden to the USB device drivers. What do you think? --HPS - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Thu, 17 May 2007, Hans Petter Selasky wrote: In Linux, the USB callbacks are generally atomic. Does that answer your question? Yes. So you protect the callback with a lock to make it atomic? No, you don't understand. The callback is atomic because it is not allowed to sleep. That's what atomic means. It has nothing to do with locking or protection. b) You don't pre-allocate transfers, resulting in synchronous/blocking calls everywhere, and no-one thinks about what can happen then :-) Your reasoning is illogical. Why does allocation have to be blocking? Memory allocation is blocking in that way it might have to flush out memory pages to a harddisk, before those pages can be allocated by something in the kernel. Of course there exists no-wait options that you can pass to malloc, but I wouldn't rely too much on those flags You _can_ rely on the no-wait option to prevent the allocation from sleeping or flushing pages to a disk... unless you are allocating from a pre-defined memory pool, where you know that there is memory reserved for you. ... and you can't rely on no-wait to succeed unless, as you say, you already know there is memory available. But that's also true for early, blocking allocations; there's nothing special about late, non-blocking malloc. With pre-allocation you might fail at the beginning, and with late allocation you might fail in the middle. Either way, you fail. So what's the big deal? Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Thursday 17 May 2007, Hans Petter Selasky wrote: I would like introduce a new USB API call, so that my pre-allocate model will work better with your USB API. For example I want something like this: void usb_setup_endpoint(struct usb_device *usb, struct usb_interface *ui, struct usb_host_endpoint *uhe, uint32_t bufsize, uint32_t unused0, uint32_t unused1, uint32_t unused2); The usb_device and usb_interface are implied by the usb_host_endpoint, and unused parameters are pointless. Sizes are size_t, and such a call could obviously fail because of invalid parameters. So int usb_setup_endpoint(struct usb_host_endpoint *hep, size_t bufsize); What would such a call do, though? Who would use it, and why? On FreeBSD this function will pre-allocate one or two USB transfers for an endpoint using the given bufsize argument. Those FreeBSD USB transfers will then be used to do all the Linux USB transfers. This function can block and must have a context. So what's the model ... GPL'd Linux drivers will be modified to incorporate that call, so they'd work better on FreeBSD? - Dave - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
Hi, On Thursday 17 May 2007 19:03, Alan Stern wrote: On Thu, 17 May 2007, Hans Petter Selasky wrote: In Linux, the USB callbacks are generally atomic. Does that answer your question? Yes. So you protect the callback with a lock to make it atomic? No, you don't understand. The callback is atomic because it is not allowed to sleep. That's what atomic means. It has nothing to do with locking or protection. And it cannot be interrupted either? b) You don't pre-allocate transfers, resulting in synchronous/blocking calls everywhere, and no-one thinks about what can happen then :-) Your reasoning is illogical. Why does allocation have to be blocking? Memory allocation is blocking in that way it might have to flush out memory pages to a harddisk, before those pages can be allocated by something in the kernel. Of course there exists no-wait options that you can pass to malloc, but I wouldn't rely too much on those flags You _can_ rely on the no-wait option to prevent the allocation from sleeping or flushing pages to a disk... unless you are allocating from a pre-defined memory pool, where you know that there is memory reserved for you. ... and you can't rely on no-wait to succeed unless, as you say, you already know there is memory available. But that's also true for early, blocking allocations; there's nothing special about late, non-blocking malloc. With pre-allocation you might fail at the beginning, and with late allocation you might fail in the middle. Either way, you fail. So what's the big deal? There is a greater chance of successing with pre-allocation if you use the wait flag when you malloc? Right? --HPS - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Thu, 17 May 2007 10:44:13 -0700, David Brownell [EMAIL PROTECTED] wrote: So what's the model ... GPL'd Linux drivers will be modified to incorporate that call, so they'd work better on FreeBSD? I thought that we ignored this on purpose and talking about the licensing so deeply in the thread is too late. What have we spent all this energy for up to this point? It was clear from the start that the model is exactly what you surmised. It's a fact of life that BSDs steal Linux code and slap their own copyright and licensing on it. The story of OpenBSD and the Broadcom wireless was just the latest example. However, we cannot preclude them doing this, and least of all by pretending that they'd stop if we ask nicely. I chose to not discuss this up to this point and take the best from Hans' independent insight, because this way I (as a kernel hacker) receive at least some benefit. If I turned Hans away right off the bat, his cohorts would still do the same thing, only without talking to us. That would be a net loss for Linux. -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Thu, 17 May 2007, Hans Petter Selasky wrote: Hi, On Thursday 17 May 2007 19:03, Alan Stern wrote: On Thu, 17 May 2007, Hans Petter Selasky wrote: In Linux, the USB callbacks are generally atomic. Does that answer your question? Yes. So you protect the callback with a lock to make it atomic? No, you don't understand. The callback is atomic because it is not allowed to sleep. That's what atomic means. It has nothing to do with locking or protection. And it cannot be interrupted either? Some atomic routines can be interrupted and some can't. If an interrupt does occur then the interrupt handler is also atomic (by definition), so no problem will arise. As it happens, USB callbacks cannot be interrupted. That's a somewhat artificial restriction; in theory there's no reason we couldn't allow interrupts. With pre-allocation you might fail at the beginning, and with late allocation you might fail in the middle. Either way, you fail. So what's the big deal? There is a greater chance of successing with pre-allocation if you use the wait flag when you malloc? Right? Certainly. But turn it around: With pre-allocation you force other parts of the system to have a higher chance of failing, because you already own the memory they want (even though you may not be using it). Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Thursday 17 May 2007 19:44, David Brownell wrote:
On Thursday 17 May 2007, Hans Petter Selasky wrote:
I would like introduce a new USB API call, so that my pre-allocate model
will work better with your USB API. For example I want something like
this:
void
usb_setup_endpoint(struct usb_device *usb, struct usb_interface *ui,
struct usb_host_endpoint *uhe, uint32_t bufsize, uint32_t unused0,
uint32_t unused1, uint32_t unused2);
The usb_device and usb_interface are implied by the usb_host_endpoint,
and unused parameters are pointless. Sizes are size_t, and such
a call could obviously fail because of invalid parameters. So
int usb_setup_endpoint(struct usb_host_endpoint *hep, size_t bufsize);
To save the hep to struct usb_device pointer, I would like to have struct
usb_device *dev as an argument.
What would such a call do, though? Who would use it, and why?
The call will setup one or two pre-allocated USB transfers for the emulation
layer between the Linux USB stack and the FreeBSD USB stack.
I've currently put the following into this function:
int32_t
usb_setup_endpoint(struct usb_device *dev, struct usb_host_endpoint *uhe,
uint32_t bufsize)
{
struct usbd_config cfg[2];
uint16_t mfs = usbd_get_max_frame_size((usb_endpoint_descriptor_t
*)(uhe-desc));
uint8_t type = uhe-desc.bmAttributes UE_XFERTYPE;
uint8_t addr = uhe-desc.bEndpointAddress;
usbd_transfer_unsetup(uhe-bsd_xfer, 2);
if (bufsize == 0) {
return 0;
}
bzero(cfg, sizeof(cfg));
if (type == UE_ISOCHRONOUS) {
/* Isochronous is special */
cfg[0].type = type;
cfg[0].endpoint = addr UE_ADDR;
cfg[0].direction = addr (UE_DIR_OUT|UE_DIR_IN);
cfg[0].callback = usb_linux_isoc_callback;
cfg[0].bufsize = 0; /* use wMaxPacketSize */
bcopy(cfg + 0, cfg + 1, sizeof(*cfg));
if (usbd_transfer_setup(dev-bsd_udev, uhe-bsd_iface_index,
uhe-bsd_xfer, cfg, 2, uhe,
usb_global_lock))
{
return -EINVAL;
}
} else {
if (bufsize (1 22)) {
/* limit buffer size */
bufsize = (1 22);
}
if (type == UE_CONTROL) {
/* we need enough room for the control header */
if (bufsize sizeof(usb_device_request_t)) {
bufsize = sizeof(usb_device_request_t);
}
}
if (bufsize mfs) {
/* we need to be able to hold at least one frame! */
bufsize = mfs;
}
cfg[0].type = type;
cfg[0].endpoint = addr UE_ADDR;
cfg[0].direction = addr (UE_DIR_OUT|UE_DIR_IN);
cfg[0].callback = usb_linux_non_isoc_callback;
cfg[0].bufsize = bufsize;
if (usbd_transfer_setup(dev-bsd_udev, uhe-bsd_iface_index,
uhe-bsd_xfer, cfg, 1, uhe,
usb_global_lock))
{
return -EINVAL;
}
}
return 0;
}
The reason for this is to allow Linux USB drivers to tell the FreeBSD USB
stack that they want larger/smaller buffers.
On Linux this information can be used to reserve EHCI/UHCI/OHCI USB transfer
descriptors.
On FreeBSD this function will pre-allocate one or two USB transfers for
an endpoint using the given bufsize argument. Those FreeBSD USB
transfers will then be used to do all the Linux USB transfers. This
function can block and must have a context.
So what's the model ... GPL'd Linux drivers will be modified to
incorporate that call, so they'd work better on FreeBSD?
Yes, and under Linux.
As you can see, it is not possible to emulate an on-the-fly allocation model
by a pre-allocation model. That's why I suggest this API addition.
--HPS
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Thu, 17 May 2007 14:26:18 -0400 (EDT), Alan Stern [EMAIL PROTECTED] wrote: As it happens, USB callbacks cannot be interrupted. That's a somewhat artificial restriction; in theory there's no reason we couldn't allow interrupts. Do you remember why we're doing this? I did not touch that part since the attempt to keep usb-lock across the callback (read: years back). I think we should remove those local_irq_save's, and leave just the guarantee that it won't be re-entered (currently such a guarantee is inherited from the Linux's interrupt handling, and we'll only need to make it explicit if any HCDs start using softirq when calling the giveback routine). I'm poking your memory in case there's actually a good reason for it which I forgot. Yours, -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Thursday 17 May 2007 20:19, Pete Zaitcev wrote: On Thu, 17 May 2007 10:44:13 -0700, David Brownell [EMAIL PROTECTED] wrote: So what's the model ... GPL'd Linux drivers will be modified to incorporate that call, so they'd work better on FreeBSD? I thought that we ignored this on purpose and talking about the licensing so deeply in the thread is too late. What have we spent all this energy for up to this point? It was clear from the start that the model is exactly what you surmised. It's a fact of life that BSDs steal Linux code and slap their own copyright and licensing on it. The story of OpenBSD and the Broadcom wireless was just the latest example. However, we cannot preclude them doing this, and least of all by pretending that they'd stop if we ask nicely. I chose to not discuss this up to this point and take the best from Hans' independent insight, because this way I (as a kernel hacker) receive at least some benefit. If I turned Hans away right off the bat, his cohorts would still do the same thing, only without talking to us. That would be a net loss for Linux. This sound like well known theory: Do towards others what you want them to do towards you. I'm just giving my enemies food ;-) MODULE_LICENSE(Dual BSD/GPL); If the open-source world could unite on a common USB stack in the kernel, that would be a win for all. --HPS - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Thu, 17 May 2007, Pete Zaitcev wrote: On Thu, 17 May 2007 14:26:18 -0400 (EDT), Alan Stern [EMAIL PROTECTED] wrote: As it happens, USB callbacks cannot be interrupted. That's a somewhat artificial restriction; in theory there's no reason we couldn't allow interrupts. Do you remember why we're doing this? I did not touch that part since the attempt to keep usb-lock across the callback (read: years back). I think it's pretty much just legacy. Nobody wants to audit all the callback routines to see which ones really need interrupts to be disabled. I think we should remove those local_irq_save's, and leave just the guarantee that it won't be re-entered (currently such a guarantee is inherited from the Linux's interrupt handling, and we'll only need to make it explicit if any HCDs start using softirq when calling the giveback routine). I'm poking your memory in case there's actually a good reason for it which I forgot. None that I can recall. Even without the interrupt handling guarantee, the HCDs are (or should be) written so that callbacks won't occur recursively. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Thursday 17 May 2007, Pete Zaitcev wrote: On Thu, 17 May 2007 14:26:18 -0400 (EDT), Alan Stern [EMAIL PROTECTED] wrote: As it happens, USB callbacks cannot be interrupted. That's a somewhat artificial restriction; in theory there's no reason we couldn't allow interrupts. Do you remember why we're doing this? I did not touch that part since the attempt to keep usb-lock across the callback (read: years back). HCDs have, for historical reasons, issued URB completions in their IRQ handlers. In order to do that correctly -- since completion handlers need to be able to submit URBs -- that must be done while (a) dropping the HCD's internal spinlock, but also (b) not re-enabling the HCD's IRQ, and a bit more subtly (c) ensuring certain HCD-internal state doesn't change until after the completion returns. Examples of (c) being the release of some reserved periodic bandwidth, or cleanup then re-enabling a halted bulk queue. - Dave - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Thursday 17 May 2007, Pete Zaitcev wrote: On Thu, 17 May 2007 10:44:13 -0700, David Brownell [EMAIL PROTECTED] wrote: So what's the model ... GPL'd Linux drivers will be modified to incorporate that call, so they'd work better on FreeBSD? I thought that we ignored this on purpose and talking about the licensing so deeply in the thread is too late. What have we spent all this energy for up to this point? It was clear from the start that the model is exactly what you surmised. Not entirely. Would those drivers be forked into a BSD distro? Would Linux be expected to merge those changes? Or alternatively: just clone the Linux stack sufficiently well that new BSD-licensed drivers could be written, which would run on both systems. - Dave - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Thursday 17 May 2007, Hans Petter Selasky wrote: On Thursday 17 May 2007 19:44, David Brownell wrote: On Thursday 17 May 2007, Hans Petter Selasky wrote: I would like introduce a new USB API call, so that my pre-allocate model will work better with your USB API. ... int usb_setup_endpoint(struct usb_host_endpoint *hep, size_t bufsize); To save the hep to struct usb_device pointer, I would like to have struct usb_device *dev as an argument. Introducing new error paths ... why? As a rule we remove redudancy. What would such a call do, though? Who would use it, and why? The call will setup one or two pre-allocated USB transfers for the emulation layer between the Linux USB stack and the FreeBSD USB stack. So what's a transfer ... just a bunch of TDs? And what would be the advantage to a Linux driver, since the TDs are allocated on demand in any case? The reason for this is to allow Linux USB drivers to tell the FreeBSD USB stack that they want larger/smaller buffers. On Linux this information can be used to reserve EHCI/UHCI/OHCI USB transfer descriptors. I still don't get it. What's the advantage to Linux? I could imagine a new HCD entry, parallel to endpoint_disable(), called by usbcore. It could initialize HCD-internal state like a QH, and maybe ensure that the relevant TD pool isn't empty. It'd be nice to have a task context for that in all cases. But that wouldn't be visible outside usbcore... On FreeBSD this function will pre-allocate one or two USB transfers for an endpoint using the given bufsize argument. Those FreeBSD USB transfers will then be used to do all the Linux USB transfers. This function can block and must have a context. So what's the model ... GPL'd Linux drivers will be modified to incorporate that call, so they'd work better on FreeBSD? Yes, and under Linux. As you can see, it is not possible to emulate an on-the-fly allocation model by a pre-allocation model. That's why I suggest this API addition. All Linux drivers are allowed to assume on-the-fly allocation though. That's a simpler model than mandatory pre-allocation. In this context, simpler is better. Seems to me that your Linux emulation is missing some important characteristics! - Dave - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
Hi, On Thursday 17 May 2007 21:26, David Brownell wrote: On Thursday 17 May 2007, Hans Petter Selasky wrote: On Thursday 17 May 2007 19:44, David Brownell wrote: On Thursday 17 May 2007, Hans Petter Selasky wrote: I would like introduce a new USB API call, so that my pre-allocate model will work better with your USB API. ... int usb_setup_endpoint(struct usb_host_endpoint *hep, size_t bufsize); To save the hep to struct usb_device pointer, I would like to have struct usb_device *dev as an argument. Introducing new error paths ... why? As a rule we remove redudancy. What would such a call do, though? Who would use it, and why? The call will setup one or two pre-allocated USB transfers for the emulation layer between the Linux USB stack and the FreeBSD USB stack. So what's a transfer ... just a bunch of TDs? And what would be the advantage to a Linux driver, since the TDs are allocated on demand in any case? A USB transfer on FreeBSD is equivalent to an URB on Linux. The difference is that on FreeBSD the USB transfer, struct usbd_xfer, has pointers to pre-allocated TD's, QH's and data-buffers. I want to use one or two USB transfers to move all the USB data from the Linux's URB to a FreeBSD USB transfer. The reason for this is to allow Linux USB drivers to tell the FreeBSD USB stack that they want larger/smaller buffers. On Linux this information can be used to reserve EHCI/UHCI/OHCI USB transfer descriptors. I still don't get it. What's the advantage to Linux? That the Linux USB stack can pre-allocate TD's and QH's on a per-endpoint basis. I could imagine a new HCD entry, parallel to endpoint_disable(), called by usbcore. It could initialize HCD-internal state like a QH, and maybe ensure that the relevant TD pool isn't empty. It'd be nice to have a task context for that in all cases. But that wouldn't be visible outside usbcore... On FreeBSD this function will pre-allocate one or two USB transfers for an endpoint using the given bufsize argument. Those FreeBSD USB transfers will then be used to do all the Linux USB transfers. This function can block and must have a context. So what's the model ... GPL'd Linux drivers will be modified to incorporate that call, so they'd work better on FreeBSD? Yes, and under Linux. As you can see, it is not possible to emulate an on-the-fly allocation model by a pre-allocation model. That's why I suggest this API addition. All Linux drivers are allowed to assume on-the-fly allocation though. That's a simpler model than mandatory pre-allocation. In this context, simpler is better. Why is it simpler than pre-allocation? Seems to me that your Linux emulation is missing some important characteristics! --HPS - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Wednesday 16 May 2007, David Brownell wrote: On Wednesday 16 May 2007, Hans Petter Selasky wrote: Hi, I'm currently working on a Linux USB emulation layer for FreeBSD. In that regard I have some issues that makes the stack peform non-optimal due to its API design. ... in that when you have pre-allocated all buffers and all USB host controller descriptors, you will never get in the situation of not being able to allocate transfer descriptors on the fly, like done on Linux. That's not a failure mode that's been often observed on Linux. (Never, in my own experience... which I admit has not focussed on that particular type of stress load.) So it's hard to argue that it should motivate a redesign of core APIs. A user of the Linux UVC driver unfortunately reported such a failure. The driver allocates 5 bulk URBs, and the device asked for a 2.7MB buffer. The system had been used for quite some time, and the user reported that allocating such an amount of contiguous memory made the box swap out and become very slow. Laurent Pinchart - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Thursday 17 May 2007, Laurent Pinchart wrote: On Wednesday 16 May 2007, David Brownell wrote: On Wednesday 16 May 2007, Hans Petter Selasky wrote: in that when you have pre-allocated all buffers and all USB host controller descriptors, you will never get in the situation of not being able to allocate transfer descriptors on the fly, like done on Linux. That's not a failure mode that's been often observed on Linux. (Never, in my own experience... which I admit has not focussed on that particular type of stress load.) So it's hard to argue that it should motivate a redesign of core APIs. A user of the Linux UVC driver unfortunately reported such a failure. The driver allocates 5 bulk URBs, and the device asked for a 2.7MB buffer. Buffer != transfer descriptor. The bug here is asking for a 2.7 MB block of contiguous memory. As previously discussed, that's not necessary ... or desirable. Drivers asking for such things are buggy -- except possibly on dedicated systems. - Dave The system had been used for quite some time, and the user reported that allocating such an amount of contiguous memory made the box swap out and become very slow. Laurent Pinchart - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Thu, 17 May 2007, Laurent Pinchart wrote: A user of the Linux UVC driver unfortunately reported such a failure. The driver allocates 5 bulk URBs, and the device asked for a 2.7MB buffer. The system had been used for quite some time, and the user reported that allocating such an amount of contiguous memory made the box swap out and become very slow. Obviously the driver should be smart enough not to try and get such a large buffer. It should allocate several smaller buffers instead. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Thursday 17 May 2007, David Brownell wrote: On Thursday 17 May 2007, Laurent Pinchart wrote: On Wednesday 16 May 2007, David Brownell wrote: On Wednesday 16 May 2007, Hans Petter Selasky wrote: in that when you have pre-allocated all buffers and all USB host controller descriptors, you will never get in the situation of not being able to allocate transfer descriptors on the fly, like done on Linux. That's not a failure mode that's been often observed on Linux. (Never, in my own experience... which I admit has not focussed on that particular type of stress load.) So it's hard to argue that it should motivate a redesign of core APIs. A user of the Linux UVC driver unfortunately reported such a failure. The driver allocates 5 bulk URBs, and the device asked for a 2.7MB buffer. Buffer != transfer descriptor. Ok, sorry for the noise. The bug here is asking for a 2.7 MB block of contiguous memory. As previously discussed, that's not necessary ... or desirable. Drivers asking for such things are buggy -- except possibly on dedicated systems. I'm testing a driver patch to allocate much smaller buffers. I will probably run into issues with buggy devices that send a zero packet when the actual payload size is equal to the maximum payload size, and is a multiple of the packet size, but that's another story. Laurent Pinchart - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
The call will setup one or two pre-allocated USB transfers for the emulation layer between the Linux USB stack and the FreeBSD USB stack. So what's a transfer ... just a bunch of TDs? And what would be the advantage to a Linux driver, since the TDs are allocated on demand in any case? A USB transfer on FreeBSD is equivalent to an URB on Linux. The difference is that on FreeBSD the USB transfer, struct usbd_xfer, has pointers to pre-allocated TD's, QH's and data-buffers. So it's not equivalent at all then. The call you want to add would be the first of many, and would imply a second I/O model. Linux only associates a QH and TDs -- where relevant! -- on a temporary basis, while I/O is pending. All Linux drivers are allowed to assume on-the-fly allocation though. That's a simpler model than mandatory pre-allocation. In this context, simpler is better. Why is it simpler than pre-allocation? If you've already got one model, why would you need a second one? When you've got a model that doesn't care where the buffer came from, needing to adopt a second one where you *do* need to care is obviously adding complexity. And that's on top of the performance cost of needing to copy into particular buffers. Also, the current Linux model only exposes resources to drivers if they actually need to manage them: URBs, and buffers (which may come from upper layers of the driver stack). Implementation details (like a TD or other DMA descriptor, QH, etc) are managed separately. - Dave Seems to me that your Linux emulation is missing some important characteristics! - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Thursday 17 May 2007 23:04, Alan Stern wrote: On Thu, 17 May 2007, Laurent Pinchart wrote: A user of the Linux UVC driver unfortunately reported such a failure. The driver allocates 5 bulk URBs, and the device asked for a 2.7MB buffer. The system had been used for quite some time, and the user reported that allocating such an amount of contiguous memory made the box swap out and become very slow. Obviously the driver should be smart enough not to try and get such a large buffer. It should allocate several smaller buffers instead. Isn't that the job of usb_buffer_alloc(), to allocate memory in blocks of PAGE_SIZE bytes? Is it right understood that the Linux USB stack does currently not use scatter and gathering? To me it seems like that, hence in the URB Linux only has a single DMA address value. --HPS - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Thu, 17 May 2007 12:08:15 -0700, David Brownell [EMAIL PROTECTED] wrote: As it happens, USB callbacks cannot be interrupted. That's a somewhat artificial restriction; in theory there's no reason we couldn't allow interrupts. Do you remember why we're doing this? I did not touch that part since the attempt to keep usb-lock across the callback (read: years back). HCDs have, for historical reasons, issued URB completions in their IRQ handlers. In order to do that correctly -- since completion handlers need to be able to submit URBs -- that must be done while (a) dropping the HCD's internal spinlock, but also (b) not re-enabling the HCD's IRQ, and a bit more subtly (c) ensuring certain HCD-internal state doesn't change until after the completion returns. I understand the points a-c above. The question is, why do we do local_irq_save across the URB callback? It seems to be completely non-functional. Linux already guarantees that interrupt handlers are not re-entered. If the interrupt controller on the platform allows it, this is done by masking a specific IRQ. If that is impossible, interrupts are masked in the CPU (maybe only partially, e.g. on SPARC). However it is done though, the local_irq_save that we do adds nothing that I can see. -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Thursday 17 May 2007, Pete Zaitcev wrote: On Thu, 17 May 2007 12:08:15 -0700, David Brownell [EMAIL PROTECTED] wrote: As it happens, USB callbacks cannot be interrupted. That's a somewhat artificial restriction; in theory there's no reason we couldn't allow interrupts. Do you remember why we're doing this? I did not touch that part since the attempt to keep usb-lock across the callback (read: years back). HCDs have, for historical reasons, issued URB completions in their IRQ handlers. In order to do that correctly -- since completion handlers need to be able to submit URBs -- that must be done while (a) dropping the HCD's internal spinlock, but also (b) not re-enabling the HCD's IRQ, and a bit more subtly (c) ensuring certain HCD-internal state doesn't change until after the completion returns. I understand the points a-c above. The question is, why do we do local_irq_save across the URB callback? It seems to be completely non-functional. Where is that done? The HCDs just seem to call usb_hcd_giveback_urb() after dropping their internal spinlock (except the u132 one, which has always been kind of dubious and acts unmaintained). And that routine doesn't do a local_irq_save. So the primary paths certainly don't do such a thing. I could believe other paths have that in case they're not called from an IRQ handler context. Like for example with root hub URBs... - Dave Linux already guarantees that interrupt handlers are not re-entered. If the interrupt controller on the platform allows it, this is done by masking a specific IRQ. If that is impossible, interrupts are masked in the CPU (maybe only partially, e.g. on SPARC). However it is done though, the local_irq_save that we do adds nothing that I can see. -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Thursday 17 May 2007, Hans Petter Selasky wrote: Isn't that the job of usb_buffer_alloc(), to allocate memory in blocks of PAGE_SIZE bytes? Not at all. The size parameter is in bytes, and the utility code it calls goes to some lengths to *avoid* that kind of wastage. As they say: UTSL! The original reason to have such routines was to allocate small buffers for HID devices on systems where DMA map/unmap operations were absurdly expensive on such small buffers. (Think IOMMU ops across a slowish bus.) Is it right understood that the Linux USB stack does currently not use scatter and gathering? To me it seems like that, hence in the URB Linux only has a single DMA address value. Let me guess -- you didn't read my response on that topic ... ? - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Wed, 16 May 2007 14:49:37 +0200, Hans Petter Selasky [EMAIL PROTECTED]
wrote:
I'm currently working on a Linux USB emulation layer for FreeBSD. In that
regard I have some issues that makes the stack peform non-optimal due to its
API design.
I think that what you described is largely inevitable if such a significant
difference exists in stack's architectures, but please see below.
What I would suggest is that when you allocate an URB and DMA'able memory,
you
have to specify which pipe {CONTROL, BULK, INTERRUPT or ISOC} it belongs to.
What do you think?
Just a side note, we are trying to move away from the pipe as a concept,
because it turned out to be ficticious despite being spelled out in the
spec. The real object to which you talk in the device turned out to
be the endpoint, and the spec is deceiptive. So, let's assume that you
want a kind of per-endpoint preallocation.
The reason is that in the new USB stack on FreeBSD, the USB transfer
descriptors are allocated along with the data-buffer, so that when you
unsetup an USB transfer, absolutely all memory related to a transfer is
freed. This also has a security implication in that when you have
pre-allocated all buffers and all USB host controller descriptors, you will
never get in the situation of not being able to allocate transfer descriptors
on the fly, like done on Linux.
The requirement for massive on-the-fly allocations is a part of Linux
stack that bothered me for a long time. This is especially annoying
for block devices when pressure builds up in the VM, and dirty data
has to be written out to a block storage device attached by USB.
This is somewhat analogous to the problem which exists with NFS.
So, in my drivers I leaned heavily towards the kind of preallocation
which you are discussing. However, as you know we never had complete
end-to-end preallocatin facilities, so this never was bulletproof.
Attempts to do this also run against the paucity of IOMMU resources.
We have tons of unnecessary allocations made with usb_buffer_alloc,
of which I'm trying to rid us now. This happened because people
somehow think that it's necessary to use such allocations whenever
USB is involved.
So, recently there was a backlash and giving up on this. Instead,
we are moving to the model which the networking stack uses. This
means, away from you. If anything, you're going to see less use
of usb_buffer_alloc across Linux kernel.
I suppose we could do one last effort:
- redefine usb_buffer_alloc to allow for endpoint argument
- implement methods in HCDs to allocate and free QPs and xxx_priv
- spell out in documentation very clearly that drivers should
NOT use these facilities by default and only use them when
memory pressure invokes these URBs
This is something which, I think, only Greg Kroah can decide on doing
or not doing.
The core issue is, as far as I can tell, in vast majority of cases
the end-to-end preallocation is unnecessary. If used, it adds enormous
complexity, hurts performance, and eats IOMMU. We do not want it
used routinely. So, to implement truly useful preallocations, we
have to have two paths or two chunks of code, one is smaller, less
complex, less buggy, used commonly, and another far more complex,
only used by usb-storage. Personally, I don't see it flying.
-- Pete
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
Hi,
Interesting reading.
On Wednesday 16 May 2007 16:08, Pete Zaitcev wrote:
On Wed, 16 May 2007 14:49:37 +0200, Hans Petter Selasky [EMAIL PROTECTED]
wrote:
I'm currently working on a Linux USB emulation layer for FreeBSD. In that
regard I have some issues that makes the stack peform non-optimal due to
its API design.
I think that what you described is largely inevitable if such a significant
difference exists in stack's architectures, but please see below.
What I would suggest is that when you allocate an URB and DMA'able
memory, you have to specify which pipe {CONTROL, BULK, INTERRUPT or ISOC}
it belongs to.
What do you think?
Just a side note, we are trying to move away from the pipe as a concept,
because it turned out to be ficticious despite being spelled out in the
spec. The real object to which you talk in the device turned out to
be the endpoint, and the spec is deceiptive. So, let's assume that you
want a kind of per-endpoint preallocation.
The reason is that in the new USB stack on FreeBSD, the USB transfer
descriptors are allocated along with the data-buffer, so that when you
unsetup an USB transfer, absolutely all memory related to a transfer is
freed. This also has a security implication in that when you have
pre-allocated all buffers and all USB host controller descriptors, you
will never get in the situation of not being able to allocate transfer
descriptors on the fly, like done on Linux.
The requirement for massive on-the-fly allocations is a part of Linux
stack that bothered me for a long time. This is especially annoying
for block devices when pressure builds up in the VM, and dirty data
has to be written out to a block storage device attached by USB.
This is somewhat analogous to the problem which exists with NFS.
So, in my drivers I leaned heavily towards the kind of preallocation
which you are discussing. However, as you know we never had complete
end-to-end preallocatin facilities, so this never was bulletproof.
Attempts to do this also run against the paucity of IOMMU resources.
We have tons of unnecessary allocations made with usb_buffer_alloc,
of which I'm trying to rid us now. This happened because people
somehow think that it's necessary to use such allocations whenever
USB is involved.
So, recently there was a backlash and giving up on this. Instead,
we are moving to the model which the networking stack uses. This
means, away from you. If anything, you're going to see less use
of usb_buffer_alloc across Linux kernel.
Well, that is not so far away from me. What I plan, but have not implemented
yet is the ability to set a custom buffer on a transfer.
My idea is that you have to specify the maximum transfer length. Then you
allocate descriptors enough to handle that. Then you can do transfers of any
size less than or equal to the maximum. All of the DMA memory allocation is
done allocating single memory pages at a time. I use the scatter and gather
capabilities available on the EHCI/OHCI controllers. There are no multi-page
contiguous allocations.
I suppose we could do one last effort:
- redefine usb_buffer_alloc to allow for endpoint argument
- implement methods in HCDs to allocate and free QPs and xxx_priv
- spell out in documentation very clearly that drivers should
NOT use these facilities by default and only use them when
memory pressure invokes these URBs
This is something which, I think, only Greg Kroah can decide on doing
or not doing.
The core issue is, as far as I can tell, in vast majority of cases
the end-to-end preallocation is unnecessary. If used, it adds enormous
complexity, hurts performance, and eats IOMMU.
No, there is not very much extra complexity added to using end-to-end
pre-allocation. Actually it makes the code simpler, once you first have
overcome the first barriers.
http://www.turbocat.net/~hselasky/isdn4bsd/sources/src/sys/dev/usb/
If you have a look in my ehci.c and the function ehci_xfer_setup(). This
functions allocates both the so-called URB, the required DMA buffer, a
virtually linear buffer if wanted, and all required USB host controller
descriptors.
Then look at ehci_setup_standard_chain(). This function builds the
descriptor chain. It is straight forward and fast.
http://www.turbocat.net/~hselasky/isdn4bsd/sources/src/sys/dev/usb/ehci.c
We do not want it
used routinely. So, to implement truly useful preallocations, we
have to have two paths or two chunks of code, one is smaller, less
complex, less buggy, used commonly, and another far more complex,
only used by usb-storage. Personally, I don't see it flying.
I would recommend that you split large USB-storage transfers into smaller
pieces multiplies of wMaxPacketSize.
http://www.turbocat.net/~hselasky/isdn4bsd/sources/src/sys/dev/usb/umass.c
See the function umass_t_bbb_data_write_callback() for example.
--HPS
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Wednesday 16 May 2007, Hans Petter Selasky wrote:
Hi,
I'm currently working on a Linux USB emulation layer for FreeBSD. In that
regard I have some issues that makes the stack peform non-optimal due to its
API design.
...
What I would suggest is that when you allocate an URB and DMA'able memory,
you
have to specify which pipe {CONTROL, BULK, INTERRUPT or ISOC} it belongs to.
What do you think?
Riddle me this: When should Linux choose to adopt a design mistake
made by a non-Linux driver stack?
The reason is that in the new USB stack on FreeBSD, the USB transfer
descriptors are allocated along with the data-buffer,
Whereas on Linux, data buffers are not normally bound to a particular
driver stack (such as USB). That matches normal hardware usage, and
provides a less restrictive system which minimizes routine requirements
to copy data. (And thus, structural performance limits.)
so that when you
unsetup an USB transfer, absolutely all memory related to a transfer is
freed. This also has a security implication
Calling this security seems like quite a stretch to me. Systems
that don't behave when buffers are exhausted are buggy, sure. And
marginal behavior is always hard to test and debug; and bugs are
always a potential home for exploits (including DOS). But this has
no more security implications than any other tradeoff.
in that when you have
pre-allocated all buffers and all USB host controller descriptors, you will
never get in the situation of not being able to allocate transfer descriptors
on the fly, like done on Linux.
That's not a failure mode that's been often observed on Linux. (Never,
in my own experience... which I admit has not focussed on that particular
type of stress load.) So it's hard to argue that it should motivate a
redesign of core APIs.
Transfer descriptors are an artifact of one kind of host controller;
it'd be wrong to assume all HCDs use them.
The related issue that's been discussed is how to shrink submit paths,
giving lower overhead.
Submitting URBs directly to endpoints would remove lots of dispatch
logic. Pre-allocating some TDs would remove logic too, but implies
changing the URB lifecycle. The peripheral/gadget API allows for
both of those optimizations, but adopting them on the host side would
not be particularly easy because of the how to migrate all drivers
problem. I'd expect submit-to-endpoints to be adopted more easily,
since the low level HCD primitives already work that way.
- Dave
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Wednesday 16 May 2007 16:41, David Brownell wrote:
On Wednesday 16 May 2007, Hans Petter Selasky wrote:
Hi,
I'm currently working on a Linux USB emulation layer for FreeBSD. In that
regard I have some issues that makes the stack peform non-optimal due to
its API design.
...
What I would suggest is that when you allocate an URB and DMA'able
memory, you have to specify which pipe {CONTROL, BULK, INTERRUPT or ISOC}
it belongs to.
What do you think?
Riddle me this: When should Linux choose to adopt a design mistake
made by a non-Linux driver stack?
The reason is that in the new USB stack on FreeBSD, the USB transfer
descriptors are allocated along with the data-buffer,
Whereas on Linux, data buffers are not normally bound to a particular
driver stack (such as USB). That matches normal hardware usage, and
provides a less restrictive system which minimizes routine requirements
to copy data. (And thus, structural performance limits.)
On the BSD platform there is something called BUS-DMA. Memory is allocated
according to PCI device capabilities. This is because sometimes the PCI
device is not capable of addressing the complete memory. Also you need to
sync memory, like on the SUN architecture. Then you need to send specific
commands to the PCI-bridge, for example pshyco. From what I see your model
will not work in all cases.
so that when you
unsetup an USB transfer, absolutely all memory related to a transfer is
freed. This also has a security implication
Calling this security seems like quite a stretch to me. Systems
that don't behave when buffers are exhausted are buggy, sure. And
marginal behavior is always hard to test and debug; and bugs are
always a potential home for exploits (including DOS). But this has
no more security implications than any other tradeoff.
in that when you have
pre-allocated all buffers and all USB host controller descriptors, you
will never get in the situation of not being able to allocate transfer
descriptors on the fly, like done on Linux.
That's not a failure mode that's been often observed on Linux. (Never,
in my own experience... which I admit has not focussed on that particular
type of stress load.) So it's hard to argue that it should motivate a
redesign of core APIs.
That's not the real motiviation for my design. It is just a by-product.
Transfer descriptors are an artifact of one kind of host controller;
it'd be wrong to assume all HCDs use them.
As long as the core information is not in the header of an USB transfer, like
IP-packets have an header, you cannot ignore this.
The related issue that's been discussed is how to shrink submit paths,
giving lower overhead.
Submitting URBs directly to endpoints would remove lots of dispatch
logic. Pre-allocating some TDs would remove logic too, but implies
changing the URB lifecycle. The peripheral/gadget API allows for
both of those optimizations, but adopting them on the host side would
not be particularly easy because of the how to migrate all drivers
problem. I'd expect submit-to-endpoints to be adopted more easily,
since the low level HCD primitives already work that way.
It was hard enough to rewrite the FreeBSD USB drivers. On Linux it will
probably be more difficult, hence you have more supported drivers.
--HPS
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Wed, 16 May 2007, Pete Zaitcev wrote:
What I would suggest is that when you allocate an URB and DMA'able memory,
you
have to specify which pipe {CONTROL, BULK, INTERRUPT or ISOC} it belongs to.
What do you think?
Just a side note, we are trying to move away from the pipe as a concept,
because it turned out to be ficticious despite being spelled out in the
spec. The real object to which you talk in the device turned out to
be the endpoint, and the spec is deceiptive. So, let's assume that you
want a kind of per-endpoint preallocation.
It's worth pointing out that there already are drivers which
preallocate URBs and memory buffers and then share them among multiple
endpoints. One example is usb-storage.
We have discussed in the past the notion of making URB allocation
per-bus. That would have less impact; not too many drivers share URBs
among different devices (although I think the Bluetooth driver does).
The advantage is that the allocation could then automatically
incorporate an HCD-private area; currently this has to be allocated
separately every time an URB is submitted.
The reason is that in the new USB stack on FreeBSD, the USB transfer
descriptors are allocated along with the data-buffer, so that when you
unsetup an USB transfer, absolutely all memory related to a transfer is
freed. This also has a security implication in that when you have
pre-allocated all buffers and all USB host controller descriptors, you will
never get in the situation of not being able to allocate transfer
descriptors
on the fly, like done on Linux.
It might make more sense to dedicate the transfer descriptors to the
endpoint and not to any particular transfer. This can be done entirely
within the HCD code. However it would not completely solve the problem
of needing to allocate descriptors on the fly, although it would reduce
the impact.
The requirement for massive on-the-fly allocations is a part of Linux
stack that bothered me for a long time. This is especially annoying
for block devices when pressure builds up in the VM, and dirty data
has to be written out to a block storage device attached by USB.
This is somewhat analogous to the problem which exists with NFS.
I don't see how either of these scenarios would be affected. Whether
you do all the other allocations when the URB and its buffers are
allocated or you wait until the URB is submitted, the memory pressure
would still be just as bad.
I suppose we could do one last effort:
- redefine usb_buffer_alloc to allow for endpoint argument
- implement methods in HCDs to allocate and free QPs and xxx_priv
- spell out in documentation very clearly that drivers should
NOT use these facilities by default and only use them when
memory pressure invokes these URBs
This is something which, I think, only Greg Kroah can decide on doing
or not doing.
I am not in favor of such a large change.
Alan Stern
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Wed, 16 May 2007 07:41:26 -0700, David Brownell [EMAIL PROTECTED] wrote: in that when you have pre-allocated all buffers and all USB host controller descriptors, you will never get in the situation of not being able to allocate transfer descriptors on the fly, like done on Linux. That's not a failure mode that's been often observed on Linux. (Never, in my own experience... which I admit has not focussed on that particular type of stress load.) So it's hard to argue that it should motivate a redesign of core APIs. I have never, ever, seen USB stack deplete the atomic pool completely either, if this is what you are talking about. So, you're quite right about that. However, the usb-storage worker thread can get stuck sleeping for allocations. We try to deal with it by using GFP_NOIO carefuly, but this is a palliative. I continue to hear from my users with systems locking up when they mount ext3 on winchesters in USB enclosures and use a simple cp. Switching from usb-storage to ub fixes the issue (which is why we continue to ship it). It's not a commonplace concern, but it persists. Sometimes it involves scsi_eh_0. I have come to think that ub does not dramatically alter the pressure on the atomic pool. It allocates the same QHs and TDs. It's the thread which is the main problem, because it allows for interesting scenarios of deadlocks between kswapd, scsi_eh_0, and usb-storage helper. I am thinking about taking the ub concept and integrating it into usb-storage as some kind of threadless option. If only I could get rid of the SCSI error handling... -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Wednesday 16 May 2007, Hans Petter Selasky wrote: On the BSD platform there is something called BUS-DMA. Memory is allocated according to PCI device capabilities. This is because sometimes the PCI device is not capable of addressing the complete memory. Also you need to sync memory, like on the SUN architecture. Then you need to send specific commands to the PCI-bridge, for example pshyco. From what I see your model will not work in all cases. Those issues are handled by the DMA framework, transparently to USB. Transfer descriptors are an artifact of one kind of host controller; it'd be wrong to assume all HCDs use them. As long as the core information is not in the header of an USB transfer, like IP-packets have an header, you cannot ignore this. Strange how it seems to work already though, having factored the problem differently ... I think that word (cannot) doesn't mean what you think it means!! - Dave - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Wednesday 16 May 2007, Pete Zaitcev wrote: On Wed, 16 May 2007 07:41:26 -0700, David Brownell [EMAIL PROTECTED] wrote: in that when you have pre-allocated all buffers and all USB host controller descriptors, you will never get in the situation of not being able to allocate transfer descriptors on the fly, like done on Linux. That's not a failure mode that's been often observed on Linux. (Never, in my own experience... which I admit has not focussed on that particular type of stress load.) So it's hard to argue that it should motivate a redesign of core APIs. I have never, ever, seen USB stack deplete the atomic pool completely either, if this is what you are talking about. So, you're quite right about that. I was referring to the dma_pool allocations ... those don't need to be atomic. OHCI or EHCI tend to allocate a page or so for each type of descriptor seen by the hardware, and usually won't need more than that. UHCI uses more pages; TD-per-packet requirements from the hardware, ISTR (instead of multiple-pages-per-TD). However, the usb-storage worker thread can get stuck sleeping for allocations. Might be good to look at removing that worker thread sometime. We try to deal with it by using GFP_NOIO carefuly, but this is a palliative. I continue to hear from my users with systems locking up when they mount ext3 on winchesters in USB enclosures and use a simple cp. Switching from usb-storage to ub fixes the issue (which is why we continue to ship it). It's not a commonplace concern, but it persists. Sometimes it involves scsi_eh_0. SCSI EH causes lots of strangeness. :( I have come to think that ub does not dramatically alter the pressure on the atomic pool. It allocates the same QHs and TDs. It's the thread which is the main problem, because it allows for interesting scenarios of deadlocks between kswapd, scsi_eh_0, and usb-storage helper. I am thinking about taking the ub concept and integrating it into usb-storage as some kind of threadless option. If only I could get rid of the SCSI error handling... Agreed, all those threads make things complex ... probably more so than is really needed. - Dave - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Wed, 16 May 2007, David Brownell wrote: I have never, ever, seen USB stack deplete the atomic pool completely either, if this is what you are talking about. So, you're quite right about that. I was referring to the dma_pool allocations ... those don't need to be atomic. OHCI or EHCI tend to allocate a page or so for each type of descriptor seen by the hardware, and usually won't need more than that. UHCI uses more pages; TD-per-packet requirements from the hardware, ISTR (instead of multiple-pages-per-TD). If dma_pool allocation isn't atomic, does that mean it could block for I/O? If yes, then it doesn't belong on the usb-storage I/O path. I have come to think that ub does not dramatically alter the pressure on the atomic pool. It allocates the same QHs and TDs. It's the thread which is the main problem, because it allows for interesting scenarios of deadlocks between kswapd, scsi_eh_0, and usb-storage helper. I am thinking about taking the ub concept and integrating it into usb-storage as some kind of threadless option. If only I could get rid of the SCSI error handling... Agreed, all those threads make things complex ... probably more so than is really needed. I wonder... ub does away with thread complexity by using a complex state machine. Ultimately the complexity lies in the USB mass-storage protocol and in error handling; we can't get away from it no matter how we try. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Wed, 16 May 2007 16:52:53 +0200, Hans Petter Selasky [EMAIL PROTECTED] wrote: [...] Then you need to send specific commands to the PCI-bridge, for example pshyco. From what I see your model will not work in all cases. USB through Psycho/Schizo is fully supported on Linux. Heck it works better than the equivalent on x86_64, because there's no address range limitation. The key is to set IOMMU at transfer time. Solaris defers DMA setup as well (for what they call streaming transfers). -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Wed, 16 May 2007 11:38:47 -0400 (EDT), Alan Stern [EMAIL PROTECTED] wrote: I have never, ever, seen USB stack deplete the atomic pool completely either, if this is what you are talking about. So, you're quite right about that. I was referring to the dma_pool allocations ... those don't need to be atomic. OHCI or EHCI tend to allocate a page or so for each type of descriptor seen by the hardware, and usually won't need more than that. UHCI uses more pages; TD-per-packet requirements from the hardware, ISTR (instead of multiple-pages-per-TD). If dma_pool allocation isn't atomic, does that mean it could block for I/O? If yes, then it doesn't belong on the usb-storage I/O path. AFAIK, the definition is, GFP_NOIO can block, but it cannot wait for a writeout. If it cannot be satisfied without writing dirty data, it will fail. -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Wed, 16 May 2007 10:57:04 -0400 (EDT), Alan Stern [EMAIL PROTECTED] wrote: It's worth pointing out that there already are drivers which preallocate URBs and memory buffers and then share them among multiple endpoints. One example is usb-storage. This is for CBI transport, right? Honestly, I forgot about that. But aren't control transfers short, just commands and replies? Their buffers can be dealiased, *if* need arises. We have discussed in the past the notion of making URB allocation per-bus. That would have less impact; not too many drivers share URBs among different devices (although I think the Bluetooth driver does). The advantage is that the allocation could then automatically incorporate an HCD-private area; currently this has to be allocated separately every time an URB is submitted. Right. Per-endpoint with a size limits also allows TDs to be preallocated. The requirement for massive on-the-fly allocations is a part of Linux stack that bothered me for a long time. This is especially annoying for block devices when pressure builds up in the VM, and dirty data has to be written out to a block storage device attached by USB. This is somewhat analogous to the problem which exists with NFS. I don't see how either of these scenarios would be affected. Whether you do all the other allocations when the URB and its buffers are allocated or you wait until the URB is submitted, the memory pressure would still be just as bad. If URB, hcd_priv, and TDs are preallocated, the allocation happens when there's no pressure, and not when all of your memory is dirtied. It can also happen on a process context. I suppose we could do one last effort: - redefine usb_buffer_alloc to allow for endpoint argument - implement methods in HCDs to allocate and free QPs and xxx_priv - spell out in documentation very clearly that drivers should NOT use these facilities by default and only use them when memory pressure invokes these URBs This is something which, I think, only Greg Kroah can decide on doing or not doing. I am not in favor of such a large change. Yeah... I mentioned in my reply to David that I would like to explore more narrow approaches, like a threadless ub-like usb-storage. This won't help Hans in any way, though. -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Wednesday 16 May 2007, Alan Stern wrote: On Wed, 16 May 2007, David Brownell wrote: I have never, ever, seen USB stack deplete the atomic pool completely either, if this is what you are talking about. So, you're quite right about that. I was referring to the dma_pool allocations ... those don't need to be atomic. OHCI or EHCI tend to allocate a page or so for each type of descriptor seen by the hardware, and usually won't need more than that. UHCI uses more pages; TD-per-packet requirements from the hardware, ISTR (instead of multiple-pages-per-TD). If dma_pool allocation isn't atomic, does that mean it could block for I/O? If yes, then it doesn't belong on the usb-storage I/O path. dma_pool_alloc() takes gfp_flags, and (looking at the code) tests only for __GFP_WAIT. So if you don't pass that flag, it won't wait... I have come to think that ub does not dramatically alter the pressure on the atomic pool. It allocates the same QHs and TDs. It's the thread which is the main problem, because it allows for interesting scenarios of deadlocks between kswapd, scsi_eh_0, and usb-storage helper. I am thinking about taking the ub concept and integrating it into usb-storage as some kind of threadless option. If only I could get rid of the SCSI error handling... Agreed, all those threads make things complex ... probably more so than is really needed. I wonder... ub does away with thread complexity by using a complex state machine. Ultimately the complexity lies in the USB mass-storage protocol and in error handling; we can't get away from it no matter how we try. Tradeoffs, tradeoffs... yeah, proponents of threads always like to point out the seeming (micro-) simplicity. It's not clear to me that any resulting macro-complexity is a win in all cases. Sometimes it's clearly not. In this case, I said probably because the macro-complexity of USB-storage gets multiplied by the macro-complexity of SCSI. (I think!) Error paths are where the rubber meets the road... Sometimes you can almost understand why people would choose to live in a fantasy-based world, not the reality-based one. Of course, folk making that choice have no business making decisions affecting the real world (including kernel code). :) - Dave - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Wednesday 16 May 2007 18:00, David Brownell wrote: On Wednesday 16 May 2007, Alan Stern wrote: On Wed, 16 May 2007, David Brownell wrote: I have never, ever, seen USB stack deplete the atomic pool completely either, if this is what you are talking about. So, you're quite right about that. I was referring to the dma_pool allocations ... those don't need to be atomic. OHCI or EHCI tend to allocate a page or so for each type of descriptor seen by the hardware, and usually won't need more than that. UHCI uses more pages; TD-per-packet requirements from the hardware, ISTR (instead of multiple-pages-per-TD). If dma_pool allocation isn't atomic, does that mean it could block for I/O? If yes, then it doesn't belong on the usb-storage I/O path. dma_pool_alloc() takes gfp_flags, and (looking at the code) tests only for __GFP_WAIT. So if you don't pass that flag, it won't wait... It is very clear to me that non-blocking memory allocation at the point of starting an USB transfer will require extra error handling in the USB device driver code! My usbd_transfer_start() returns void. Your usb_submit_urb() returns int. Pre-allocating everything you need simply saves code, hence you only check once if you got the memory or not. --HPS - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Wed, 16 May 2007, Pete Zaitcev wrote: On Wed, 16 May 2007 10:57:04 -0400 (EDT), Alan Stern [EMAIL PROTECTED] wrote: It's worth pointing out that there already are drivers which preallocate URBs and memory buffers and then share them among multiple endpoints. One example is usb-storage. This is for CBI transport, right? Honestly, I forgot about that. But aren't control transfers short, just commands and replies? Their buffers can be dealiased, *if* need arises. It's also true for bulk-only; the same URB and buffer get used for the IN and the OUT endpoints (CSW and CDB). Yes, we could dealias them if necessary. We have discussed in the past the notion of making URB allocation per-bus. That would have less impact; not too many drivers share URBs among different devices (although I think the Bluetooth driver does). The advantage is that the allocation could then automatically incorporate an HCD-private area; currently this has to be allocated separately every time an URB is submitted. Right. Per-endpoint with a size limits also allows TDs to be preallocated. With a large potential waste of memory! UHCI is so inefficient that the TDs use up almost as much memory as the data to be transferred (within a factor of 2). Do we really want to keep those things around when they're not being used? I don't see how either of these scenarios would be affected. Whether you do all the other allocations when the URB and its buffers are allocated or you wait until the URB is submitted, the memory pressure would still be just as bad. If URB, hcd_priv, and TDs are preallocated, the allocation happens when there's no pressure, and not when all of your memory is dirtied. It can also happen on a process context. At the cost of wasting the memory for the URBs and the TDs when they aren't needed. And this wastage would have to be multiplied by the number of the USB mass-storage devices attached to the system. I suppose we could do one last effort: - redefine usb_buffer_alloc to allow for endpoint argument - implement methods in HCDs to allocate and free QPs and xxx_priv - spell out in documentation very clearly that drivers should NOT use these facilities by default and only use them when memory pressure invokes these URBs This is something which, I think, only Greg Kroah can decide on doing or not doing. I am not in favor of such a large change. Yeah... I mentioned in my reply to David that I would like to explore more narrow approaches, like a threadless ub-like usb-storage. This won't help Hans in any way, though. It's possible that we have moved too far in one direction. Even though you might not want to preallocate things all the time, it would be nice if you had the ability to do it when you wanted to. But of course, it would add code and debugging complexity. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Wed, 16 May 2007, Hans Petter Selasky wrote: It is very clear to me that non-blocking memory allocation at the point of starting an USB transfer will require extra error handling in the USB device driver code! It's not so clear to me. My usbd_transfer_start() returns void. Your usb_submit_urb() returns int. URB submission has other failure possibilities than lack of memory. Those other things have to be checked for regardless. Pre-allocating everything you need simply saves code, hence you only check once if you got the memory or not. It doesn't save code. You need to check for the memory when you allocate it, no matter when that is done. One allocation = one check. The total code size is the same if you do the allocation early and only once or if you do it late and many times. It does save execution time. But that's a different matter; it also wastes data space. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Wednesday 16 May 2007, Alan Stern wrote: On Wed, 16 May 2007, Pete Zaitcev wrote: Right. Per-endpoint with a size limits also allows TDs to be preallocated. With a large potential waste of memory! Which is the general down-side of preallocation... UHCI is so inefficient that the TDs use up almost as much memory as the data to be transferred (within a factor of 2). Do we really want to keep those things around when they're not being used? Not really ... considering most endpoints are idle most of the time. Also, remember that the number of TDs required for a buffer isn't strictly a function of buffer size, but also of alignment. EHCI, for one example, can handle up to 20 KB if the buffer is nicely aligned, but maybe only 16 KB otherwise. So if the size limit is 20 KB per URB (I've seen usb-storage regularly want 64 KB though, when memory isn't very fragmented), does that imply one TD or two? - Dave - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Wednesday 16 May 2007 18:21, Alan Stern wrote: On Wed, 16 May 2007, Pete Zaitcev wrote: On Wed, 16 May 2007 10:57:04 -0400 (EDT), Alan Stern [EMAIL PROTECTED] wrote: It's worth pointing out that there already are drivers which preallocate URBs and memory buffers and then share them among multiple endpoints. One example is usb-storage. This is for CBI transport, right? Honestly, I forgot about that. But aren't control transfers short, just commands and replies? Their buffers can be dealiased, *if* need arises. You first send a control request of size 8 bytes. Afterwards you receive or transmit data as indicated by the length field in the control request. It's also true for bulk-only; the same URB and buffer get used for the IN and the OUT endpoints (CSW and CDB). Yes, we could dealias them if necessary. I would says it is a specification design fault that read and write endpoints are not used at the same time. Allocating one buffer for each of the endoints is not a waste of memory. We have discussed in the past the notion of making URB allocation per-bus. That would have less impact; not too many drivers share URBs among different devices (although I think the Bluetooth driver does). The advantage is that the allocation could then automatically incorporate an HCD-private area; currently this has to be allocated separately every time an URB is submitted. Right. Per-endpoint with a size limits also allows TDs to be preallocated. With a large potential waste of memory! UHCI is so inefficient that the TDs use up almost as much memory as the data to be transferred (within a factor of 2). Do we really want to keep those things around when they're not being used? That depends largely on wMaxPacketSize. I don't see how either of these scenarios would be affected. Whether you do all the other allocations when the URB and its buffers are allocated or you wait until the URB is submitted, the memory pressure would still be just as bad. If URB, hcd_priv, and TDs are preallocated, the allocation happens when there's no pressure, and not when all of your memory is dirtied. It can also happen on a process context. At the cost of wasting the memory for the URBs and the TDs when they aren't needed. And this wastage would have to be multiplied by the number of the USB mass-storage devices attached to the system. All devices need to allocate some memory, even if they are not used. That is just the way it is. If you want to save memory, then USB has the advantage that you can unplug the device and save resources. I suppose we could do one last effort: - redefine usb_buffer_alloc to allow for endpoint argument - implement methods in HCDs to allocate and free QPs and xxx_priv - spell out in documentation very clearly that drivers should NOT use these facilities by default and only use them when memory pressure invokes these URBs This is something which, I think, only Greg Kroah can decide on doing or not doing. I am not in favor of such a large change. Yeah... I mentioned in my reply to David that I would like to explore more narrow approaches, like a threadless ub-like usb-storage. This won't help Hans in any way, though. It's possible that we have moved too far in one direction. 1) Even though you might not want to preallocate things all the time, 2) it would be nice if you had the ability to do it when you wanted to. But of course, it would add code and debugging complexity. Most likely I will end up with 16Kbyte buffers on every bulk/interrupt/control endpoint. That should give a maximum transfer rate of approximately 16MB/sec, which is not so bad for ordinary USB gadgets. --HPS - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Wednesday 16 May 2007 18:25, Alan Stern wrote:
On Wed, 16 May 2007, Hans Petter Selasky wrote:
It is very clear to me that non-blocking memory allocation at the point
of starting an USB transfer will require extra error handling in the USB
device driver code!
It's not so clear to me.
In my new USB stack, I pass all endpoint and buffer size information
to usbd_transfer_setup() at attach time:
For example:
static const struct usbd_config umodem_config_data[UMODEM_N_DATA_TRANSFER] = {
[0] = {
.type = UE_BULK,
.endpoint = -1, /* any */
.direction = UE_DIR_OUT,
.bufsize = UMODEM_BUF_SIZE,
.flags = 0,
.callback = umodem_write_callback,
},
[1] = {
.type = UE_BULK,
.endpoint = -1, /* any */
.direction = UE_DIR_IN,
.bufsize = UMODEM_BUF_SIZE,
.flags = USBD_SHORT_XFER_OK,
.callback = umodem_read_callback,
},
[2] = {
.type = UE_CONTROL,
.endpoint = 0x00, /* Control pipe */
.direction = -1,
.bufsize = sizeof(usb_device_request_t),
.callback = umodem_write_clear_stall_callback,
.timeout = 1000, /* 1 second */
},
[3] = {
.type = UE_CONTROL,
.endpoint = 0x00, /* Control pipe */
.direction = -1,
.bufsize = sizeof(usb_device_request_t),
.callback = umodem_read_clear_stall_callback,
.timeout = 1000, /* 1 second */
},
};
error = usbd_transfer_setup(uaa-device, sc-sc_data_iface_index,
sc-sc_xfer_data, umodem_config_data,
UMODEM_N_DATA_TRANSFER,
sc, Giant);
if (error) {
goto detach;
}
My usbd_transfer_start() returns void. Your usb_submit_urb()
returns int.
URB submission has other failure possibilities than lack of memory.
Those other things have to be checked for regardless.
Yes, but that is because you allow too many parameters in the URB to be
changed between USB transfers.
Pre-allocating everything you need simply saves code, hence you only
check once if you got the memory or not.
It doesn't save code. You need to check for the memory when you
allocate it, no matter when that is done.
Yes, but it is a difference doing it once at attach or doing it every time you
start a transfer.
One allocation = one check.
The total code size is the same if you do the allocation early and only
once or if you do it late and many times.
It does save execution time. But that's a different matter; it also
wastes data space.
Yes, it wastes some memory, but that is just how it is. Get used to it :-)
I have some times been thinking that USB endpoint descriptors should have
supplied some information on the maximum bandwidth supported, so that the USB
devices can allocate appropriate buffers.
--HPS
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Wed, 16 May 2007, Hans Petter Selasky wrote: It's also true for bulk-only; the same URB and buffer get used for the IN and the OUT endpoints (CSW and CDB). Yes, we could dealias them if necessary. I would says it is a specification design fault that read and write endpoints are not used at the same time. It's not a specification design fault; the specification says nothing about whether the endpoints are or are not used at the same time. It's a design limitation of the usb-storage driver. With a large potential waste of memory! UHCI is so inefficient that the TDs use up almost as much memory as the data to be transferred (within a factor of 2). Do we really want to keep those things around when they're not being used? That depends largely on wMaxPacketSize. With UHCI, wMaxPacketSize for bulk endpoints is almost always 64, and that's what I was talking about. If wMaxPacketSize is smaller then the ratio is even worse. All devices need to allocate some memory, even if they are not used. That is just the way it is. If you want to save memory, then USB has the advantage that you can unplug the device and save resources. Of course all devices need memory. But there's a big difference between preallocating 4 KB and preallocating 512 KB. And if you start telling people they can save memory by unplugging their USB devices, they'll just laugh at you. Saving memory is the OS's job, not the user's. Most likely I will end up with 16Kbyte buffers on every bulk/interrupt/control endpoint. That should give a maximum transfer rate of approximately 16MB/sec, which is not so bad for ordinary USB gadgets. No doubt you would reduce that amount for hubs, keyboards, and mice. It's not so bad, as you say. Although for mass-storage devices people would want higher transfer rates. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Wed, 16 May 2007, Hans Petter Selasky wrote: On Wednesday 16 May 2007 18:25, Alan Stern wrote: On Wed, 16 May 2007, Hans Petter Selasky wrote: It is very clear to me that non-blocking memory allocation at the point of starting an USB transfer will require extra error handling in the USB device driver code! It's not so clear to me. In my new USB stack, I pass all endpoint and buffer size information to usbd_transfer_setup() at attach time: For example: Irrelevant. This doesn't affect the need for error handling later on. My usbd_transfer_start() returns void. Your usb_submit_urb() returns int. URB submission has other failure possibilities than lack of memory. Those other things have to be checked for regardless. Yes, but that is because you allow too many parameters in the URB to be changed between USB transfers. No; it's because unforeseen events can occur. For example, the device may have been unplugged or suspended. Pre-allocating everything you need simply saves code, hence you only check once if you got the memory or not. It doesn't save code. You need to check for the memory when you allocate it, no matter when that is done. Yes, but it is a difference doing it once at attach or doing it every time you start a transfer. Above you said it saves code. That is wrong. One allocation = one check. The total code size is the same if you do the allocation early and only once or if you do it late and many times. It does save execution time. But that's a different matter; it also wastes data space. Yes, it wastes some memory, but that is just how it is. Get used to it :-) I have some times been thinking that USB endpoint descriptors should have supplied some information on the maximum bandwidth supported, so that the USB devices can allocate appropriate buffers. The manufacturers would probably get it wrong anyway. Alan Stern - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
Hi, On Wednesday 16 May 2007 19:38, Alan Stern wrote: On Wed, 16 May 2007, Hans Petter Selasky wrote: On Wednesday 16 May 2007 18:25, Alan Stern wrote: On Wed, 16 May 2007, Hans Petter Selasky wrote: It is very clear to me that non-blocking memory allocation at the point of starting an USB transfer will require extra error handling in the USB device driver code! It's not so clear to me. In my new USB stack, I pass all endpoint and buffer size information to usbd_transfer_setup() at attach time: For example: Irrelevant. This doesn't affect the need for error handling later on. My usbd_transfer_start() returns void. Your usb_submit_urb() returns int. URB submission has other failure possibilities than lack of memory. Those other things have to be checked for regardless. Yes, but that is because you allow too many parameters in the URB to be changed between USB transfers. No; it's because unforeseen events can occur. For example, the device may have been unplugged or suspended. On FreeBSD it will never happen that you call the equivalent of usb_submit_urb() after that the device has detached! It must be something terribly wrong in the Linux USB stack if the callbacks are alive after that you have detached a USB device. Therefore you don't have to check anything when starting or stopping a USB transfer on FreeBSD [new stack]. Pre-allocating everything you need simply saves code, hence you only check once if you got the memory or not. It doesn't save code. You need to check for the memory when you allocate it, no matter when that is done. Yes, but it is a difference doing it once at attach or doing it every time you start a transfer. Above you said it saves code. That is wrong. One allocation = one check. The total code size is the same if you do the allocation early and only once or if you do it late and many times. It does save execution time. But that's a different matter; it also wastes data space. Yes, it wastes some memory, but that is just how it is. Get used to it :-) I have some times been thinking that USB endpoint descriptors should have supplied some information on the maximum bandwidth supported, so that the USB devices can allocate appropriate buffers. The manufacturers would probably get it wrong anyway. Yes, probably. --HPS - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Wed, 16 May 2007 18:11:35 +0200, Hans Petter Selasky [EMAIL PROTECTED] wrote: My usbd_transfer_start() returns void. Your usb_submit_urb() returns int. We (ok, I) don't like this scheme. In Linux only SCSI uses it, primarily because that's how Eric Youngdale defined it in 1992. See, there may be other reasons why a transfer would fail, outside of memory allocation failure. In such case, an error has to be reported. In your design, error is reported through a callback, and if the error is detected during the submission, it is reported on the context which is submitting. Thus, you cannot hold any locks across the submission which the callback is likely to take. It's a real pain on SMP and with a multithreaded system. -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
URB submission has other failure possibilities than lack of memory. Those other things have to be checked for regardless. Yes, but that is because you allow too many parameters in the URB to be changed between USB transfers. No; it's because unforeseen events can occur. For example, the device may have been unplugged or suspended. On FreeBSD it will never happen that you call the equivalent of usb_submit_urb() after that the device has detached! It must be something terribly wrong in the Linux USB stack if the callbacks are alive after that you have detached a USB device. How does that work then ... driver must grab a lock, check whether the device has disconnected, then submit the request and drop the lock? Sounds like needless slowdowns. Because if there's no lock against async disconnect events, then it's trivial to have the disconnect logic underway on one CPU while another CPU does real work, submitting an I/O request. - Dave p.s. You mentioned 16 MB/sec bulk transfer rates. Folk often get over twice that on Linux, and a few years back there were measurements of around 50 MByte/sec ... limitations seeming to come from hardware not the driver stack. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Wed, 16 May 2007 19:49:57 +0200, Hans Petter Selasky [EMAIL PROTECTED] wrote: No; it's because unforeseen events can occur. For example, the device may have been unplugged or suspended. On FreeBSD it will never happen that you call the equivalent of usb_submit_urb() after that the device has detached! It must be something terribly wrong in the Linux USB stack if the callbacks are alive after that you have detached a USB device. I'm so blogging this. -- Pete - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
Hi,
On Wednesday 16 May 2007 20:20, David Brownell wrote:
URB submission has other failure possibilities than lack of memory.
Those other things have to be checked for regardless.
Yes, but that is because you allow too many parameters in the URB to
be changed between USB transfers.
No; it's because unforeseen events can occur. For example, the device
may have been unplugged or suspended.
On FreeBSD it will never happen that you call the equivalent
of usb_submit_urb() after that the device has detached! It must be
something terribly wrong in the Linux USB stack if the callbacks are
alive after that you have detached a USB device.
How does that work then ... driver must grab a lock, check
whether the device has disconnected, then submit the request
and drop the lock? Sounds like needless slowdowns.
Each USB device has its own lock. There are some tricks there.
1) usbd_transfer_start() is always called like this:
usbd_transfer_start(sc-sc_xfer[x]);
2) sc-sc_xfer[x] is set to zero at detach holding the private lock of the USB
device driver. All subsequent calls to usbd_transfer_start(), if any, will
fail.
3) usbd_transfer_start() is always non-blocking. In other words a single lock
is held across the call.
This is how it looks until further:
As you can see, no other locks are locked unless you want to submit a transfer
to the USB host controller. Then you have to aquire usb_mtx which is per
USB host controller.
void
usbd_transfer_start(struct usbd_xfer *xfer)
{
if (xfer == NULL) {
/* transfer is gone */
return;
}
mtx_assert(xfer-priv_mtx, MA_OWNED);
if(!(xfer-flags USBD_DEV_OPEN))
{
xfer-flags |= USBD_DEV_OPEN;
/*
* open transfer
*/
mtx_lock(xfer-usb_mtx);
(xfer-pipe-methods-open)(xfer);
mtx_unlock(xfer-usb_mtx);
}
/* USBD_DEV_TRANSFERRING is only changed
* when priv_mtx is locked
*/
if(!(xfer-flags (USBD_DEV_TRANSFERRING)))
{
/* call callback */
__usbd_callback(xfer);
cut away
}
return;
}
Because if there's no lock against async disconnect events,
then it's trivial to have the disconnect logic underway on
one CPU while another CPU does real work, submitting an I/O
request.
We solve this in one of two ways:
1) Using a mutex. At detach we lock the mutex stopping all transfers.
2) Using a thread. At detach we teardown and wait for the thread to exit.
- Dave
p.s. You mentioned 16 MB/sec bulk transfer rates. Folk often
get over twice that on Linux, and a few years back there
were measurements of around 50 MByte/sec ... limitations
seeming to come from hardware not the driver stack.
Yes, hardware and price :-)
--HPS
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Wednesday 16 May 2007 20:20, Pete Zaitcev wrote:
On Wed, 16 May 2007 18:11:35 +0200, Hans Petter Selasky [EMAIL PROTECTED]
wrote:
My usbd_transfer_start() returns void. Your usb_submit_urb()
returns int.
We (ok, I) don't like this scheme. In Linux only SCSI uses it,
primarily because that's how Eric Youngdale defined it in 1992.
See, there may be other reasons why a transfer would fail, outside
of memory allocation failure. In such case, an error has to be
reported. In your design, error is reported through a callback,
and if the error is detected during the submission, it is reported
on the context which is submitting. Thus, you cannot hold any
locks across the submission which the callback is likely to take.
It's a real pain on SMP and with a multithreaded system.
The lock that you are holding during submission is the same lock that is
protecting the callback. Actually you can end up calling the
__usbd_callback() prematurely in my new USB stack, but that is handled just
fine, through some recurse bits:
void
__usbd_callback(struct usbd_xfer *xfer)
{
mtx_assert(xfer-priv_mtx, MA_OWNED);
/* check first recurse flag */
if(!(xfer-flags USBD_DEV_RECURSED_1))
{
do {
/* set both recurse flags */
xfer-flags |= (USBD_DEV_RECURSED_2|
USBD_DEV_RECURSED_1);
/* call processing routine */
(xfer-callback)(xfer);
/* check second recurse flag */
} while(!(xfer-flags USBD_DEV_RECURSED_2));
/* clear first recurse flag */
xfer-flags = ~USBD_DEV_RECURSED_1;
}
else
{
/* clear second recurse flag */
xfer-flags = ~USBD_DEV_RECURSED_2;
}
return;
}
Those recurse bits solve the problem if you call urb_submit() from the
callback and you want to return an error.
Two flies have been smacked into one. There is only one error check, and that
is when the transfer fails. Therefore there is no need to return an error
by usbd_transfer_start().
--HPS
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] New USB stack on FreeBSD w/Linux emulation layer coming
On Wednesday 16 May 2007, Hans Petter Selasky wrote: Hi, On Wednesday 16 May 2007 20:20, David Brownell wrote: URB submission has other failure possibilities than lack of memory. Those other things have to be checked for regardless. Yes, but that is because you allow too many parameters in the URB to be changed between USB transfers. No; it's because unforeseen events can occur. For example, the device may have been unplugged or suspended. On FreeBSD it will never happen that you call the equivalent of usb_submit_urb() after that the device has detached! It must be something terribly wrong in the Linux USB stack if the callbacks are alive after that you have detached a USB device. How does that work then ... driver must grab a lock, check whether the device has disconnected, then submit the request and drop the lock? Sounds like needless slowdowns. Each USB device has its own lock. There are some tricks there. 1) usbd_transfer_start() is always called like this: usbd_transfer_start(sc-sc_xfer[x]); 2) sc-sc_xfer[x] is set to zero at detach holding the private lock of the USB device driver. All subsequent calls to usbd_transfer_start(), if any, will fail. So there's a race on SMP, where sc-sc_xfer[x] may be referenced on one CPU while another is nulling it. The lock you showed is inside usbd_transfer_start(), where it can't do any good. 3) usbd_transfer_start() is always non-blocking. In other words a single lock is held across the call. Like usb_submit_urb() then, except that the disconnect race is handled by being buggy rather than by reporting a fault at submit time... ... Because if there's no lock against async disconnect events, then it's trivial to have the disconnect logic underway on one CPU while another CPU does real work, submitting an I/O request. We solve this in one of two ways: 1) Using a mutex. At detach we lock the mutex stopping all transfers. 2) Using a thread. At detach we teardown and wait for the thread to exit. But there's that race above, so it's not solved. - Dave - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
