On 15-12-30 12:26 PM, Jesper Dangaard Brouer wrote: > On Wed, 30 Dec 2015 09:52:49 -0800 > John Fastabend <john.fastab...@gmail.com> wrote: > >> The net sched infrastructure has a gso ptr that points to skb structs >> that have failed to be enqueued by the device driver. > > What about fixing up the naming "gso" to something else like "requeue", > in the process (or by an pre-patch) ?
Sure I'll throw a patch in front of this to rename it. > > >> This can happen when multiple cores try to push a skb onto the same >> underlying hardware queue resulting in lock contention. This case is >> handled by a cpu collision handler handle_dev_cpu_collision(). Another >> case occurs when the stack overruns the drivers low level tx queues >> capacity. Ideally these should be a rare occurrence in a well-tuned >> system but they do happen. >> >> To handle this in the lockless case use a per cpu gso field to park >> the skb until the conflict can be resolved. Note at this point the >> skb has already been popped off the qdisc so it has to be handled >> by the infrastructure. > > I generally like this idea of resolving this per cpu. (I stalled here, > on the requeue issue, last time I implemented a lockless qdisc > approach). > Great, this approach seems to work OK. On another note even if we only get a single skb dequeued at a time in the initial implementation this is still a win as soon as we start running classifiers/actions. Even if doing simple pfifo_fast sans classifiers raw throughput net gain is minimal. .John -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
