Eric Lee / smarc-fsl-linux-kernel

18 Mar, 2020

1 commit

31 May, 2019

1 commit

  • 2874c5fd2   treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 152 ... Browse Code »

    Based on 1 normalized pattern(s):

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public license as published by
    the free software foundation either version 2 of the license or at
    your option any later version

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-or-later

    has been chosen to replace the boilerplate/reference in 3029 file(s).

    Signed-off-by: Thomas Gleixner
    Reviewed-by: Allison Randal
    Cc: linux-spdx@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.de
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

08 Apr, 2019

1 commit

  • 8f0db0180   rhashtable: use bit_spin_locks to protect hash bucket. ... Browse Code »

    This patch changes rhashtables to use a bit_spin_lock on BIT(1) of the
    bucket pointer to lock the hash chain for that bucket.

    The benefits of a bit spin_lock are:
    - no need to allocate a separate array of locks.
    - no need to have a configuration option to guide the
    choice of the size of this array
    - locking cost is often a single test-and-set in a cache line
    that will have to be loaded anyway. When inserting at, or removing
    from, the head of the chain, the unlock is free - writing the new
    address in the bucket head implicitly clears the lock bit.
    For __rhashtable_insert_fast() we ensure this always happens
    when adding a new key.
    - even when lockings costs 2 updates (lock and unlock), they are
    in a cacheline that needs to be read anyway.

    The cost of using a bit spin_lock is a little bit of code complexity,
    which I think is quite manageable.

    Bit spin_locks are sometimes inappropriate because they are not fair -
    if multiple CPUs repeatedly contend of the same lock, one CPU can
    easily be starved. This is not a credible situation with rhashtable.
    Multiple CPUs may want to repeatedly add or remove objects, but they
    will typically do so at different buckets, so they will attempt to
    acquire different locks.

    As we have more bit-locks than we previously had spinlocks (by at
    least a factor of two) we can expect slightly less contention to
    go with the slightly better cache behavior and reduced memory
    consumption.

    To enhance type checking, a new struct is introduced to represent the
    pointer plus lock-bit
    that is stored in the bucket-table. This is "struct rhash_lock_head"
    and is empty. A pointer to this needs to be cast to either an
    unsigned lock, or a "struct rhash_head *" to be useful.
    Variables of this type are most often called "bkt".

    Previously "pprev" would sometimes point to a bucket, and sometimes a
    ->next pointer in an rhash_head. As these are now different types,
    pprev is NULL when it would have pointed to the bucket. In that case,
    'blk' is used, together with correct locking protocol.

    Signed-off-by: NeilBrown
    Signed-off-by: David S. Miller

    NeilBrown
     

18 Feb, 2017

1 commit

04 Feb, 2017

2 commits

  • 11538d039   bridge: vlan dst_metadata hooks in ingress and egress paths ... Browse Code »

    - ingress hook:
    - if port is a tunnel port, use tunnel info in
    attached dst_metadata to map it to a local vlan
    - egress hook:
    - if port is a tunnel port, use tunnel info attached to
    vlan to set dst_metadata on the skb

    CC: Nikolay Aleksandrov
    Signed-off-by: Roopa Prabhu
    Signed-off-by: David S. Miller

    Roopa Prabhu
     
  • efa5356b0   bridge: per vlan dst_metadata netlink support ... Browse Code »

    This patch adds support to attach per vlan tunnel info dst
    metadata. This enables bridge driver to map vlan to tunnel_info
    at ingress and egress. It uses the kernel dst_metadata infrastructure.

    The initial use case is vlan to vni bridging, but the api is generic
    to extend to any tunnel_info in the future:
    - Uapi to configure/unconfigure/dump per vlan tunnel data
    - netlink functions to configure vlan and tunnel_info mapping
    - Introduces bridge port flag BR_LWT_VLAN to enable attach/detach
    dst_metadata to bridged packets on ports. off by default.
    - changes to existing code is mainly refactor some existing vlan
    handling netlink code + hooks for new vlan tunnel code
    - I have kept the vlan tunnel code isolated in separate files.
    - most of the netlink vlan tunnel code is handling of vlan-tunid
    ranges (follows the vlan range handling code). To conserve space
    vlan-tunid by default are always dumped in ranges if applicable.

    Use case:
    example use for this is a vxlan bridging gateway or vtep
    which maps vlans to vn-segments (or vnis).

    iproute2 example (patched and pruned iproute2 output to just show
    relevant fdb entries):
    example shows same host mac learnt on two vni's and
    vlan 100 maps to vni 1000, vlan 101 maps to vni 1001

    before (netdev per vni):
    $bridge fdb show | grep "00:02:00:00:00:03"
    00:02:00:00:00:03 dev vxlan1001 vlan 101 master bridge
    00:02:00:00:00:03 dev vxlan1001 dst 12.0.0.8 self
    00:02:00:00:00:03 dev vxlan1000 vlan 100 master bridge
    00:02:00:00:00:03 dev vxlan1000 dst 12.0.0.8 self

    after this patch with collect metdata in bridged mode (single netdev):
    $bridge fdb show | grep "00:02:00:00:00:03"
    00:02:00:00:00:03 dev vxlan0 vlan 101 master bridge
    00:02:00:00:00:03 dev vxlan0 src_vni 1001 dst 12.0.0.8 self
    00:02:00:00:00:03 dev vxlan0 vlan 100 master bridge
    00:02:00:00:00:03 dev vxlan0 src_vni 1000 dst 12.0.0.8 self

    CC: Nikolay Aleksandrov
    Signed-off-by: Roopa Prabhu
    Signed-off-by: David S. Miller

    Roopa Prabhu