2006-09-21 02:36:48 +08:00
|
|
|
/* Copyright (c) 2006 Coraid, Inc. See COPYING for GPL terms. */
|
2008-02-08 20:19:58 +08:00
|
|
|
#define VERSION "47"
|
2005-04-17 06:20:36 +08:00
|
|
|
#define AOE_MAJOR 152
|
|
|
|
#define DEVICE_NAME "aoe"
|
2005-04-19 13:00:17 +08:00
|
|
|
|
|
|
|
/* set AOE_PARTITIONS to 1 to use whole-disks only
|
|
|
|
* default is 16, which is 15 partitions plus the whole disk
|
|
|
|
*/
|
2005-04-17 06:20:36 +08:00
|
|
|
#ifndef AOE_PARTITIONS
|
2005-08-20 04:54:43 +08:00
|
|
|
#define AOE_PARTITIONS (16)
|
2005-04-17 06:20:36 +08:00
|
|
|
#endif
|
2005-04-19 13:00:17 +08:00
|
|
|
|
2005-08-20 04:54:43 +08:00
|
|
|
#define SYSMINOR(aoemajor, aoeminor) ((aoemajor) * NPERSHELF + (aoeminor))
|
|
|
|
#define AOEMAJOR(sysminor) ((sysminor) / NPERSHELF)
|
|
|
|
#define AOEMINOR(sysminor) ((sysminor) % NPERSHELF)
|
2005-04-17 06:20:36 +08:00
|
|
|
#define WHITESPACE " \t\v\f\n"
|
|
|
|
|
|
|
|
enum {
|
|
|
|
AOECMD_ATA,
|
|
|
|
AOECMD_CFG,
|
|
|
|
|
|
|
|
AOEFL_RSP = (1<<3),
|
|
|
|
AOEFL_ERR = (1<<2),
|
|
|
|
|
|
|
|
AOEAFL_EXT = (1<<6),
|
|
|
|
AOEAFL_DEV = (1<<4),
|
|
|
|
AOEAFL_ASYNC = (1<<1),
|
|
|
|
AOEAFL_WRITE = (1<<0),
|
|
|
|
|
|
|
|
AOECCMD_READ = 0,
|
|
|
|
AOECCMD_TEST,
|
|
|
|
AOECCMD_PTEST,
|
|
|
|
AOECCMD_SET,
|
|
|
|
AOECCMD_FSET,
|
|
|
|
|
|
|
|
AOE_HVER = 0x10,
|
|
|
|
};
|
|
|
|
|
|
|
|
struct aoe_hdr {
|
|
|
|
unsigned char dst[6];
|
|
|
|
unsigned char src[6];
|
2005-04-19 13:00:20 +08:00
|
|
|
__be16 type;
|
2005-04-17 06:20:36 +08:00
|
|
|
unsigned char verfl;
|
|
|
|
unsigned char err;
|
2005-04-19 13:00:20 +08:00
|
|
|
__be16 major;
|
2005-04-17 06:20:36 +08:00
|
|
|
unsigned char minor;
|
|
|
|
unsigned char cmd;
|
2005-04-19 13:00:20 +08:00
|
|
|
__be32 tag;
|
2005-04-17 06:20:36 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
struct aoe_atahdr {
|
|
|
|
unsigned char aflags;
|
|
|
|
unsigned char errfeat;
|
|
|
|
unsigned char scnt;
|
|
|
|
unsigned char cmdstat;
|
|
|
|
unsigned char lba0;
|
|
|
|
unsigned char lba1;
|
|
|
|
unsigned char lba2;
|
|
|
|
unsigned char lba3;
|
|
|
|
unsigned char lba4;
|
|
|
|
unsigned char lba5;
|
|
|
|
unsigned char res[2];
|
|
|
|
};
|
|
|
|
|
|
|
|
struct aoe_cfghdr {
|
2005-04-19 13:00:20 +08:00
|
|
|
__be16 bufcnt;
|
|
|
|
__be16 fwver;
|
2006-09-21 02:36:49 +08:00
|
|
|
unsigned char scnt;
|
2005-04-17 06:20:36 +08:00
|
|
|
unsigned char aoeccmd;
|
|
|
|
unsigned char cslen[2];
|
|
|
|
};
|
|
|
|
|
|
|
|
enum {
|
|
|
|
DEVFL_UP = 1, /* device is installed in system and ready for AoE->ATA commands */
|
|
|
|
DEVFL_TKILL = (1<<1), /* flag for timer to know when to kill self */
|
|
|
|
DEVFL_EXT = (1<<2), /* device accepts lba48 commands */
|
|
|
|
DEVFL_CLOSEWAIT = (1<<3), /* device is waiting for all closes to revalidate */
|
2006-01-20 02:46:19 +08:00
|
|
|
DEVFL_GDALLOC = (1<<4), /* need to alloc gendisk */
|
aoe: handle multiple network paths to AoE device
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: Ed L. Cashin <ecashin@coraid.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-02-08 20:20:00 +08:00
|
|
|
DEVFL_KICKME = (1<<5), /* slow polling network card catch */
|
2006-01-20 02:46:19 +08:00
|
|
|
DEVFL_NEWSIZE = (1<<6), /* need to update dev size in block layer */
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
BUFFL_FAIL = 1,
|
|
|
|
};
|
|
|
|
|
|
|
|
enum {
|
2006-09-21 02:36:49 +08:00
|
|
|
DEFAULTBCNT = 2 * 512, /* 2 sectors */
|
2005-08-20 04:54:43 +08:00
|
|
|
NPERSHELF = 16, /* number of slots per shelf address */
|
2005-04-17 06:20:36 +08:00
|
|
|
FREETAG = -1,
|
aoe: handle multiple network paths to AoE device
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: Ed L. Cashin <ecashin@coraid.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-02-08 20:20:00 +08:00
|
|
|
MIN_BUFS = 16,
|
|
|
|
NTARGETS = 8,
|
|
|
|
NAOEIFS = 8,
|
aoe: dynamically allocate a capped number of skbs when necessary
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: Ed L. Cashin <ecashin@coraid.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-02-08 20:20:05 +08:00
|
|
|
NSKBPOOLMAX = 128,
|
aoe: handle multiple network paths to AoE device
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: Ed L. Cashin <ecashin@coraid.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-02-08 20:20:00 +08:00
|
|
|
|
|
|
|
TIMERTICK = HZ / 10,
|
|
|
|
MINTIMER = HZ >> 2,
|
|
|
|
MAXTIMER = HZ << 1,
|
|
|
|
HELPWAIT = 20,
|
2005-04-17 06:20:36 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
struct buf {
|
|
|
|
struct list_head bufs;
|
aoe: handle multiple network paths to AoE device
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: Ed L. Cashin <ecashin@coraid.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-02-08 20:20:00 +08:00
|
|
|
ulong stime; /* for disk stats */
|
2005-04-17 06:20:36 +08:00
|
|
|
ulong flags;
|
|
|
|
ulong nframesout;
|
|
|
|
ulong resid;
|
|
|
|
ulong bv_resid;
|
aoe: handle multiple network paths to AoE device
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: Ed L. Cashin <ecashin@coraid.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-02-08 20:20:00 +08:00
|
|
|
ulong bv_off;
|
2005-04-17 06:20:36 +08:00
|
|
|
sector_t sector;
|
|
|
|
struct bio *bio;
|
|
|
|
struct bio_vec *bv;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct frame {
|
|
|
|
int tag;
|
|
|
|
ulong waited;
|
|
|
|
struct buf *buf;
|
|
|
|
char *bufaddr;
|
2006-09-21 02:36:49 +08:00
|
|
|
ulong bcnt;
|
|
|
|
sector_t lba;
|
2006-09-21 02:36:49 +08:00
|
|
|
struct sk_buff *skb;
|
2005-04-17 06:20:36 +08:00
|
|
|
};
|
|
|
|
|
aoe: handle multiple network paths to AoE device
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: Ed L. Cashin <ecashin@coraid.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-02-08 20:20:00 +08:00
|
|
|
struct aoeif {
|
|
|
|
struct net_device *nd;
|
|
|
|
unsigned char lost;
|
|
|
|
unsigned char lostjumbo;
|
|
|
|
ushort maxbcnt;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct aoetgt {
|
|
|
|
unsigned char addr[6];
|
|
|
|
ushort nframes;
|
|
|
|
struct frame *frames;
|
|
|
|
struct aoeif ifs[NAOEIFS];
|
|
|
|
struct aoeif *ifp; /* current aoeif in use */
|
|
|
|
ushort nout;
|
|
|
|
ushort maxout;
|
|
|
|
u16 lasttag; /* last tag sent */
|
|
|
|
u16 useme;
|
|
|
|
ulong lastwadj; /* last window adjustment */
|
|
|
|
int wpkts, rpkts;
|
aoe: dynamically allocate a capped number of skbs when necessary
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: Ed L. Cashin <ecashin@coraid.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-02-08 20:20:05 +08:00
|
|
|
int dataref;
|
aoe: handle multiple network paths to AoE device
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: Ed L. Cashin <ecashin@coraid.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-02-08 20:20:00 +08:00
|
|
|
};
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
struct aoedev {
|
|
|
|
struct aoedev *next;
|
|
|
|
ulong sysminor;
|
|
|
|
ulong aoemajor;
|
aoe: handle multiple network paths to AoE device
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: Ed L. Cashin <ecashin@coraid.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-02-08 20:20:00 +08:00
|
|
|
u16 aoeminor;
|
|
|
|
u16 flags;
|
2006-09-21 02:36:49 +08:00
|
|
|
u16 nopen; /* (bd_openers isn't available without sleeping) */
|
|
|
|
u16 rttavg; /* round trip average of requests/responses */
|
|
|
|
u16 mintimer;
|
2005-04-17 06:20:36 +08:00
|
|
|
u16 fw_ver; /* version of blade's firmware */
|
|
|
|
struct work_struct work;/* disk create work struct */
|
|
|
|
struct gendisk *gd;
|
2007-07-24 15:28:11 +08:00
|
|
|
struct request_queue blkq;
|
2005-04-17 06:20:36 +08:00
|
|
|
struct hd_geometry geo;
|
|
|
|
sector_t ssize;
|
|
|
|
struct timer_list timer;
|
|
|
|
spinlock_t lock;
|
2005-04-19 13:00:22 +08:00
|
|
|
struct sk_buff *sendq_hd; /* packets needing to be sent, list head */
|
|
|
|
struct sk_buff *sendq_tl;
|
aoe: dynamically allocate a capped number of skbs when necessary
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: Ed L. Cashin <ecashin@coraid.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-02-08 20:20:05 +08:00
|
|
|
struct sk_buff *skbpool_hd;
|
|
|
|
struct sk_buff *skbpool_tl;
|
|
|
|
int nskbpool;
|
2005-04-17 06:20:36 +08:00
|
|
|
mempool_t *bufpool; /* for deadlock-free Buf allocation */
|
|
|
|
struct list_head bufq; /* queue of bios to work on */
|
|
|
|
struct buf *inprocess; /* the one we're currently working on */
|
aoe: handle multiple network paths to AoE device
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: Ed L. Cashin <ecashin@coraid.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-02-08 20:20:00 +08:00
|
|
|
struct aoetgt *targets[NTARGETS];
|
|
|
|
struct aoetgt **tgt; /* target in use when working */
|
|
|
|
struct aoetgt **htgt; /* target needing rexmit assistance */
|
2005-04-17 06:20:36 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
int aoeblk_init(void);
|
|
|
|
void aoeblk_exit(void);
|
|
|
|
void aoeblk_gdalloc(void *);
|
|
|
|
void aoedisk_rm_sysfs(struct aoedev *d);
|
|
|
|
|
|
|
|
int aoechr_init(void);
|
|
|
|
void aoechr_exit(void);
|
|
|
|
void aoechr_error(char *);
|
|
|
|
|
|
|
|
void aoecmd_work(struct aoedev *d);
|
2006-01-20 02:46:19 +08:00
|
|
|
void aoecmd_cfg(ushort aoemajor, unsigned char aoeminor);
|
2005-04-17 06:20:36 +08:00
|
|
|
void aoecmd_ata_rsp(struct sk_buff *);
|
|
|
|
void aoecmd_cfg_rsp(struct sk_buff *);
|
2006-11-22 22:57:56 +08:00
|
|
|
void aoecmd_sleepwork(struct work_struct *);
|
aoe: handle multiple network paths to AoE device
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: Ed L. Cashin <ecashin@coraid.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-02-08 20:20:00 +08:00
|
|
|
void aoecmd_cleanslate(struct aoedev *);
|
|
|
|
struct sk_buff *aoecmd_ata_id(struct aoedev *);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
int aoedev_init(void);
|
|
|
|
void aoedev_exit(void);
|
2005-04-19 13:00:18 +08:00
|
|
|
struct aoedev *aoedev_by_aoeaddr(int maj, int min);
|
aoe: handle multiple network paths to AoE device
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: Ed L. Cashin <ecashin@coraid.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-02-08 20:20:00 +08:00
|
|
|
struct aoedev *aoedev_by_sysminor_m(ulong sysminor);
|
2005-04-17 06:20:36 +08:00
|
|
|
void aoedev_downdev(struct aoedev *d);
|
2006-01-20 02:46:19 +08:00
|
|
|
int aoedev_isbusy(struct aoedev *d);
|
2008-02-08 20:20:03 +08:00
|
|
|
int aoedev_flush(const char __user *str, size_t size);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
int aoenet_init(void);
|
|
|
|
void aoenet_exit(void);
|
|
|
|
void aoenet_xmit(struct sk_buff *);
|
|
|
|
int is_aoe_netif(struct net_device *ifp);
|
|
|
|
int set_aoe_iflist(const char __user *str, size_t size);
|
|
|
|
|
2008-02-08 20:20:01 +08:00
|
|
|
unsigned long long mac_addr(char addr[6]);
|