Skip to content
  1. Jan 27, 2008
  2. Jan 21, 2008
  3. Jan 20, 2008
    • Eric Dumazet's avatar
      [IPV4] ROUTE: ip_rt_dump() is unecessary slow · d2c758a5
      Eric Dumazet authored
      
      
      [ Upstream commit: d8c92830 ]
      
      I noticed "ip route list cache x.y.z.t" can be *very* slow.
      
      While strace-ing -T it I also noticed that first part of route cache
      is fetched quite fast :
      
      recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000},
      +msg_iov(1)=[{"p\0\0\0\30\0\2\0\254i\202
      GXm\0\0\2  \0\376\0\0\2\0\2\0"..., 16384}], msg_controllen=0, msg_flags=0}, 0) =
      +3772 <0.000047>
      recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000},
      +msg_iov(1)=[{"\234\0\0\0\30\0\2\0\254i\
      202GXm\0\0\2  \0\376\0\0\1\0\2"..., 16384}], msg_controllen=0, msg_flags=0}, 0)
      += 3736 <0.000042>
      recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000},
      +msg_iov(1)=[{"\204\0\0\0\30\0\2\0\254i\
      202GXm\0\0\2  \0\376\0\0\1\0\2"..., 16384}], msg_controllen=0, msg_flags=0}, 0)
      += 3740 <0.000055>
      recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000},
      +msg_iov(1)=[{"\234\0\0\0\30\0\2\0\254i\
      202GXm\0\0\2  \0\376\0\0\1\0\2"..., 16384}], msg_controllen=0, msg_flags=0}, 0)
      += 3712 <0.000043>
      recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000},
      +msg_iov(1)=[{"\204\0\0\0\30\0\2\0\254i\
      202GXm\0\0\2  \0\376\0\0\1\0\2"..., 16384}], msg_controllen=0, msg_flags=0}, 0)
      += 3732 <0.000053>
      recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000},
      +msg_iov(1)=[{"p\0\0\0\30\0\2\0\254i\202
      GXm\0\0\2  \0\376\0\0\2\0\2\0"..., 16384}], msg_controllen=0, msg_flags=0}, 0) =
      +3708 <0.000052>
      recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000},
      +msg_iov(1)=[{"p\0\0\0\30\0\2\0\254i\202
      GXm\0\0\2  \0\376\0\0\2\0\2\0"..., 16384}], msg_controllen=0, msg_flags=0}, 0) =
      +3680 <0.000041>
      
      while the part at the end of the table is more expensive:
      
      recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000},
      +msg_iov(1)=[{"\204\0\0\0\30\0\2\0\254i\202GXm\0\0\2  \0\376\0\0\1\0\2"...,
      +16384}], msg_controllen=0, msg_flags=0}, 0) = 3656 <0.003857>
      recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000},
      +msg_iov(1)=[{"\204\0\0\0\30\0\2\0\254i\202GXm\0\0\2  \0\376\0\0\1\0\2"...,
      +16384}], msg_controllen=0, msg_flags=0}, 0) = 3772 <0.003891>
      recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000},
      +msg_iov(1)=[{"p\0\0\0\30\0\2\0\254i\202GXm\0\0\2  \0\376\0\0\2\0\2\0"...,
      +16384}], msg_controllen=0, msg_flags=0}, 0) = 3712 <0.003765>
      recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000},
      +msg_iov(1)=[{"p\0\0\0\30\0\2\0\254i\202GXm\0\0\2  \0\376\0\0\2\0\2\0"...,
      +16384}], msg_controllen=0, msg_flags=0}, 0) = 3700 <0.003879>
      recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000},
      +msg_iov(1)=[{"p\0\0\0\30\0\2\0\254i\202GXm\0\0\2  \0\376\0\0\2\0\2\0"...,
      +16384}], msg_controllen=0, msg_flags=0}, 0) = 3676 <0.003797>
      recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000},
      +msg_iov(1)=[{"p\0\0\0\30\0\2\0\254i\202GXm\0\0\2  \0\376\0\0\2\0\2\0"...,
      +16384}], msg_controllen=0, msg_flags=0}, 0) = 3724 <0.003856>
      recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000},
      +msg_iov(1)=[{"\234\0\0\0\30\0\2\0\254i\202GXm\0\0\2  \0\376\0\0\1\0\2"...,
      +16384}], msg_controllen=0, msg_flags=0}, 0) = 3736 <0.003848>
      
      The following patch corrects this performance/latency problem,
      removing quadratic behavior.
      
      Signed-off-by: default avatarEric Dumazet <dada1@cosmosbay.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarAdrian Bunk <bunk@kernel.org>
      d2c758a5
    • Al Viro's avatar
      [NET]: Introduce types for checksums. · 9160766b
      Al Viro authored
      
      
      New types - for 16bit checksums and "unfolded" 32bit variant.
      
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarAdrian Bunk <bunk@kernel.org>
      9160766b
    • David S. Miller's avatar
      [CASSINI]: Set skb->truesize properly on receive packets. · fdd75e9b
      David S. Miller authored
      
      
      [ Upstream commit: d011a231 ]
      
      skb->truesize was not being incremented at all to
      reflect the page based data added to RX SKBs.
      
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarAdrian Bunk <bunk@kernel.org>
      fdd75e9b
    • Al Viro's avatar
      [CASSINI]: Fix endianness bug. · cffb92d2
      Al Viro authored
      
      
      [ Upstream commit: e5e02540 ]
      
      Here's proposed fix for RX checksum handling in cassini; it affects
      little-endian working with half-duplex gigabit, but obviously needs
      testing on big-endian too.
      
      The problem is, we need to convert checksum to fixed-endian *before*
      correcting for (unstripped) FCS.  On big-endian it won't matter
      (conversion is no-op), on little-endian it will, but only if FCS is
      not stripped by hardware; i.e. in half-duplex gigabit mode when
      ->crc_size is set.
      
      cassini.c part is that fix, cassini.h one consists of trivial
      endianness annotations.  With that applied the sucker is endian-clean,
      according to sparse.
      
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarAdrian Bunk <bunk@kernel.org>
      cffb92d2
    • Chas Williams's avatar
      [ATM]: [nicstar] delay irq setup until card is configured · 52f6ca5f
      Chas Williams authored
      
      
      [ Upstream commit: 52961955 ]
      
      Adrian Bunk:
      Backported to 2.6.16.
      
      Signed-off-by: default avatarChas Williams <chas@cmf.nrl.navy.mil>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarAdrian Bunk <bunk@kernel.org>
      52f6ca5f
    • Jeff Moyer's avatar
      raw: don't allow the creation of a raw device with minor number 0 · ac3cb3e4
      Jeff Moyer authored
      
      
      Minor number 0 (under the raw major) is reserved for the rawctl device
      file, which is used to query, set, and unset raw device bindings.  However,
      the ioctl interface does not protect the user from specifying a raw device
      with minor number 0:
      
      $ sudo ./raw /dev/raw/raw0 /dev/VolGroup00/swap
      /dev/raw/raw0:  bound to major 253, minor 2
      $ ls -l /dev/rawctl
      ls: /dev/rawctl: No such file or directory
      $ ls -l /dev/raw/raw0
      crw------- 1 root root 162, 0 Jan 12 10:51 /dev/raw/raw0
      $ sudo ./raw -qa
      Cannot open master raw device '/dev/rawctl' (No such file or directory)
      
      As you can see, this prevents any further raw operations from
      succeeding.  The fix (from Steve Fernandez) is quite simple - do not
      allow the allocation of minor number 0.
      
      Signed-off-by: default avatarJeff Moyer <jmoyer@redhat.com>
      Signed-off-by: default avatarAdrian Bunk <bunk@kernel.org>
      ac3cb3e4
  4. Jan 19, 2008
  5. Jan 16, 2008
  6. Jan 15, 2008
  7. Jan 06, 2008
Loading