1. 09 2月, 2008 7 次提交
    • E
      aoe: make error messages more specific · 578c4aa0
      Ed L. Cashin 提交于
      Andrew Morton pointed out that the "too many targets" message in patch 2 could
      be printed for failing GFP_ATOMIC allocations.  This patch makes the messages
      more specific.
      Signed-off-by: NEd L. Cashin <ecashin@coraid.com>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      578c4aa0
    • E
      aoe: the aoeminor doesn't need a long format · 1d75981a
      Ed L. Cashin 提交于
      The aoedev aoeminor member doesn't need a long format.
      Signed-off-by: NEd L. Cashin <ecashin@coraid.com>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1d75981a
    • E
      aoe: add module parameter for users who need more outstanding I/O · 7df620d8
      Ed L. Cashin 提交于
      An AoE target provides an estimate of the number of outstanding commands that
      the AoE initiator can send before getting a response.  The aoe_maxout
      parameter provides a way to set an even lower limit.  It will not allow a user
      to use more outstanding commands than the target permits.  If a user discovers
      a problem with a large setting, this parameter provides a way for us to work
      with them to debug the problem.  We expect to improve the dynamic window
      sizing algorithm and drop this parameter.  For the time being, it is a
      debugging aid.
      Signed-off-by: NEd L. Cashin <ecashin@coraid.com>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7df620d8
    • E
      aoe: only install new AoE device once · 6b9699bb
      Ed L. Cashin 提交于
      An aoe driver user who had about 70 AoE targets found that he was hitting a
      BUG in sysfs_create_file because the aoe driver was trying to tell the kernel
      about an AoE device more than once.  Each AoE device was reachable by several
      local network interfaces, and multiple ATA device indentify responses were
      returning from that single device.
      
      This patch eliminates a race condition so that aoe always informs the block
      layer of a new AoE device once in the presence of multiple incoming ATA device
      identify responses.
      Signed-off-by: NEd L. Cashin <ecashin@coraid.com>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6b9699bb
    • E
      aoe: dynamically allocate a capped number of skbs when necessary · 9bb237b6
      Ed L. Cashin 提交于
      What this Patch Does
      
        Even before this recent series of 12 patches to 2.6.22-rc4, the aoe
        driver was reusing a small set of skbs that were allocated once and
        were only used for outbound AoE commands.
      
        The network layer cannot be allowed to put_page on the data that is
        still associated with a bio we haven't returned to the block layer,
        so the aoe driver (even before the patch under discussion) is still
        the owner of skbs that have been handed to the network layer for
        transmission.  We need to keep track of these skbs so that we can
        free them, but by tracking them, we can also easily re-use them.
      
        The new patch was a response to the behavior of certain network
        drivers.  We cannot reuse an skb that the network driver still has
        in its transmit ring.  Network drivers can defer transmit ring
        cleanup and then use the state in the skb to determine how many data
        segments to clean up in its transmit ring.  The tg3 driver is one
        driver that behaves in this way.
      
        When the network driver defers cleanup of its transmit ring, the aoe
        driver can find itself in a situation where it would like to send an
        AoE command, and the AoE target is ready for more work, but the
        network driver still has all of the pre-allocated skbs.  In that
        case, the new patch just calls alloc_skb, as you'd expect.
      
        We don't want to get carried away, though.  We try not to do
        excessive allocation in the write path, so we cap the number of skbs
        we dynamically allocate.
      
        Probably calling it a "dynamic pool" is misleading.  We were already
        trying to use a small fixed-size set of pre-allocated skbs before
        this patch, and this patch just provides a little headroom (with a
        ceiling, though) to accomodate network drivers that hang onto skbs,
        by allocating when needed.  The d->skbpool_hd list of allocated skbs
        is necessary so that we can free them later.
      
        We didn't notice the need for this headroom until AoE targets got
        fast enough.
      
      Alternatives
      
        If the network layer never did a put_page on the pages in the bio's
        we get from the block layer, then it would be possible for us to
        hand skbs to the network layer and forget about them, allowing the
        network layer to free skbs itself (and thereby calling our own
        skb->destructor callback function if we needed that).  In that case
        we could get rid of the pre-allocated skbs and also the
        d->skbpool_hd, instead just calling alloc_skb every time we wanted
        to transmit a packet.  The slab allocator would effectively maintain
        the list of skbs.
      
        Besides a loss of CPU cache locality, the main concern with that
        approach the danger that it would increase the likelihood of
        deadlock when VM is trying to free pages by writing dirty data from
        the page cache through the aoe driver out to persistent storage on
        an AoE device.  Right now we have a situation where we have
        pre-allocation that corresponds to how much we use, which seems
        ideal.
      
        Of course, there's still the separate issue of receiving the packets
        that tell us that a write has successfully completed on the AoE
        target.  When memory is low and VM is using AoE to flush dirty data
        to free up pages, it would be perfect if there were a way for us to
        register a fast callback that could recognize write command
        completion responses.  But I don't think the current problems with
        the receive side of the situation are a justification for
        exacerbating the problem on the transmit side.
      Signed-off-by: NEd L. Cashin <ecashin@coraid.com>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9bb237b6
    • E
      aoe: mac_addr: avoid 64-bit arch compiler warnings · 1eb0da4c
      Ed L. Cashin 提交于
      By returning unsigned long long, mac_addr does not generate compiler warnings
      on 64-bit architectures.
      Signed-off-by: NEd L. Cashin <ecashin@coraid.com>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1eb0da4c
    • E
      aoe: handle multiple network paths to AoE device · 68e0d42f
      Ed L. Cashin 提交于
      A remote AoE device is something can process ATA commands and is identified by
      an AoE shelf number and an AoE slot number.  Such a device might have more
      than one network interface, and it might be reachable by more than one local
      network interface.  This patch tracks the available network paths available to
      each AoE device, allowing them to be used more efficiently.
      
      Andrew Morton asked about the call to msleep_interruptible in the revalidate
      function.  Yes, if a signal is pending, then msleep_interruptible will not
      return 0.  That means we will not loop but will call aoenet_xmit with a NULL
      skb, which is a noop.  If the system is too low on memory or the aoe driver is
      too low on frames, then the user can hit control-C to interrupt the attempt to
      do a revalidate.  I have added a comment to the code summarizing that.
      
      Andrew Morton asked whether the allocation performed inside addtgt could use a
      more relaxed allocation like GFP_KERNEL, but addtgt is called when the aoedev
      lock has been locked with spin_lock_irqsave.  It would be nice to allocate the
      memory under fewer restrictions, but targets are only added when the device is
      being discovered, and if the target can't be added right now, we can try again
      in a minute when then next AoE config query broadcast goes out.
      
      Andrew Morton pointed out that the "too many targets" message could be printed
      for failing GFP_ATOMIC allocations.  The last patch in this series makes the
      messages more specific.
      Signed-off-by: NEd L. Cashin <ecashin@coraid.com>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      68e0d42f
  2. 17 10月, 2007 1 次提交
  3. 11 10月, 2007 1 次提交
    • E
      [NET]: Make the device list and device lookups per namespace. · 881d966b
      Eric W. Biederman 提交于
      This patch makes most of the generic device layer network
      namespace safe.  This patch makes dev_base_head a
      network namespace variable, and then it picks up
      a few associated variables.  The functions:
      dev_getbyhwaddr
      dev_getfirsthwbytype
      dev_get_by_flags
      dev_get_by_name
      __dev_get_by_name
      dev_get_by_index
      __dev_get_by_index
      dev_ioctl
      dev_ethtool
      dev_load
      wireless_process_ioctl
      
      were modified to take a network namespace argument, and
      deal with it.
      
      vlan_ioctl_set and brioctl_set were modified so their
      hooks will receive a network namespace argument.
      
      So basically anthing in the core of the network stack that was
      affected to by the change of dev_base was modified to handle
      multiple network namespaces.  The rest of the network stack was
      simply modified to explicitly use &init_net the initial network
      namespace.  This can be fixed when those components of the network
      stack are modified to handle multiple network namespaces.
      
      For now the ifindex generator is left global.
      
      Fundametally ifindex numbers are per namespace, or else
      we will have corner case problems with migration when
      we get that far.
      
      At the same time there are assumptions in the network stack
      that the ifindex of a network device won't change.  Making
      the ifindex number global seems a good compromise until
      the network stack can cope with ifindex changes when
      you change namespaces, and the like.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      881d966b
  4. 10 10月, 2007 1 次提交
  5. 04 5月, 2007 1 次提交
  6. 26 4月, 2007 3 次提交
  7. 03 3月, 2007 1 次提交
  8. 23 12月, 2006 1 次提交
    • E
      [PATCH] fix aoe without scatter-gather [Bug 7662] · 19900cde
      Ed L. Cashin 提交于
      Fix a bug that only appears when AoE goes over a network card that does not
      support scatter-gather.  The headers in the linear part of the skb appeared
      to be larger than they really were, resulting in data that was offset by 24
      bytes.
      
      This patch eliminates the offset data on cards that don't support
      scatter-gather or have had scatter-gather turned off.  There remains an
      unrelated issue that I'll address in a separate email.
      
      Fixes bugzilla #7662
      Signed-off-by: N"Ed L. Cashin" <ecashin@coraid.com>
      Cc: <stable@kernel.org>
      Cc: Greg KH <greg@kroah.com>
      Cc: <boddingt@optusnet.com.au>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      19900cde
  9. 22 11月, 2006 1 次提交
  10. 19 10月, 2006 10 次提交
  11. 24 3月, 2006 6 次提交
  12. 01 11月, 2005 1 次提交
  13. 29 10月, 2005 1 次提交
  14. 19 4月, 2005 5 次提交