Cong Wang <xiyou.wangcong@xxxxxxxxx> writes: > On Wed, Jul 13, 2022 at 01:14:08PM +0200, Toke Høiland-Jørgensen wrote: >> Packet forwarding is an important use case for XDP, which offers >> significant performance improvements compared to forwarding using the >> regular networking stack. However, XDP currently offers no mechanism to >> delay, queue or schedule packets, which limits the practical uses for >> XDP-based forwarding to those where the capacity of input and output links >> always match each other (i.e., no rate transitions or many-to-one >> forwarding). It also prevents an XDP-based router from doing any kind of >> traffic shaping or reordering to enforce policy. >> > > Sorry for forgetting to respond to your email to my patchset. > > The most important question from you is actually why I give up on PIFO. > Actually its limitation is already in its name, its name Push In First > Out already says clearly that it only allows to dequeue the first one. > Still confusing? > > You can take a look at your pifo_map_pop_elem(), which is the > implementation for bpf_map_pop_elem(), which is: > > long bpf_map_pop_elem(struct bpf_map *map, void *value) > > Clearly, there is no even 'key' in its parameter list. If you just > compare it to mine: > > BPF_CALL_2(bpf_skb_map_pop, struct bpf_map *, map, u64, key) > > Is their difference now 100% clear? :) > > The next question is why this is important (actually it is the most > important)? Because we (I mean for eBPF Qdisc users, not sure about you) > want the programmability, which I have been emphasizing since V1... Right, I realise that in a strictly abstract sense, only being able to dequeue at the head is a limitation. However, what I'm missing is what concrete thing that limitation prevents you from implementing (see my reply to your other email about LSTF)? I'm really not trying to be disingenuous, I have no interest in ending up with a map primitive that turns out to be limiting down the road... > BTW, what is _your_ use case for skb map and user-space PIFO map? I am > sure you have uses case for XDP, it is unclear what you have for other > cases. Please don't piggy back use cases you don't have, we all have > to justify all use cases. :) You keep talking about the SKB and XDP paths as though they're completely separate things. They're not: we're adding a general capability to the kernel to implement programmable packet queueing using BPF. One is for packets forwarded from the XDP hook, the other is for packets coming from the stack. In an ideal world we'd only need one hook that could handle both paths, but as the discussion I linked to in my cover letter shows that is probably not going to be feasible. So we'll most likely end up with two hooks, but as far as use cases are concerned they are the same: I want to make sure that the primitives we add are expressive enough to implement every conceivable queueing and scheduling algorithm. I don't view the two efforts to be in competition with each other either; we're really trying to achieve the same thing here, so let's work together to make sure we end up with something that works for both the XDP and qdisc layers? :) The reason I mention the SKB path in particular in this series is that I want to make sure we make the two as compatible as we can, so as not to unnecessarily fragment the ecosystem. Sharing primitives is the obvious way to do that. -Toke
