On Fri, May 13, 2022 at 10:03:13AM +0200, Felix Fietkau wrote: > > On 13.05.22 09:49, Pablo Neira Ayuso wrote: > > Hi, > > > > On Tue, May 10, 2022 at 10:27:39PM +0200, Felix Fietkau wrote: > > > In many cases, it's not easily possible for user space to know, which > > > devices properly support hardware offload. > > > > Then, it is a matter of extending the netlink interface to expose this > > feature? Probably add a FLOW_BLOCK_PROBE or similar which allow to > > consult if this feature is available? > > > > > Even if a device supports hardware flow offload, it is not > > > guaranteed that it will actually be able to handle the flows for > > > which hardware offload is requested. > > > > When might this happen? > > I think there are many possible reasons: The flow might be using features > not supported by the offload driver. Maybe it doesn't have any space left in > the offload table. I'm sure there are many other possible reasons it could > fail. This fallback to software flowtable path for partial scenarios already exists. > > > Ignoring errors on the FLOW_BLOCK_BIND makes it a lot easier to set up > > > configurations that use hardware offload where possible and gracefully > > > fall back to software offload for everything else. > > > > I understand this might be useful from userspace perspective, because > > forcing the user to re-try is silly. > > > > However, on the other hand, the user should have some way to know from > > the control plane that the feature (hardware offload) that they > > request is not available for their setup. > > In my opinion, most users of this API probably don't care and just want to > have offload on a best effort basis. OK, but if the setup does not support hardware offload at all, why should the control plane accept this? I think user should know in first place that no one single flow is going to be offloaded to hardware. > Assuming that is the case, wouldn't it be better if we simply have > an API that indicates, which flowtable members hardware offload was > actually enabled for? What are you proposing? I think it would be good to expose through netlink interface what the device can actually do according to the existing supported flowtable software datapath features.
