On Thu, 2008-03-27 at 12:57 +0100, Holger Schurig wrote: > > The problem with using upld_buf (and therefore zero-copy in > > the CF driver) is that you have no idea how long a read from > > the card will really take, and what errors might happen during > > the read from the card. > > Yes, this can take a long time. And, BTW, I don't want to use > upld_buf. > > > My idea is this: > > > > struct lbs_event *lbs_get_free_event(struct lbs_private > > > *priv); > > This will take out an lbs_event from the event_free_list and > return it. > Taking out has to be done under spinlock, but this is very fast. > > Once the lbs_event is no longer in any of the two event list, > we "own" it and can handle it as long as we want, without the > need of an additional spinlock. > > Then > > > > void lbs_handle_event(struct lbs_private *priv, struct > > > lbs_event *event); > > would again take the spinlock, insert the event in the > event_list, and release the spinlock. Which again takes only a > short time. well, if this is being done in lbs_thread() then the call from lbs_get_free_event() is going to be right above lbs_handle_event() anyway, so you might as well hold the spinlock over both, right? I'm just basing that assumption off the existing structure of lbs_thread(), maybe you've re-ordered it a lot or something. But it sounds OK. Dan > This approach can make receiption of command responses from card > zero-copy like, at least insofar the event processing is > considered. > > > > > I'd argue that the CF driver should also have an internal > > buffer like the SDIO and USB drivers do, and then there's still > > only one copy. > > Yeah, but I can reduce easily to a 0-copy-scheme. > > > I hope all of this sounds sane. > -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
