1. 15 Jun, 2021 4 commits
    • Peng Li's avatar
      net: z85230: add blank line after declarations · 61312d78
      Peng Li authored
      This patch fixes the checkpatch error about missing a blank line
      after declarations.
      Signed-off-by: default avatarPeng Li <lipeng321@huawei.com>
      Signed-off-by: default avatarGuangbin Huang <huangguangbin2@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      61312d78
    • Peng Li's avatar
      net: z85230: remove redundant blank lines · 336bac5e
      Peng Li authored
      This patch removes some redundant blank lines.
      Signed-off-by: default avatarPeng Li <lipeng321@huawei.com>
      Signed-off-by: default avatarGuangbin Huang <huangguangbin2@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      336bac5e
    • Boris Sukholitko's avatar
      net/sched: cls_flower: Remove match on n_proto · 0dca2c74
      Boris Sukholitko authored
      The following flower filters fail to match packets:
      
      tc filter add dev eth0 ingress protocol 0x8864 flower \
      	action simple sdata hi64
      tc filter add dev eth0 ingress protocol 802.1q flower \
      	vlan_ethtype 0x8864 action simple sdata "hi vlan"
      
      The protocol 0x8864 (ETH_P_PPP_SES) is a tunnel protocol. As such, it is
      being dissected by __skb_flow_dissect and it's internal protocol is
      being set as key->basic.n_proto. IOW, the existence of ETH_P_PPP_SES
      tunnel is transparent to the callers of __skb_flow_dissect.
      
      OTOH, in the filters above, cls_flower configures its key->basic.n_proto
      to the ETH_P_PPP_SES value configured by the user. Matching on this key
      fails because of __skb_flow_dissect "transparency" mentioned above.
      
      In the following, I would argue that the problem lies with cls_flower,
      unnessary attempting key->basic.n_proto match.
      
      There are 3 close places in fl_set_key in cls_flower setting up
      mask->basic.n_proto. They are (in reverse order of appearance in the
      code) due to:
      
      (a) No vlan is given: use TCA_FLOWER_KEY_ETH_TYPE parameter
      (b) One vlan tag is given: use TCA_FLOWER_KEY_VLAN_ETH_TYPE
      (c) Two vlans are given: use TCA_FLOWER_KEY_CVLAN_ETH_TYPE
      
      The match in case (a) is unneeded because flower has no its own
      eth_type parameter. It was removed by Jamal Hadi Salim in commit
      488b41d020fb06428b90289f70a41210718f52b7 in iproute2. For
      TCA_FLOWER_KEY_ETH_TYPE the userspace uses the generic tc filter
      protocol field. Therefore the match for the case (a) is done by tc
      itself.
      
      The matches in cases (b), (c) are unneeded because the protocol will
      appear in and will be matched by flow_dissector_key_vlan.vlan_tpid.
      Therefore in the best case, key->basic.n_proto will try to repeat vlan
      key match again.
      
      The below patch removes mask->basic.n_proto setting and resets it to 0
      in case (c).
      Signed-off-by: default avatarBoris Sukholitko <boris.sukholitko@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0dca2c74
    • Matteo Croce's avatar
      stmmac: align RX buffers · a955318f
      Matteo Croce authored
      On RX an SKB is allocated and the received buffer is copied into it.
      But on some architectures, the memcpy() needs the source and destination
      buffers to have the same alignment to be efficient.
      
      This is not our case, because SKB data pointer is misaligned by two bytes
      to compensate the ethernet header.
      
      Align the RX buffer the same way as the SKB one, so the copy is faster.
      An iperf3 RX test gives a decent improvement on a RISC-V machine:
      
      before:
      [ ID] Interval           Transfer     Bitrate         Retr
      [  5]   0.00-10.00  sec   733 MBytes   615 Mbits/sec   88             sender
      [  5]   0.00-10.01  sec   730 MBytes   612 Mbits/sec                  receiver
      
      after:
      [ ID] Interval           Transfer     Bitrate         Retr
      [  5]   0.00-10.00  sec  1.10 GBytes   942 Mbits/sec    0             sender
      [  5]   0.00-10.00  sec  1.09 GBytes   940 Mbits/sec                  receiver
      
      And the memcpy() overhead during the RX drops dramatically.
      
      before:
      Overhead  Shared O  Symbol
        43.35%  [kernel]  [k] memcpy
        33.77%  [kernel]  [k] __asm_copy_to_user
         3.64%  [kernel]  [k] sifive_l2_flush64_range
      
      after:
      Overhead  Shared O  Symbol
        45.40%  [kernel]  [k] __asm_copy_to_user
        28.09%  [kernel]  [k] memcpy
         4.27%  [kernel]  [k] sifive_l2_flush64_range
      Signed-off-by: default avatarMatteo Croce <mcroce@microsoft.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a955318f
  2. 14 Jun, 2021 36 commits