1. 30 Sep, 2020 3 commits
    • Xiaoliang Yang's avatar
      net: mscc: ocelot: return error if VCAP filter is not found · ed5672d8
      Xiaoliang Yang authored
      Although it doesn't look like it is possible to hit these conditions
      from user space, there are 2 separate, but related, issues.
      
      First, the ocelot_vcap_block_get_filter_index function, née
      ocelot_ace_rule_get_index_id prior to the aae4e500 ("net: mscc:
      ocelot: generalize the "ACE/ACL" names") rename, does not do what the
      author probably intended. If the desired filter entry is not present in
      the ACL block, this function returns an index equal to the total number
      of filters, instead of -1, which is maybe what was intended, judging
      from the curious initialization with -1, and the "++index" idioms.
      Either way, none of the callers seems to expect this behavior.
      
      Second issue, the callers don't actually check the return value at all.
      So in case the filter is not found in the rule list, propagate the
      return code.
      
      So update the callers and also take the opportunity to get rid of the
      odd coding idioms that appear to work but don't.
      Signed-off-by: default avatarXiaoliang Yang <xiaoliang.yang_1@nxp.com>
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ed5672d8
    • Vladimir Oltean's avatar
      net: mscc: ocelot: introduce a new ocelot_target_{read,write} API · 3c0e37a9
      Vladimir Oltean authored
      There are some targets (register blocks) in the Ocelot switch that are
      instantiated more than once. For example, the VCAP IS1, IS2 and ES0
      blocks all share the same register layout for interacting with the cache
      for the TCAM and the action RAM.
      
      For the VCAPs, the procedure for servicing them is actually common. We
      just need an API specifying which VCAP we are talking to, and we do that
      via these raw ocelot_target_read and ocelot_target_write accessors.
      
      In plain ocelot_read, the target is encoded into the register enum
      itself:
      
      	u16 target = reg >> TARGET_OFFSET;
      
      For the VCAPs, the registers are currently defined like this:
      
      	enum ocelot_reg {
      	[...]
      		S2_CORE_UPDATE_CTRL = S2 << TARGET_OFFSET,
      		S2_CORE_MV_CFG,
      		S2_CACHE_ENTRY_DAT,
      		S2_CACHE_MASK_DAT,
      		S2_CACHE_ACTION_DAT,
      		S2_CACHE_CNT_DAT,
      		S2_CACHE_TG_DAT,
      	[...]
      	};
      
      which is precisely what we want to avoid, because we'd have to duplicate
      the same register map for S1 and for S0, and then figure out how to pass
      VCAP instance-specific registers to the ocelot_read calls (basically
      another lookup table that undoes the effect of shifting with
      TARGET_OFFSET).
      
      So for some targets, propose a more raw API, similar to what is
      currently done with ocelot_port_readl and ocelot_port_writel. Those
      targets can only be accessed with ocelot_target_{read,write} and not
      with ocelot_{read,write} after the conversion, which is fine.
      
      The VCAP registers are not actually modified to use this new API as of
      this patch. They will be modified in the next one.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Acked-by: default avatarAlexandre Belloni <alexandre.belloni@bootlin.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3c0e37a9
    • Lorenzo Bianconi's avatar
      net: mvneta: avoid possible cache misses in mvneta_rx_swbm · 879456be
      Lorenzo Bianconi authored
      Do not use rx_desc pointers if possible since rx descriptors are stored in
      uncached memory and dereferencing rx_desc pointers generate extra loads.
      This patch improves XDP_DROP performance of ~ 110Kpps (700Kpps vs 590Kpps)
      on Marvell Espressobin
      Analyzed-by: default avatarIlias Apalodimas <ilias.apalodimas@linaro.org>
      Signed-off-by: default avatarLorenzo Bianconi <lorenzo@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      879456be
  2. 29 Sep, 2020 37 commits