On Mon, 2008-10-20 at 02:14 -0700, Luis R. Rodriguez wrote: > Indeed I agree with this. I think we can do this in three steps: > > 1. resolve aggregation for now for ath9k That's what Sujith's patch does, basically. It just leaves the Intel hooks in place. > 2. resolve aggregation for amdpu_queue case. My suggestion here is to > use skb_buf_head (after Jouni's suggestion for our driver in fact), > and do not make use of a qdisc at all for this I agree on both, but this is more of an implementation detail than an API description, which we really want to have first. > 3. consider what we can really share when schedulers on aggr differ, > in one case where everything is in the driver and the other where its > not. For example -- when a new driver requiring aggregation is needed > we can consolidate aggr scheduler mechanisms. If this is not > acceptable this means we have to do it now but I don't know enough > about any other hardware to do it accurately to make it work for 2 > hardwares. I think the scheduler probably doesn't really matter as long as we have a way to let the frames stop coming in/start again. And I also don't think there are any other possible much different hardware designs. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
