1. 23 4月, 2017 1 次提交
  2. 12 4月, 2017 1 次提交
  3. 29 3月, 2017 1 次提交
    • A
      devlink: Support for pipeline debug (dpipe) · 1555d204
      Arkadi Sharshevsky 提交于
      The pipeline debug is used to export the pipeline abstractions for the
      main objects - tables, headers and entries. The only support for set is
      for changing the counter parameter on specific table.
      
      The basic structures:
      
      Header - can represent a real protocol header information or internal
               metadata. Generic protocol headers like IPv4 can be shared
               between drivers. Each driver can add local headers.
      
      Field - part of a header. Can represent protocol field or specific ASIC
              metadata field. Hardware special metadata fields can be mapped
              to different resources, for example switch ASIC ports can have
              internal number which from the systems point of view is mapped
              to netdeivce ifindex.
      
      Match - represent specific match rule. Can describe match on specific
              field or header. The header index should be specified as well
              in order to support several header instances of the same type
              (tunneling).
      
      Action - represents specific action rule. Actions can describe operations
               on specific field values for example like set, increment, etc.
               And header operation like add and delete.
      
      Value - represents value which can be associated with specific match or
              action.
      
      Table - represents a hardware block which can be described with match/
              action behavior. The match/action can be done on the packets
              data or on the internal metadata that it gathered along the
              packets traversal throw the pipeline which is vendor specific
              and should be exported in order to provide understanding of
              ASICs behavior.
      
      Entry - represents single record in a specific table. The entry is
              identified by specific combination of values for match/action.
      
      Prior to accessing the tables/entries the drivers provide the header/
      field data base which is used by driver to user-space. The data base
      is split between the shared headers and unique headers.
      Signed-off-by: NArkadi Sharshevsky <arkadis@mellanox.com>
      Signed-off-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1555d204
  4. 11 2月, 2017 4 次提交
  5. 25 11月, 2016 1 次提交
  6. 28 10月, 2016 3 次提交
    • J
      genetlink: mark families as __ro_after_init · 56989f6d
      Johannes Berg 提交于
      Now genl_register_family() is the only thing (other than the
      users themselves, perhaps, but I didn't find any doing that)
      writing to the family struct.
      
      In all families that I found, genl_register_family() is only
      called from __init functions (some indirectly, in which case
      I've add __init annotations to clarifly things), so all can
      actually be marked __ro_after_init.
      
      This protects the data structure from accidental corruption.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      56989f6d
    • J
      genetlink: statically initialize families · 489111e5
      Johannes Berg 提交于
      Instead of providing macros/inline functions to initialize
      the families, make all users initialize them statically and
      get rid of the macros.
      
      This reduces the kernel code size by about 1.6k on x86-64
      (with allyesconfig).
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      489111e5
    • J
      genetlink: no longer support using static family IDs · a07ea4d9
      Johannes Berg 提交于
      Static family IDs have never really been used, the only
      use case was the workaround I introduced for those users
      that assumed their family ID was also their multicast
      group ID.
      
      Additionally, because static family IDs would never be
      reserved by the generic netlink code, using a relatively
      low ID would only work for built-in families that can be
      registered immediately after generic netlink is started,
      which is basically only the control family (apart from
      the workaround code, which I also had to add code for so
      it would reserve those IDs)
      
      Thus, anything other than GENL_ID_GENERATE is flawed and
      luckily not used except in the cases I mentioned. Move
      those workarounds into a few lines of code, and then get
      rid of GENL_ID_GENERATE entirely, making it more robust.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a07ea4d9
  7. 27 10月, 2016 1 次提交
  8. 13 7月, 2016 1 次提交
  9. 03 7月, 2016 1 次提交
  10. 15 4月, 2016 2 次提交
  11. 09 4月, 2016 2 次提交
  12. 02 3月, 2016 1 次提交
    • J
      Introduce devlink infrastructure · bfcd3a46
      Jiri Pirko 提交于
      Introduce devlink infrastructure for drivers to register and expose to
      userspace via generic Netlink interface.
      
      There are two basic objects defined:
      devlink - one instance for every "parent device", for example switch ASIC
      devlink port - one instance for every physical port of the device.
      
      This initial portion implements basic get/dump of objects to userspace.
      Also, port splitter and port type setting is implemented.
      Signed-off-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bfcd3a46