1. 15 Jun, 2021 3 commits
    • 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
  3. 13 Jun, 2021 1 commit
    • David S. Miller's avatar
      Merge branch 'iosm-driver' · a212d9f3
      David S. Miller authored
      M Chetan Kumar says:
      
      ====================
      net: iosm: PCIe Driver for Intel M.2 Modem
      
      The IOSM (IPC over Shared Memory) driver is a PCIe host driver implemented
      for linux or chrome platform for data exchange over PCIe interface between
      Host platform & Intel M.2 Modem. The driver exposes interface conforming to
      the MBIM protocol. Any front end application ( eg: Modem Manager) could
      easily manage the MBIM interface to enable data communication towards WWAN.
      
      Intel M.2 modem uses 2 BAR regions. The first region is dedicated to Doorbell
      register for IRQs and the second region is used as scratchpad area for book
      keeping modem execution stage details along with host system shared memory
      region context details. The upper edge of the driver exposes the control and
      data channels for user space application interaction. At lower edge these data
      and control channels are associated to pipes. The pipes are lowest level
      interfaces used over PCIe as a logical channel for message exchange. A single
      channel maps to UL and DL pipe and are initialized on device open.
      
      On UL path, driver copies application sent data to SKBs associate it with
      transfer descriptor and puts it on to ring buffer for DMA transfer. Once
      information has been updated in shared memory region, host gives a Doorbell
      to modem to perform DMA and modem uses MSI to communicate back to host.
      For receiving data in DL path, SKBs are pre-allocated during pipe open and
      transfer descriptors are given to modem for DMA transfer.
      
      The driver exposes two types of ports, namely "wwan0mbim0", a char device node
      which is used for MBIM control operation and "wwan0-x",(x = 0,1,2..7) network
      interfaces for IP data communication.
      1) MBIM Control Interface:
      This node exposes an interface between modem and application using char device
      exposed by "IOSM" driver to establish and manage the MBIM data communication
      with PCIe based Intel M.2 Modems.
      
      2) MBIM Data Interface:
      The IOSM driver exposes IP link interface "wwan0-x" of type "wwan" for IP traffic.
      Iproute network utility is used for creating "wwan0-x" network interface and for
      associating it with MBIM IP session. The Driver supports upto 8 IP sessions for
      simultaneous IP communication.
      
      This applies on top of WWAN core rtnetlink series posted here:
      https://lore.kernel.org/netdev/1623486057-13075-1-git-send-email-loic.poulain@linaro.org/
      
      Also driver has been compiled and tested on top of netdev net-next tree.
      https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a212d9f3