• Daniel Borkmann's avatar
    xdp: refine xdp api with regards to generic xdp · d67b9cd2
    Daniel Borkmann authored
    While working on the iproute2 generic XDP frontend, I noticed that
    as of right now it's possible to have native *and* generic XDP
    programs loaded both at the same time for the case when a driver
    supports native XDP.
    
    The intended model for generic XDP from b5cdae32 ("net: Generic
    XDP") is, however, that only one out of the two can be present at
    once which is also indicated as such in the XDP netlink dump part.
    The main rationale for generic XDP is to ease accessibility (in
    case a driver does not yet have XDP support) and to generically
    provide a semantical model as an example for driver developers
    wanting to add XDP support. The generic XDP option for an XDP
    aware driver can still be useful for comparing and testing both
    implementations.
    
    However, it is not intended to have a second XDP processing stage
    or layer with exactly the same functionality of the first native
    stage. Only reason could be to have a partial fallback for future
    XDP features that are not supported yet in the native implementation
    and we probably also shouldn't strive for such fallback and instead
    encourage native feature support in the first place. Given there's
    currently no such fallback issue or use case, lets not go there yet
    if we don't need to.
    
    Therefore, change semantics for loading XDP and bail out if the
    user tries to load a generic XDP program when a native one is
    present and vice versa. Another alternative to bailing out would
    be to handle the transition from one flavor to another gracefully,
    but that would require to bring the device down, exchange both
    types of programs, and bring it up again in order to avoid a tiny
    window where a packet could hit both hooks. Given this complicates
    the logic for just a debugging feature in the native case, I went
    with the simpler variant.
    
    For the dump, remove IFLA_XDP_FLAGS that was added with b5cdae32
    and reuse IFLA_XDP_ATTACHED for indicating the mode. Dumping all
    or just a subset of flags that were used for loading the XDP prog
    is suboptimal in the long run since not all flags are useful for
    dumping and if we start to reuse the same flag definitions for
    load and dump, then we'll waste bit space. What we really just
    want is to dump the mode for now.
    
    Current IFLA_XDP_ATTACHED semantics are: nothing was installed (0),
    a program is running at the native driver layer (1). Thus, add a
    mode that says that a program is running at generic XDP layer (2).
    Applications will handle this fine in that older binaries will
    just indicate that something is attached at XDP layer, effectively
    this is similar to IFLA_XDP_FLAGS attr that we would have had
    modulo the redundancy.
    Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
    Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    d67b9cd2
rtnetlink.c 102 KB