1. 30 Sep, 2020 6 commits
    • Vladimir Oltean's avatar
      net: mscc: ocelot: add definitions for VCAP ES0 keys, actions and target · e3aea296
      Vladimir Oltean authored
      As a preparation step for the offloading to ES0, let's create the
      infrastructure for talking with this hardware block.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e3aea296
    • Vladimir Oltean's avatar
      net: mscc: ocelot: add definitions for VCAP IS1 keys, actions and target · a61e365d
      Vladimir Oltean authored
      As a preparation step for the offloading to IS1, let's create the
      infrastructure for talking with this hardware block.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a61e365d
    • Vladimir Oltean's avatar
      net: mscc: ocelot: generalize existing code for VCAP · c1c3993e
      Vladimir Oltean authored
      In the Ocelot switches there are 3 TCAMs: VCAP ES0, IS1 and IS2, which
      have the same configuration interface, but different sets of keys and
      actions. The driver currently only supports VCAP IS2.
      
      In preparation of VCAP IS1 and ES0 support, the existing code must be
      generalized to work with any VCAP.
      
      In that direction, we should move the structures that depend upon VCAP
      instantiation, like vcap_is2_keys and vcap_is2_actions, out of struct
      ocelot and into struct vcap_props .keys and .actions, a structure that
      is replicated 3 times, once per VCAP. We'll pass that structure as an
      argument to each function that does the key and action packing - only
      the control logic needs to distinguish between ocelot->vcap[VCAP_IS2]
      or IS1 or ES0.
      
      Another change is to make use of the newly introduced ocelot_target_read
      and ocelot_target_write API, since the 3 VCAPs have the same registers
      but put at different addresses.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c1c3993e
    • 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 34 commits