1. 08 7月, 2014 35 次提交
  2. 03 7月, 2014 5 次提交
    • D
      Merge branch 'sctp' · 239960d6
      David S. Miller 提交于
      Daniel Borkmann says:
      
      ====================
      Misc SCTP updates
      
      Daniel Borkmann (2):
        net: sctp: improve timer slack calculation for transport HBs
        net: sctp: only warn in proc_sctp_do_alpha_beta if write
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Acked-by: NNeil Horman <nhorman@tuxdriver.com>
      239960d6
    • D
      net: sctp: only warn in proc_sctp_do_alpha_beta if write · eaea2da7
      Daniel Borkmann 提交于
      Only warn if the value is written to alpha or beta. We don't care
      emitting a one-time warning when only reading it.
      Reported-by: NJiri Pirko <jpirko@redhat.com>
      Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
      Reviewed-by: NJiri Pirko <jiri@resnulli.us>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      eaea2da7
    • D
      net: sctp: improve timer slack calculation for transport HBs · 8f61059a
      Daniel Borkmann 提交于
      RFC4960, section 8.3 says:
      
        On an idle destination address that is allowed to heartbeat,
        it is recommended that a HEARTBEAT chunk is sent once per RTO
        of that destination address plus the protocol parameter
        'HB.interval', with jittering of +/- 50% of the RTO value,
        and exponential backoff of the RTO if the previous HEARTBEAT
        is unanswered.
      
      Currently, we calculate jitter via sctp_jitter() function first,
      and then add its result to the current RTO for the new timeout:
      
        TMO = RTO + (RAND() % RTO) - (RTO / 2)
                    `------------------------^-=> sctp_jitter()
      
      Instead, we can just simplify all this by directly calculating:
      
        TMO = (RTO / 2) + (RAND() % RTO)
      
      With the help of prandom_u32_max(), we don't need to open code
      our own global PRNG, but can instead just make use of the per
      CPU implementation of prandom with better quality numbers. Also,
      we can now spare us the conditional for divide by zero check
      since no div or mod operation needs to be used. Note that
      prandom_u32_max() won't emit the same result as a mod operation,
      but we really don't care here as we only want to have a random
      number scaled into RTO interval.
      
      Note, exponential RTO backoff is handeled elsewhere, namely in
      sctp_do_8_2_transport_strike().
      Signed-off-by: NDaniel Borkmann <dborkman@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8f61059a
    • D
      Merge branch 'be2net' · eb1ac820
      David S. Miller 提交于
      Sathya Perla says:
      
      ====================
      be2net: patch set
      
      v2 change: merged 2 lines into one in patch 4
      
      Patch 1 refactors be_cmd_get_profile_config() routine to reduce
      code duplication by using the be_cmd_notify_wait() routine, instead
      of using a separate variant of the code for MBOX and MCCQ.
      
      Patch 2 introduces the required FW-cmd code in the PF to query
      RSS support on a VF. This is in preparation for patch 3.
      
      Patch 3 adds support for the PF driver to re-configure the resource
      distribution in FW based on the number of VFs enabled by the user. When
      the user is not interested in enabling VFs, all resources of a port are
      set-aside for the PF. If less than maximum number of VFs are enabled, then
      each VF gets a better share of the resources and can now enable RSS (if
      the interface supports it.)
      
      Patch 4 is a minor fix to re-enable HW vlan filtering as soon as the number
      of vlans programmed is within the HW limit.
      
      Please consider applying to net-next tree. Thanks!
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      eb1ac820
    • K
      be2net: re-enable vlan filtering mode asap · 9d4dfe4a
      Kalesh AP 提交于
      While adding vlans, when the HW limit of vlan filters is reached, the
      driver enables vlan promiscuous mode.
      Similarily, while removing vlans, the driver must re-enable HW filtering
      as soon as the number of vlan filters is within the HW limit.
      Signed-off-by: NKalesh AP <kalesh.purayil@emulex.com>
      Signed-off-by: NSathya Perla <sathya.perla@emulex.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9d4dfe4a