On 06/24, Stanislav Fomichev wrote: > On 06/24, Jakub Kicinski wrote: > > On Fri, 23 Jun 2023 19:52:03 -0700 Alexei Starovoitov wrote: > > > That's pretty much what I'm suggesting. > > > Add two driver specific __weak nop hook points where necessary > > > with few driver specific kfuncs. > > > Don't build generic infra when it's too early to generalize. > > > > > > It would mean that bpf progs will be driver specific, > > > but when something novel like this is being proposed it's better > > > to start with minimal code change to core kernel (ideally none) > > > and when common things are found then generalize. > > > > > > Sounds like Stanislav use case is timestamps in TX > > > while Donald's are checksums on RX, TX. These use cases are too different. > > > To make HW TX checksum compute checksum driven by AF_XDP > > > a lot more needs to be done than what Stan is proposing for timestamps. > > > > 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? :) > > > > 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
