On Mon, Sep 23, 2019 at 5:21 PM wenxu <we...@ucloud.cn> wrote: > 在 2019/9/23 17:42, John Hurley 写道: > > On Mon, Sep 23, 2019 at 5:20 AM wenxu <we...@ucloud.cn> wrote: > >> Hi John & Jakub > >> > >> There are some limitations for indirect tc callback work with skip_sw ? > >> > > Hi Wenxu, > > This is not really a limitation. > > As Or points out, indirect block offload is not supposed to work with > > skip_sw. > > Indirect offload allows us to hook onto existing kernel devices (for > > TC events we may which to offload) that are out of the control of the > > offload driver and, therefore, should always accept software path > > rules. > > For example, the vxlan driver does not implement a setup_tc ndo so it > > does not expect to run rules in hw - it should always handle > > associated rules in the software datapath as a minimum. > > I think accepting skip_sw rules for devices with no in-built concept > > of hardware offload would be wrong. > > Do you have a use case that requires skip_sw rules for such devices?
> When we use ovs to control the tc offload. The ovs kernel already provide the > software > path rules so maybe user don't want other soft path. this (programming the rule to both tc and ovs kernel DPs) is a choice made by the ovs user-space code and could change later. Actually, for complex use case such as connection tracking, there might be cases when multiple tables are used, when the 1st packet/s would jump before hw to sw TC tables, so using skip_sw will likely not to work and we'll get bug reports. The production TC configuration we use/recommend with for overlay networks e-switching is "both" (== "none", i.e none of skip_sw or skip_hw). > And with skip_sw it can be easily distinguish offloaded and non-offloaded > rules. per tc rule, the kernel reports on offloaded vs not offloaded packet/bytes, so the info is there. In the system level, I don't think it's good that on point A in time we blocked skip_sw rules for tunnel devices and at point B we enabled it for no real/good reason, I vote for blocking it again, since as Pieter explained disallowing this is not consistent with the kernel SW model on the receiving side.
