Re: [Linux-zigbee-devel] [PATCH 1/6] mac802154: Immediately retry sending failed packets
On 04/02/2013 10:30 PM, David Miller wrote: > From: Alan Ott > Date: Tue, 02 Apr 2013 22:25:28 -0400 > >> The workqueue in mac802154 is only needed because the current mac802154 >> xmit() function is designed to be blocking and synchronous. >> >> Prior to my patch (#3/6), that very same workqueue would actually queue >> up packets (without bound). That's what my patch fixes. >> >> The workqueue in mac802154 also serializes the access to the device for >> other functions like setting the channel, ensuring that in the driver >> code, one doesn't have to mutex everything. I'm not sure if that's the >> "right" way to do it, but that's the way it was when I got here. > This is entirely duplicating existing facilities. > > Your desire to allow blockability during xmit() on the basis of mutual > exclusion is not well founded. I'm not sure it's my desire, but rather a statement of the way it currently is. To be clear, .ndo_start_xmit() does not block, but queues a workqueue item which then calls ieee802154_ops->xmit() which does block. This patch series centers around putting netif_stop_queue() and netif_wake_queue() in the mac802154 layer. I've sent emails about this before[1], and gotten no real suggestions about the issue, so I proceeded with Solution #1 (as described at [1]). If you want to skip this and go straight to solution #2, then let's talk about what that might look like. I still think though, that there is benefit in getting solution #1 in because it fixes some current usability problems (including the buffer (workqueue) growing without bound). All that said, I'm not sure I've answered your question or concern. Please let me know if I'm still not getting it. Alan. [1] http://thread.gmane.org/gmane.linux.network/242495/focus=262869 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-zigbee-devel] [PATCH 1/6] mac802154: Immediately retry sending failed packets
Alan Ott wrote: > 1. Most supported devices have only single packet output buffer, so > blocking in the driver is the most straight-forward way to handle it. > The alternative is to make each driver have a workqueue for xmit() (to > lift the blocking out from atomic context). This makes each driver simpler. It does make following the program flow a little easier, but the difference isn't all that large if you think of it, particularly if you have to wait not only for I/O to finish but also for the device to send the packet. The latter will usually be signaled by some form of interrupt, so you're already in a situation where a callback to the higher layers of the stack would be very natural. > Maybe at some point this will be done. Right now we have a ton of > pressing issues (in my opinion). Agreed on having no shortage of nasty issues :-) And I'd like to echo Dave's comment regarding netdev. Those ieee802154_dev always struck me as peculiar, with flow control just being one issue. And things get worse when you have a complex bus underneath your driver. For example, my USB-using atusb driver (*) has to do a great many things usbnet already does. And any other USB-based WPAN driver would be more or less in the same boat. Of course, one could reinvent that wheel as well and make a usbwpan, but ... :) (*) Sneak preview, still with a number of issues, not only style: https://github.com/wpwrak/ben-wpan-linux/blob/master/drivers/net/ieee802154/atusb.c - Werner -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-zigbee-devel] [PATCH 1/6] mac802154: Immediately retry sending failed packets
From: Alan Ott Date: Tue, 02 Apr 2013 22:25:28 -0400 > The workqueue in mac802154 is only needed because the current mac802154 > xmit() function is designed to be blocking and synchronous. > > Prior to my patch (#3/6), that very same workqueue would actually queue > up packets (without bound). That's what my patch fixes. > > The workqueue in mac802154 also serializes the access to the device for > other functions like setting the channel, ensuring that in the driver > code, one doesn't have to mutex everything. I'm not sure if that's the > "right" way to do it, but that's the way it was when I got here. This is entirely duplicating existing facilities. Your desire to allow blockability during xmit() on the basis of mutual exclusion is not well founded. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-zigbee-devel] [PATCH 1/6] mac802154: Immediately retry sending failed packets
On 04/02/2013 10:03 PM, David Miller wrote: > From: Alan Ott > Date: Tue, 02 Apr 2013 21:59:37 -0400 > >> On 04/02/2013 09:56 PM, David Miller wrote: >>> From: Alan Ott >>> Date: Tue, 02 Apr 2013 21:24:59 -0400 >>> I like it for a couple of reasons. 1. Most supported devices have only single packet output buffer, so blocking in the driver is the most straight-forward way to handle it. The alternative is to make each driver have a workqueue for xmit() (to lift the blocking out from atomic context). This makes each driver simpler. 2. All of the flow control can be handled one time in the mac802154 layer. >>> We have a perfectly working flow control mechanism in the generic >>> networking queuing layer. Please use it instead of inventing things. >> I'm pretty sure that's what I'm doing in [1]. When I say "flow control >> can be handled," I mean managing calls to netif_stop_queue() and >> netif_wake_queue(). Is there something else I should be doing instead? > Then you shouldn't need workqueues if the generic netdev facilities > can do the flow control properly. The workqueue in mac802154 is only needed because the current mac802154 xmit() function is designed to be blocking and synchronous. Prior to my patch (#3/6), that very same workqueue would actually queue up packets (without bound). That's what my patch fixes. The workqueue in mac802154 also serializes the access to the device for other functions like setting the channel, ensuring that in the driver code, one doesn't have to mutex everything. I'm not sure if that's the "right" way to do it, but that's the way it was when I got here. > There are several ethernet devices that have a single transmit buffer > and function just fine, and optimally, solely using the transmit queue > stop/start/wake infrastructure. Yes, that does work. enc28j60 works like this. However, since it's an SPI device (and can sleep), its ndo_start_xmit() _does_ use a workqueue (to remove it from atomic context), the same as ours (mac802154) does. The difference is that we do it at the mac802154 layer, while Ethernet devices do it in the driver. I guess one advantage to the way it currently is in mac802154, with the synchronous xmit(), is that a return code can be had from the driver for each packet. With my new idea that we don't need to retransmit on failure, I'm not sure we need this return code at all. Alan. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-zigbee-devel] [PATCH 1/6] mac802154: Immediately retry sending failed packets
From: Alan Ott Date: Tue, 02 Apr 2013 21:59:37 -0400 > On 04/02/2013 09:56 PM, David Miller wrote: >> From: Alan Ott >> Date: Tue, 02 Apr 2013 21:24:59 -0400 >> >>> I like it for a couple of reasons. >>> 1. Most supported devices have only single packet output buffer, so >>> blocking in the driver is the most straight-forward way to handle it. >>> The alternative is to make each driver have a workqueue for xmit() (to >>> lift the blocking out from atomic context). This makes each driver simpler. >>> >>> 2. All of the flow control can be handled one time in the mac802154 layer. >> We have a perfectly working flow control mechanism in the generic >> networking queuing layer. Please use it instead of inventing things. > > I'm pretty sure that's what I'm doing in [1]. When I say "flow control > can be handled," I mean managing calls to netif_stop_queue() and > netif_wake_queue(). Is there something else I should be doing instead? Then you shouldn't need workqueues if the generic netdev facilities can do the flow control properly. There are several ethernet devices that have a single transmit buffer and function just fine, and optimally, solely using the transmit queue stop/start/wake infrastructure. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-zigbee-devel] [PATCH 1/6] mac802154: Immediately retry sending failed packets
On 04/02/2013 09:56 PM, David Miller wrote: > From: Alan Ott > Date: Tue, 02 Apr 2013 21:24:59 -0400 > >> I like it for a couple of reasons. >> 1. Most supported devices have only single packet output buffer, so >> blocking in the driver is the most straight-forward way to handle it. >> The alternative is to make each driver have a workqueue for xmit() (to >> lift the blocking out from atomic context). This makes each driver simpler. >> >> 2. All of the flow control can be handled one time in the mac802154 layer. > We have a perfectly working flow control mechanism in the generic > networking queuing layer. Please use it instead of inventing things. I'm pretty sure that's what I'm doing in [1]. When I say "flow control can be handled," I mean managing calls to netif_stop_queue() and netif_wake_queue(). Is there something else I should be doing instead? > If it does not meet your needs, fix it, rather than go off and do > your own thing. That way everyone benfits, not just you. Fully agreed. Alan. [1] http://www.spinics.net/lists/netdev/msg231483.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-zigbee-devel] [PATCH 1/6] mac802154: Immediately retry sending failed packets
From: Alan Ott Date: Tue, 02 Apr 2013 21:24:59 -0400 > I like it for a couple of reasons. > 1. Most supported devices have only single packet output buffer, so > blocking in the driver is the most straight-forward way to handle it. > The alternative is to make each driver have a workqueue for xmit() (to > lift the blocking out from atomic context). This makes each driver simpler. > > 2. All of the flow control can be handled one time in the mac802154 layer. We have a perfectly working flow control mechanism in the generic networking queuing layer. Please use it instead of inventing things. If it does not meet your needs, fix it, rather than go off and do your own thing. That way everyone benfits, not just you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-zigbee-devel] [PATCH 1/6] mac802154: Immediately retry sending failed packets
On 04/02/2013 07:13 PM, Werner Almesberger wrote: > Alan Ott wrote: >> it's now my opinion that we should _not_ try to retransmit at >> all in mac802154/tx.c. > I think the currently blocking workqueue design is ugly and > quite contrary to how most the rest of the stack works. So > anything that kills it has my blessing :-) I like it for a couple of reasons. 1. Most supported devices have only single packet output buffer, so blocking in the driver is the most straight-forward way to handle it. The alternative is to make each driver have a workqueue for xmit() (to lift the blocking out from atomic context). This makes each driver simpler. 2. All of the flow control can be handled one time in the mac802154 layer. > I do wonder though why it was done like this in the first place. > Just for convenience ? > > If we want to move towards an asynchronous interface, it could > exist in parallel with the current one. That way, drivers could > be migrated one by one. Maybe at some point this will be done. Right now we have a ton of pressing issues (in my opinion). > Having said that, the errors you get there may not be failed > single transmissions on the air but some form of congestion in > the driver or a problem with the device. But I don't think > that's a valid reason for retrying the transmission at that > level. Agreed. Like I said, I'm now of the opinion that the mac802154 layer should _not_ retry at all. Alan. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-zigbee-devel] [PATCH 1/6] mac802154: Immediately retry sending failed packets
Alan Ott wrote: > it's now my opinion that we should _not_ try to retransmit at > all in mac802154/tx.c. I think the currently blocking workqueue design is ugly and quite contrary to how most the rest of the stack works. So anything that kills it has my blessing :-) I do wonder though why it was done like this in the first place. Just for convenience ? If we want to move towards an asynchronous interface, it could exist in parallel with the current one. That way, drivers could be migrated one by one. Having said that, the errors you get there may not be failed single transmissions on the air but some form of congestion in the driver or a problem with the device. But I don't think that's a valid reason for retrying the transmission at that level. - Werner -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-zigbee-devel] [PATCH 1/6] mac802154: Immediately retry sending failed packets
Alan Ott wrote: it's now my opinion that we should _not_ try to retransmit at all in mac802154/tx.c. I think the currently blocking workqueue design is ugly and quite contrary to how most the rest of the stack works. So anything that kills it has my blessing :-) I do wonder though why it was done like this in the first place. Just for convenience ? If we want to move towards an asynchronous interface, it could exist in parallel with the current one. That way, drivers could be migrated one by one. Having said that, the errors you get there may not be failed single transmissions on the air but some form of congestion in the driver or a problem with the device. But I don't think that's a valid reason for retrying the transmission at that level. - Werner -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-zigbee-devel] [PATCH 1/6] mac802154: Immediately retry sending failed packets
On 04/02/2013 07:13 PM, Werner Almesberger wrote: Alan Ott wrote: it's now my opinion that we should _not_ try to retransmit at all in mac802154/tx.c. I think the currently blocking workqueue design is ugly and quite contrary to how most the rest of the stack works. So anything that kills it has my blessing :-) I like it for a couple of reasons. 1. Most supported devices have only single packet output buffer, so blocking in the driver is the most straight-forward way to handle it. The alternative is to make each driver have a workqueue for xmit() (to lift the blocking out from atomic context). This makes each driver simpler. 2. All of the flow control can be handled one time in the mac802154 layer. I do wonder though why it was done like this in the first place. Just for convenience ? If we want to move towards an asynchronous interface, it could exist in parallel with the current one. That way, drivers could be migrated one by one. Maybe at some point this will be done. Right now we have a ton of pressing issues (in my opinion). Having said that, the errors you get there may not be failed single transmissions on the air but some form of congestion in the driver or a problem with the device. But I don't think that's a valid reason for retrying the transmission at that level. Agreed. Like I said, I'm now of the opinion that the mac802154 layer should _not_ retry at all. Alan. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-zigbee-devel] [PATCH 1/6] mac802154: Immediately retry sending failed packets
From: Alan Ott a...@signal11.us Date: Tue, 02 Apr 2013 21:24:59 -0400 I like it for a couple of reasons. 1. Most supported devices have only single packet output buffer, so blocking in the driver is the most straight-forward way to handle it. The alternative is to make each driver have a workqueue for xmit() (to lift the blocking out from atomic context). This makes each driver simpler. 2. All of the flow control can be handled one time in the mac802154 layer. We have a perfectly working flow control mechanism in the generic networking queuing layer. Please use it instead of inventing things. If it does not meet your needs, fix it, rather than go off and do your own thing. That way everyone benfits, not just you. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-zigbee-devel] [PATCH 1/6] mac802154: Immediately retry sending failed packets
On 04/02/2013 09:56 PM, David Miller wrote: From: Alan Ott a...@signal11.us Date: Tue, 02 Apr 2013 21:24:59 -0400 I like it for a couple of reasons. 1. Most supported devices have only single packet output buffer, so blocking in the driver is the most straight-forward way to handle it. The alternative is to make each driver have a workqueue for xmit() (to lift the blocking out from atomic context). This makes each driver simpler. 2. All of the flow control can be handled one time in the mac802154 layer. We have a perfectly working flow control mechanism in the generic networking queuing layer. Please use it instead of inventing things. I'm pretty sure that's what I'm doing in [1]. When I say flow control can be handled, I mean managing calls to netif_stop_queue() and netif_wake_queue(). Is there something else I should be doing instead? If it does not meet your needs, fix it, rather than go off and do your own thing. That way everyone benfits, not just you. Fully agreed. Alan. [1] http://www.spinics.net/lists/netdev/msg231483.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-zigbee-devel] [PATCH 1/6] mac802154: Immediately retry sending failed packets
From: Alan Ott a...@signal11.us Date: Tue, 02 Apr 2013 21:59:37 -0400 On 04/02/2013 09:56 PM, David Miller wrote: From: Alan Ott a...@signal11.us Date: Tue, 02 Apr 2013 21:24:59 -0400 I like it for a couple of reasons. 1. Most supported devices have only single packet output buffer, so blocking in the driver is the most straight-forward way to handle it. The alternative is to make each driver have a workqueue for xmit() (to lift the blocking out from atomic context). This makes each driver simpler. 2. All of the flow control can be handled one time in the mac802154 layer. We have a perfectly working flow control mechanism in the generic networking queuing layer. Please use it instead of inventing things. I'm pretty sure that's what I'm doing in [1]. When I say flow control can be handled, I mean managing calls to netif_stop_queue() and netif_wake_queue(). Is there something else I should be doing instead? Then you shouldn't need workqueues if the generic netdev facilities can do the flow control properly. There are several ethernet devices that have a single transmit buffer and function just fine, and optimally, solely using the transmit queue stop/start/wake infrastructure. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-zigbee-devel] [PATCH 1/6] mac802154: Immediately retry sending failed packets
On 04/02/2013 10:03 PM, David Miller wrote: From: Alan Ott a...@signal11.us Date: Tue, 02 Apr 2013 21:59:37 -0400 On 04/02/2013 09:56 PM, David Miller wrote: From: Alan Ott a...@signal11.us Date: Tue, 02 Apr 2013 21:24:59 -0400 I like it for a couple of reasons. 1. Most supported devices have only single packet output buffer, so blocking in the driver is the most straight-forward way to handle it. The alternative is to make each driver have a workqueue for xmit() (to lift the blocking out from atomic context). This makes each driver simpler. 2. All of the flow control can be handled one time in the mac802154 layer. We have a perfectly working flow control mechanism in the generic networking queuing layer. Please use it instead of inventing things. I'm pretty sure that's what I'm doing in [1]. When I say flow control can be handled, I mean managing calls to netif_stop_queue() and netif_wake_queue(). Is there something else I should be doing instead? Then you shouldn't need workqueues if the generic netdev facilities can do the flow control properly. The workqueue in mac802154 is only needed because the current mac802154 xmit() function is designed to be blocking and synchronous. Prior to my patch (#3/6), that very same workqueue would actually queue up packets (without bound). That's what my patch fixes. The workqueue in mac802154 also serializes the access to the device for other functions like setting the channel, ensuring that in the driver code, one doesn't have to mutex everything. I'm not sure if that's the right way to do it, but that's the way it was when I got here. There are several ethernet devices that have a single transmit buffer and function just fine, and optimally, solely using the transmit queue stop/start/wake infrastructure. Yes, that does work. enc28j60 works like this. However, since it's an SPI device (and can sleep), its ndo_start_xmit() _does_ use a workqueue (to remove it from atomic context), the same as ours (mac802154) does. The difference is that we do it at the mac802154 layer, while Ethernet devices do it in the driver. I guess one advantage to the way it currently is in mac802154, with the synchronous xmit(), is that a return code can be had from the driver for each packet. With my new idea that we don't need to retransmit on failure, I'm not sure we need this return code at all. Alan. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-zigbee-devel] [PATCH 1/6] mac802154: Immediately retry sending failed packets
From: Alan Ott a...@signal11.us Date: Tue, 02 Apr 2013 22:25:28 -0400 The workqueue in mac802154 is only needed because the current mac802154 xmit() function is designed to be blocking and synchronous. Prior to my patch (#3/6), that very same workqueue would actually queue up packets (without bound). That's what my patch fixes. The workqueue in mac802154 also serializes the access to the device for other functions like setting the channel, ensuring that in the driver code, one doesn't have to mutex everything. I'm not sure if that's the right way to do it, but that's the way it was when I got here. This is entirely duplicating existing facilities. Your desire to allow blockability during xmit() on the basis of mutual exclusion is not well founded. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-zigbee-devel] [PATCH 1/6] mac802154: Immediately retry sending failed packets
Alan Ott wrote: 1. Most supported devices have only single packet output buffer, so blocking in the driver is the most straight-forward way to handle it. The alternative is to make each driver have a workqueue for xmit() (to lift the blocking out from atomic context). This makes each driver simpler. It does make following the program flow a little easier, but the difference isn't all that large if you think of it, particularly if you have to wait not only for I/O to finish but also for the device to send the packet. The latter will usually be signaled by some form of interrupt, so you're already in a situation where a callback to the higher layers of the stack would be very natural. Maybe at some point this will be done. Right now we have a ton of pressing issues (in my opinion). Agreed on having no shortage of nasty issues :-) And I'd like to echo Dave's comment regarding netdev. Those ieee802154_dev always struck me as peculiar, with flow control just being one issue. And things get worse when you have a complex bus underneath your driver. For example, my USB-using atusb driver (*) has to do a great many things usbnet already does. And any other USB-based WPAN driver would be more or less in the same boat. Of course, one could reinvent that wheel as well and make a usbwpan, but ... :) (*) Sneak preview, still with a number of issues, not only style: https://github.com/wpwrak/ben-wpan-linux/blob/master/drivers/net/ieee802154/atusb.c - Werner -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-zigbee-devel] [PATCH 1/6] mac802154: Immediately retry sending failed packets
On 04/02/2013 10:30 PM, David Miller wrote: From: Alan Ott a...@signal11.us Date: Tue, 02 Apr 2013 22:25:28 -0400 The workqueue in mac802154 is only needed because the current mac802154 xmit() function is designed to be blocking and synchronous. Prior to my patch (#3/6), that very same workqueue would actually queue up packets (without bound). That's what my patch fixes. The workqueue in mac802154 also serializes the access to the device for other functions like setting the channel, ensuring that in the driver code, one doesn't have to mutex everything. I'm not sure if that's the right way to do it, but that's the way it was when I got here. This is entirely duplicating existing facilities. Your desire to allow blockability during xmit() on the basis of mutual exclusion is not well founded. I'm not sure it's my desire, but rather a statement of the way it currently is. To be clear, .ndo_start_xmit() does not block, but queues a workqueue item which then calls ieee802154_ops-xmit() which does block. This patch series centers around putting netif_stop_queue() and netif_wake_queue() in the mac802154 layer. I've sent emails about this before[1], and gotten no real suggestions about the issue, so I proceeded with Solution #1 (as described at [1]). If you want to skip this and go straight to solution #2, then let's talk about what that might look like. I still think though, that there is benefit in getting solution #1 in because it fixes some current usability problems (including the buffer (workqueue) growing without bound). All that said, I'm not sure I've answered your question or concern. Please let me know if I'm still not getting it. Alan. [1] http://thread.gmane.org/gmane.linux.network/242495/focus=262869 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
