On 06/13, Jakub Kicinski wrote: > On Tue, 13 Jun 2023 20:54:26 -0700 David Ahern wrote: > > On 6/13/23 9:31 PM, Jakub Kicinski wrote: > > > On Mon, 12 Jun 2023 10:23:00 -0700 Stanislav Fomichev wrote: > > >> The goal of this series is to add two new standard-ish places > > >> in the transmit path: > > >> > > >> 1. Right before the packet is transmitted (with access to TX > > >> descriptors) > > > > If a device requires multiple Tx descriptors per skb or multibuf frame, > > how would that be handled within the XDP API? > > > > > I'm not sure that the Tx descriptors can be populated piecemeal. > > > > If it is host memory before the pidx move, why would that matter? Do you > > have a specific example in mind? > > I don't mean it's impossible implement, but it's may get cumbersome. > TSO/CSO/crypto may all need to know where L4 header starts, f.e. > Some ECN marking in the NIC may also want to know where L3 is. > So the offsets will get duplicated in each API. > > > > If we were ever to support more standard offload features, which > > > require packet geometry (hdr offsets etc.) to be described "call > > > per feature" will end up duplicating arguments, and there will be > > > a lot of args.. > > > > > > And if there is an SKB path in the future combining the normal SKB > > > offloads with the half-rendered descriptors may be a pain. > > > > Once the descriptor(s) is (are) populated, the skb is irrelevant is it > > not? Only complication that comes to mind is wanting to add or remove > > headers (e.g., tunnels) which will be much more complicated at this > > point, but might still be possible on a per NIC (and maybe version) basis. > > I guess one can write the skb descriptors first, then modify them from > the BPF. Either way I feel like the helper approach for Tx will result > in drivers saving the info into some local struct and then rendering > the descriptors after. We'll see. I agree that it's probably the "easiest" option to implement for the majority of the devices that were designed without much of a programmability this late in the stack. But maybe some devices can or at least we can try to influence future designs :-)
