From: David S. Miller Date: Fri, 17 Nov 2017 05:09:36 +0000 (+0900) Subject: Merge branch 'nfp-flower-fixes-and-typo-in-ethtool-stats-name' X-Git-Url: http://git.cdn.openwrt.org/?a=commitdiff_plain;h=58fedcade126c16cf466a0dd1bc59312e1a6b6f1;p=openwrt%2Fstaging%2Fblogic.git Merge branch 'nfp-flower-fixes-and-typo-in-ethtool-stats-name' Jakub Kicinski says: ==================== nfp: flower fixes and typo in ethtool stats name This set comes from the flower offload team. From Pieter we have a fix to the semantics of the flag telling FW whether to allocate or free a mask and correction of a typo in name of one of the MAC statistics (reveive -> received, we use past participle to match HW docs). Dirk fixes propagation of max MTU to representors. John improves VXLAN offload. The old code was not using egress_dev at all, so Jiri missed it in his conversion. The validation of ingress port is still not perfect, we will have to wait for shared block dust to settle to tackle it. This is how John explains the cases: The following example rule is now correctly offloaded in net-next kernel: tc filter add dev vxlan0 ... enc_dst_port 4789 ... skip_sw \ action redirect dev nfp_p0 The following rule will not be offloaded to the NFP (previously it incorrectly matched vxlan packets - it shouldn't as ingress dev is not a vxlan netdev): tc filter add dev nfp_p0 ... enc_dst_port 4789 ... skip_sw \ action redirect dev nfp_p0 Rules that are not matching on tunnels and are an egress offload are rejected. The standard match code assumes the offloaded repr is the ingress port. Rejecting egress offloads removes the chances of false interpretation of the rules on the NFP. A know issue is that the following rule example could still be offloaded and incorrectly match tunnel data: tc filter add dev dummy ... enc_dst_port 4789 ... skip_sw \ action redirect dev nfp_p0 Because the egress register callback does not give information on the ingress netdev, the patch assumes that if it is not a repr then it is the correct tunnel netdev. This may not be the case. The chances of this happening is reduced as it is enforced that the rule match on the well known vxlan port but it is still possible. ==================== Signed-off-by: David S. Miller --- 58fedcade126c16cf466a0dd1bc59312e1a6b6f1