1. 09 3月, 2015 1 次提交
  2. 04 3月, 2015 2 次提交
    • E
      neigh: Add helper function neigh_xmit · 4fd3d7d9
      Eric W. Biederman 提交于
      For MPLS I am building the code so that either the neighbour mac
      address can be specified or we can have a next hop in ipv4 or ipv6.
      
      The kind of next hop we have is indicated by the neighbour table
      pointer.  A neighbour table pointer of NULL is a link layer address.
      A non-NULL neighbour table pointer indicates which neighbour table and
      thus which address family the next hop address is in that we need to
      look up.
      
      The code either sends a packet directly or looks up the appropriate
      neighbour table entry and sends the packet.
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4fd3d7d9
    • E
      neigh: Factor out ___neigh_lookup_noref · 60395a20
      Eric W. Biederman 提交于
      While looking at the mpls code I found myself writing yet another
      version of neigh_lookup_noref.  We currently have __ipv4_lookup_noref
      and __ipv6_lookup_noref.
      
      So to make my work a little easier and to make it a smidge easier to
      verify/maintain the mpls code in the future I stopped and wrote
      ___neigh_lookup_noref.  Then I rewote __ipv4_lookup_noref and
      __ipv6_lookup_noref in terms of this new function.  I tested my new
      version by verifying that the same code is generated in
      ip_finish_output2 and ip6_finish_output2 where these functions are
      inlined.
      
      To get to ___neigh_lookup_noref I added a new neighbour cache table
      function key_eq.  So that the static size of the key would be
      available.
      
      I also added __neigh_lookup_noref for people who want to to lookup
      a neighbour table entry quickly but don't know which neibhgour table
      they are going to look up.
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      60395a20
  3. 03 3月, 2015 2 次提交
  4. 27 12月, 2014 1 次提交
  5. 12 11月, 2014 1 次提交
  6. 30 10月, 2014 1 次提交
  7. 27 9月, 2014 1 次提交
    • P
      netfilter: bridge: move br_netfilter out of the core · 34666d46
      Pablo Neira Ayuso 提交于
      Jesper reported that br_netfilter always registers the hooks since
      this is part of the bridge core. This harms performance for people that
      don't need this.
      
      This patch modularizes br_netfilter so it can be rmmod'ed, thus,
      the hooks can be unregistered. I think the bridge netfilter should have
      been a separated module since the beginning, Patrick agreed on that.
      
      Note that this is breaking compatibility for users that expect that
      bridge netfilter is going to be available after explicitly 'modprobe
      bridge' or via automatic load through brctl.
      
      However, the damage can be easily undone by modprobing br_netfilter.
      The bridge core also spots a message to provide a clue to people that
      didn't notice that this has been deprecated.
      
      On top of that, the plan is that nftables will not rely on this software
      layer, but integrate the connection tracking into the bridge layer to
      enable stateful filtering and NAT, which is was bridge netfilter users
      seem to require.
      
      This patch still keeps the fake_dst_ops in the bridge core, since this
      is required by when the bridge port is initialized. So we can safely
      modprobe/rmmod br_netfilter anytime.
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      Acked-by: NFlorian Westphal <fw@strlen.de>
      34666d46
  8. 15 7月, 2014 1 次提交
  9. 17 1月, 2014 1 次提交
  10. 12 12月, 2013 1 次提交
    • J
      ipv6: router reachability probing · 7e980569
      Jiri Benc 提交于
      RFC 4191 states in 3.5:
      
         When a host avoids using any non-reachable router X and instead sends
         a data packet to another router Y, and the host would have used
         router X if router X were reachable, then the host SHOULD probe each
         such router X's reachability by sending a single Neighbor
         Solicitation to that router's address.  A host MUST NOT probe a
         router's reachability in the absence of useful traffic that the host
         would have sent to the router if it were reachable.  In any case,
         these probes MUST be rate-limited to no more than one per minute per
         router.
      
      Currently, when the neighbour corresponding to a router falls into
      NUD_FAILED, it's never considered again. Introduce a new rt6_nud_state
      value, RT6_NUD_FAIL_PROBE, which suggests the route should not be used but
      should be probed with a single NS. The probe is ratelimited by the existing
      code. To better distinguish meanings of the failure values, rename
      RT6_NUD_FAIL_SOFT to RT6_NUD_FAIL_DO_RR.
      Signed-off-by: NJiri Benc <jbenc@redhat.com>
      Acked-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7e980569
  11. 10 12月, 2013 4 次提交
  12. 01 8月, 2013 1 次提交
  13. 11 2月, 2013 1 次提交
  14. 29 1月, 2013 1 次提交
    • Y
      net neigh: Optimize neighbor entry size calculation. · 08433eff
      YOSHIFUJI Hideaki / 吉藤英明 提交于
      When allocating memory for neighbour cache entry, if
      tbl->entry_size is not set, we always calculate
      sizeof(struct neighbour) + tbl->key_len, which is common
      in the same table.
      
      With this change, set tbl->entry_size during the table
      initialization phase, if it was not set, and use it in
      neigh_alloc() and neighbour_priv().
      
      This change also allow us to have both of protocol private
      data and device priate data at tha same time.
      
      Note that the only user of prototcol private is DECnet
      and the only user of device private is ATM CLIP.
      Since those are exclusive, we have not been facing issues
      here.
      Signed-off-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      08433eff
  15. 08 8月, 2012 1 次提交
    • E
      net: output path optimizations · 425f09ab
      Eric Dumazet 提交于
      1) Avoid dirtying neighbour's confirmed field.
      
        TCP workloads hits this cache line for each incoming ACK.
        Lets write n->confirmed only if there is a jiffie change.
      
      2) Optimize neigh_hh_output() for the common Ethernet case, were
         hh_len is less than 16 bytes. Replace the memcpy() call
         by two inlined 64bit load/stores on x86_64.
      
      Bench results using udpflood test, with -C option (MSG_CONFIRM flag
      added to sendto(), to reproduce the n->confirmed dirtying on UDP)
      
      24 threads doing 1.000.000 UDP sendto() on dummy device, 4 runs.
      
      before : 2.247s, 2.235s, 2.247s, 2.318s
      after  : 1.884s, 1.905s, 1.891s, 1.895s
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      425f09ab
  16. 05 7月, 2012 2 次提交
  17. 16 4月, 2012 1 次提交
  18. 14 4月, 2012 1 次提交
  19. 29 12月, 2011 1 次提交
  20. 20 12月, 2011 1 次提交
  21. 14 12月, 2011 1 次提交
  22. 01 12月, 2011 2 次提交
  23. 14 11月, 2011 1 次提交
    • E
      neigh: new unresolved queue limits · 8b5c171b
      Eric Dumazet 提交于
      Le mercredi 09 novembre 2011 à 16:21 -0500, David Miller a écrit :
      > From: David Miller <davem@davemloft.net>
      > Date: Wed, 09 Nov 2011 16:16:44 -0500 (EST)
      >
      > > From: Eric Dumazet <eric.dumazet@gmail.com>
      > > Date: Wed, 09 Nov 2011 12:14:09 +0100
      > >
      > >> unres_qlen is the number of frames we are able to queue per unresolved
      > >> neighbour. Its default value (3) was never changed and is responsible
      > >> for strange drops, especially if IP fragments are used, or multiple
      > >> sessions start in parallel. Even a single tcp flow can hit this limit.
      > >  ...
      > >
      > > Ok, I've applied this, let's see what happens :-)
      >
      > Early answer, build fails.
      >
      > Please test build this patch with DECNET enabled and resubmit.  The
      > decnet neigh layer still refers to the removed ->queue_len member.
      >
      > Thanks.
      
      Ouch, this was fixed on one machine yesterday, but not the other one I
      used this morning, sorry.
      
      [PATCH V5 net-next] neigh: new unresolved queue limits
      
      unres_qlen is the number of frames we are able to queue per unresolved
      neighbour. Its default value (3) was never changed and is responsible
      for strange drops, especially if IP fragments are used, or multiple
      sessions start in parallel. Even a single tcp flow can hit this limit.
      
      $ arp -d 192.168.20.108 ; ping -c 2 -s 8000 192.168.20.108
      PING 192.168.20.108 (192.168.20.108) 8000(8028) bytes of data.
      8008 bytes from 192.168.20.108: icmp_seq=2 ttl=64 time=0.322 ms
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8b5c171b
  24. 27 7月, 2011 1 次提交
  25. 18 7月, 2011 1 次提交
  26. 17 7月, 2011 4 次提交
  27. 14 7月, 2011 1 次提交
    • D
      net: Embed hh_cache inside of struct neighbour. · f6b72b62
      David S. Miller 提交于
      Now that there is a one-to-one correspondance between neighbour
      and hh_cache entries, we no longer need:
      
      1) dynamic allocation
      2) attachment to dst->hh
      3) refcounting
      
      Initialization of the hh_cache entry is indicated by hh_len
      being non-zero, and such initialization is always done with
      the neighbour's lock held as a writer.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f6b72b62
  28. 11 7月, 2011 1 次提交
    • D
      neigh: Store hash shift instead of mask. · cd089336
      David S. Miller 提交于
      And mask the hash function result by simply shifting
      down the "->hash_shift" most significant bits.
      
      Currently which bits we use is arbitrary since jhash
      produces entropy evenly across the whole hash function
      result.
      
      But soon we'll be using universal hashing functions,
      and in those cases more entropy exists in the higher
      bits than the lower bits, because they use multiplies.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cd089336
  29. 19 11月, 2010 1 次提交
  30. 12 11月, 2010 1 次提交