On Mon, Jun 26, 2023 at 3:37 PM Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > On Mon, Jun 26, 2023 at 2:36 PM Stanislav Fomichev <sdf@xxxxxxxxxx> wrote: > > > > > > > > > > I'd think HW TX csum is actually simpler than dealing with time, > > > > will you change your mind if Stan posts Tx csum within a few days? :) > > Absolutely :) Happy to change my mind. > > > > > The set of offloads is barely changing, the lack of clarity > > > > on what is needed seems overstated. IMHO AF_XDP is getting no use > > > > today, because everything remotely complex was stripped out of > > > > the implementation to get it merged. Aren't we hand waving the > > > > complexity away simply because we don't want to deal with it? > > > > > > > > These are the features today's devices support (rx/tx is a mirror): > > > > - L4 csum > > > > - segmentation > > > > - time reporting > > > > > > > > Some may also support: > > > > - forwarding md tagging > > > > - Tx launch time > > > > - no fcs > > > > Legacy / irrelevant: > > > > - VLAN insertion > > > > > > Right, the goal of the series is to lay out the foundation to support > > > AF_XDP offloads. I'm starting with tx timestamp because that's more > > > pressing. But, as I mentioned in another thread, we do have other > > > users that want to adopt AF_XDP, but due to missing tx offloads, they > > > aren't able to. > > > > > > IMHO, with pre-tx/post-tx hooks, it's pretty easy to go from TX > > > timestamp to TX checksum offload, we don't need a lot: > > > - define another generic kfunc bpf_request_tx_csum(from, to) > > > - drivers implement it > > > - af_xdp users call this kfunc from devtx hook > > > > > > We seem to be arguing over start-with-my-specific-narrow-use-case vs > > > start-with-generic implementation, so maybe time for the office hours? > > > I can try to present some cohesive plan of how we start with the framework > > > plus tx-timestamp and expand with tx-checksum/etc. There is a lot of > > > commonality in these offloads, so I'm probably not communicating it > > > properly.. > > > > Or, maybe a better suggestion: let me try to implement TX checksum > > kfunc in the v3 (to show how to build on top this series). > > Having code is better than doing slides :-D > > That would certainly help :) > What I got out of your lsfmmbpf talk is that timestamp is your > main and only use case. tx checksum for af_xdp is the other use case, > but it's not yours, so you sort-of use it as an extra justification > for timestamp. Hence my negative reaction to 'generality'. > I think we'll have better results in designing an api > when we look at these two use cases independently. > And implement them in patches solving specifically timestamp > with normal skb traffic and tx checksum for af_xdp as two independent apis. > If it looks like we can extract a common framework out of them. Great. > But trying to generalize before truly addressing both cases > is likely to cripple both apis. I need timestamps for the af_xdp case and I don't really care about skb :-( I brought skb into the picture mostly to cover John's cases. So maybe let's drop the skb case for now and focus on af_xdp? skb is convenient testing-wise though (with veth), but maybe I can somehow carve-out af_xdp skbs only out of it.. Regarding timestamp vs checksum: timestamp is more pressing, but I do have people around that want to use af_xdp but need multibuf + tx offloads, so I was hoping to at least have a path for more tx offloads after we're done with tx timestamp "offload".. > It doesn't have to be only two use cases. > I completely agree with Kuba that: > - L4 csum > - segmentation > - time reporting > are universal HW NIC features and we need to have an api > that exposes these features in programmable way to bpf progs in the kernel > and through af_xdp to user space. > I mainly suggest addressing them one by one and look > for common code bits and api similarities later. Ack, let me see if I can fit tx csum into the picture. I still feel like we need these dev-bound tracing programs if we want to trigger kfuncs safely, but maybe we can simplify further..
