* linux-next: manual merge of the net tree with the wireless-current tree
From: Stephen Rothwell @ 2011-07-06 2:53 UTC (permalink / raw)
To: David Miller, netdev; +Cc: linux-next, linux-kernel, Gustavo F. Padovan
Hi all,
Today's linux-next merge of the net tree got a conflict in
net/bluetooth/l2cap_core.c between commit 9fa7e4f76f36 ("Bluetooth: Fix
regression with incoming L2CAP connections") from the wireless-current
tree and commit 89bc500e41fc ("Bluetooth: Add state tracking to struct
l2cap_chan") from the net tree.
I fixed it up (I think - see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc net/bluetooth/l2cap_core.c
index ebff14c,9ec9c8c..0000000
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@@ -2323,8 -2530,7 +2530,8 @@@ static inline int l2cap_config_req(stru
sk = chan->sk;
- if ((bt_sk(sk)->defer_setup && sk->sk_state != BT_CONNECT2) ||
- (!bt_sk(sk)->defer_setup && sk->sk_state != BT_CONFIG)) {
- if (chan->state != BT_CONFIG) {
++ if ((bt_sk(sk)->defer_setup && chan->state != BT_CONNECT2) ||
++ (!bt_sk(sk)->defer_setup && chan->state != BT_CONFIG)) {
struct l2cap_cmd_rej rej;
rej.reason = cpu_to_le16(0x0002);
^ permalink raw reply
* Re: [PATCH v2 0/3] Add device tree probe support for imx fec driver
From: David Miller @ 2011-07-06 2:48 UTC (permalink / raw)
To: shawn.guo-QSEj5FYQhm4dnm+yROfE0A
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
patches-QSEj5FYQhm4dnm+yROfE0A
In-Reply-To: <1309878839-25743-1-git-send-email-shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
From: Shawn Guo <shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Date: Tue, 5 Jul 2011 23:13:56 +0800
> The first two patches are a little off topic. Patch #1 adds a helper
> function of_get_phy_mode into of_net, and #2 converts ibm_newemac net
> driver to use this helper function. Patch #3 is the actual one adding
> tree probe support for imx fec driver, with of_get_phy_mode being used.
>
> Changes since v1:
> * Address review comments given by Grant
> * Add patch #1 and #2
>
> Shawn Guo (3):
> dt/net: add helper function of_get_phy_mode
> net: ibm_newemac: convert it to use of_get_phy_mode
> net/fec: add device tree probe support
All applied to net-next-2.6, thanks.
^ permalink raw reply
* Re: pull request: batman-adv 2011-07-05
From: David Miller @ 2011-07-06 2:46 UTC (permalink / raw)
To: lindner_marek-LWAfsSFWpa4
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
In-Reply-To: <1309873440-11704-1-git-send-email-lindner_marek-LWAfsSFWpa4@public.gmane.org>
From: Marek Lindner <lindner_marek-LWAfsSFWpa4@public.gmane.org>
Date: Tue, 5 Jul 2011 15:43:54 +0200
> The following changes since commit 43676ab590c3f8686fd047d34c3e33803eef71f0:
>
> batman-adv: improved gateway tq-based selection (2011-06-20 11:37:41 +0200)
>
> are available in the git repository at:
> git://git.open-mesh.org/linux-merge.git batman-adv/next
Pulled, thanks.
^ permalink raw reply
* [PATCH net-next v2] net: Add GSO to vlan_features initialization
From: Shan Wei @ 2011-07-06 2:09 UTC (permalink / raw)
To: David Miller, 单卫, netdev
Just add GSO to vlan_features initialization, and update comments.
When we set offload features, vlan_dev_fix_features() will do more check.
In vlan_dev_fix_features(), final features is decided by
features of real device and vlan_features of real device.
Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
---
v2: update changelog.
---
net/core/dev.c | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 4577e67..9ca1514 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5488,11 +5488,12 @@ int register_netdevice(struct net_device *dev)
dev->features |= NETIF_F_NOCACHE_COPY;
}
- /* Enable GRO and NETIF_F_HIGHDMA for vlans by default,
- * vlan_dev_init() will do the dev->features check, so these features
- * are enabled only if supported by underlying device.
+ /* Enable GSO, GRO and NETIF_F_HIGHDMA for vlans by default,
+ * vlan_dev_fix_features() will do the features check,
+ * so NETIF_F_HIGHDMA feature is enabled only if supported
+ * by underlying device.
*/
- dev->vlan_features |= (NETIF_F_GRO | NETIF_F_HIGHDMA);
+ dev->vlan_features |= (NETIF_F_SOFT_FEATURES | NETIF_F_HIGHDMA);
ret = call_netdevice_notifiers(NETDEV_POST_INIT, dev);
ret = notifier_to_errno(ret);
--
1.7.4.1
^ permalink raw reply related
* [PATCH bug-fix v2] net: vlan: enable soft features regardless of underlying device
From: Shan Wei @ 2011-07-06 2:08 UTC (permalink / raw)
To: David Miller, 单卫, netdev
If gso/gro feature of underlying device is turned off，
then new created vlan device never can turn gso/gro on.
Although underlying device don't support TSO, we still
should use software segments for vlan device.
Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
---
v2: only update changelog and title.
---
net/8021q/vlan_dev.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index 1c9aa8c..d8f45ba 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -588,9 +588,14 @@ static void vlan_dev_uninit(struct net_device *dev)
static u32 vlan_dev_fix_features(struct net_device *dev, u32 features)
{
struct net_device *real_dev = vlan_dev_info(dev)->real_dev;
+ u32 old_features = features;
features &= real_dev->features;
features &= real_dev->vlan_features;
+
+ if (old_features & NETIF_F_SOFT_FEATURES)
+ features |= old_features & NETIF_F_SOFT_FEATURES;
+
if (dev_ethtool_get_rx_csum(real_dev))
features |= NETIF_F_RXCSUM;
features |= NETIF_F_LLTX;
--
1.7.4.1
^ permalink raw reply related
* Re: [BUG] bd4265fe36 bridge: Only flood unreg groups... breaks DHCP setup
From: David Miller @ 2011-07-06 1:40 UTC (permalink / raw)
To: herbert; +Cc: mike, netdev
In-Reply-To: <20110705235833.GA5599@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.hengli.com.au>
Date: Wed, 6 Jul 2011 07:58:33 +0800
> bridge: Always flood broadcast packets
>
> As is_multicast_ether_addr returns true on broadcast packets as
> well, we need to explicitly exclude broadcast packets so that
> they're always flooded. This wasn't an issue before as broadcast
> packets were considered to be an unregistered multicast group,
> which were always flooded. However, as we now only flood such
> packets to router ports, this is no longer acceptable.
>
> Reported-by: Michael Guntsche <mike@it-loops.com>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied.
^ permalink raw reply
* Re: [PATCH] vmxnet3: fix starving rx ring whenoc_skb kb fails
From: David Miller @ 2011-07-06 1:40 UTC (permalink / raw)
To: sbhatewara; +Cc: bhutchings, pv-drivers, netdev, scottjg
In-Reply-To: <alpine.LRH.2.00.1107051721230.32629@sbhatewara-dev1.eng.vmware.com>
From: Shreyas Bhatewara <sbhatewara@vmware.com>
Date: Tue, 5 Jul 2011 17:34:05 -0700 (PDT)
>
> If the rx ring is completely empty, then the device may never fire an rx
> interrupt. Unfortunately, the rx interrupt is what triggers populating the
> rx ring with fresh buffers, so this will cause networking to lock up.
>
> This patch replenishes the skb in recv descriptor as soon as it is
> peeled off while processing rx completions. If the skb/buffer
> allocation fails, existing one is recycled and the packet in hand is
> dropped. This way none of the RX desc is ever left empty, thus avoiding
> starvation
>
> Signed-off-by: Scott J. Goldman <scottjg@vmware.com>
> Signed-off-by: Shreyas N Bhatewara <sbhatewara@vmware.com>
Applied.
^ permalink raw reply
* Re: [PATCH] usb: usbnet: suspend count gets lost when -EBUSY
From: David Miller @ 2011-07-06 1:40 UTC (permalink / raw)
To: C.Fries, qcf001; +Cc: netdev, stable
In-Reply-To: <CADuEq9BQX2BFBY3pF=CEEymfK4JPwMP7By+JZFdaLqxs+GhtJQ@mail.gmail.com>
From: Chris Fries <qcf001@motorola.com>
Date: Tue, 5 Jul 2011 20:35:05 -0500
> +++ b/drivers/net/usb/usbnet.c
> @@ -1451,6 +1451,7 @@ int usbnet_suspend (struct usb_interface *intf,
> pm_message_t message)
Your email client has mangled your patch, please read
"Documentation/email-clients.txt" on how to fix this.
Once you've fixed it, email the patch to yourself and
verify that you yourself can successfully apply the
patch you receive.
^ permalink raw reply
* Opportunity
From: M.L @ 2011-07-06 1:38 UTC (permalink / raw)
Hello I am contacting you with regards to a business transaction I want us to execute, it is in respect to a dormant account which belongs to my late client.
I believe we may be able to make good of this situation for ourselves. Please indicate your interest and I will give you more information.
Kind regards
M.L.
^ permalink raw reply
* [PATCH] usb: usbnet: suspend count gets lost when -EBUSY
From: Chris Fries @ 2011-07-06 1:35 UTC (permalink / raw)
To: David Miller; +Cc: netdev, stable
When suspend is refused due to pending transmits, the
busy counter gets out of sync, and suspend will stop
working correctly.
Signed-off-by: Chris Fries <C.Fries@motorola.com>
---
drivers/net/usb/usbnet.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index cc95aad..9bcc3e3 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -1451,6 +1451,7 @@ int usbnet_suspend (struct usb_interface *intf,
pm_message_t message)
/* don't autosuspend while transmitting */
if (dev->txq.qlen && (message.event & PM_EVENT_AUTO)) {
spin_unlock_irq(&dev->txq.lock);
+ dev->suspend_count--;
return -EBUSY;
} else {
set_bit(EVENT_DEV_ASLEEP, &dev->flags);
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH net-next-2.6] net: sched: constify tcf_proto and tc_action
From: David Miller @ 2011-07-06 1:33 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <20110705.183234.1710750208514203200.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Tue, 05 Jul 2011 18:32:34 -0700 (PDT)
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Tue, 05 Jul 2011 18:36:47 +0200
>
>> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>
> Applied, thanks Eric.
Actually, I'm reverting:
net/sched/act_ipt.c:294:2: warning: initialization from incompatible pointer type [enabled by default]
net/sched/act_ipt.c:294:2: warning: (near initialization for ‘act_ipt_ops.act’) [enabled by default]
net/sched/act_csum.c:572:2: warning: initialization from incompatible pointer type [enabled by default]
net/sched/act_csum.c:572:2: warning: (near initialization for ‘act_csum_ops.act’) [enabled by default]
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: sched: constify tcf_proto and tc_action
From: David Miller @ 2011-07-06 1:32 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1309883807.2271.30.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 05 Jul 2011 18:36:47 +0200
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2011-07-05
From: David Miller @ 2011-07-06 1:29 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev
In-Reply-To: <20110705204106.GG7540@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Tue, 5 Jul 2011 16:41:07 -0400
> Here is another big batch of changed intended for 3.1. This looks
> bigger than it is, as it also contains a wireless-2.6 pull to resolve
> some build conflicts.
>
> The most noteworth item is yet another rtlwifi-based driver (rtl8192de).
> There is also some HT-phy work for b43, plus the usual contributions
> from the ath9k and iwlwifi crews and a variety of other bits here and
> there.
>
> Please let me know if there are problems!
Pulled, thanks John.
^ permalink raw reply
* Re: [PATCH 0/2] AF_PACKET fanout support
From: David Miller @ 2011-07-06 1:20 UTC (permalink / raw)
To: therbert; +Cc: victor, netdev, willemb
In-Reply-To: <CA+mtBx_MtQGqNT6iungW7eyStpvLEGYsgXQ8=mYq_JR8jw3=DQ@mail.gmail.com>
From: Tom Herbert <therbert@google.com>
Date: Tue, 5 Jul 2011 17:46:36 -0700
> Thanks for these patches! Is it possible you could use an alternative
> term than "fanout"? I think this may be more often associated with a
> transmit operation (e.g. multicast fanout).
I've never heard such terminology myself.
Sorry, the fanout name is staying :-)
> Also, another useful mode of steering would be to steer packets to a
> socket which was recently processed by a thread running on the same
> CPU; somewhat analogous to RFS (cc'ed WIllem Bruijn who is already
> working on this I believe).
This sounds like a good way to overload a local socket and prevent
pushing the work to lesser used sockets on other cpus.
^ permalink raw reply
* Re: usbnet suspend issue
From: David Miller @ 2011-07-06 1:11 UTC (permalink / raw)
To: C.Fries, qcf001; +Cc: netdev, stable
In-Reply-To: <CADuEq9DosCUpw9CnLrgQPXFojeCqEy-BHfZd1_BgvRJdFFQ9Ow@mail.gmail.com>
Patch submitted as binary attachment instead of plain text inline that
we can read and evaluate directly in our mail clients.
Also, if you submit this as a binary attachment, automated patch
management tools, such as patchwork, we use cannot track the patch.
Sorry, this is not the proper way to submit a patch.
Also get rid of the "Change-Id:" in your commit message, it has
no meaning.
^ permalink raw reply
* RE: [RFC] non-preemptible kernel socket for RAMster
From: Dan Magenheimer @ 2011-07-06 1:05 UTC (permalink / raw)
To: Loke, Chetan, netdev; +Cc: Konrad Wilk, linux-mm
In-Reply-To: <D3F292ADF945FB49B35E96C94C2061B91257DCA8@nsmail.netscout.com>
> From: Loke, Chetan [mailto:Chetan.Loke@netscout.com]
> Subject: RE: [RFC] non-preemptible kernel socket for RAMster
>
> > From: Dan Magenheimer [mailto:dan.magenheimer@oracle.com]
>
> > Actually, RAMster is using a much more flexible type of
> > RAM-drive; it is built on top of Transcendent Memory
> > and on top of zcache (and thus on top of cleancache and
> > frontswap). A RAM-drive is fixed size so is not very suitable
> > for the flexibility required for RAMster. For example,
> > suppose you have two machines A and B. At one point in
> > time A is overcommitted and needs to swap and B is relatively
> > idle. Then later, B is overcommitted and needs to swap and
> > A is relatively idle. RAMster can handle this entirely
> > dynamically, a RAM-drive cannot.
>
> Again, iff NBD works with a ram-drive then you really wouldn't need to
> do anything. How often are you going to re-size your remote-SWAP? Plus,
> you can make nbd-server listen on multiple ports - Google(Linux NBD)
> returned: http://www.fi.muni.cz/~kripac/orac-nbd/ . Look at the
> nbd-server code to see if it launches multiple kernel-threads for
> servicing different ports. If not, one can enhance it and scale that way
> too. But nbd-server today can service multiple-ports(that is effectively
> servicing multiple clients). So why not add NBD-filesystem-filters to
> make it point to local/remote swap?
Well, we may be talking past each other, but the RAMster answer to:
> How often are you going to re-size your remote-SWAP?
is "as often as the working set changes on any machine in the
cluster", meaning *constantly*, entirely dynamically! How
about a more specific example: Suppose you have 2 machines,
each with 8GB of memory. 99% of the time each machine is
chugging along just fine and doesn't really need more than 4GB,
and may even use less than 1GB a large part of the time.
But very now and then, one of the machines randomly needs
9GB, 10GB, maybe even 12GB of memory. This would normally
result in swapping. (Most system administrators won't even
have this much information... they'll just know they are
seeing swapping and decide they need to buy more RAM.)
With NBD to a ram-drive, each machine would need to pre-allocate
4GB of RAM for the RAM-drive, leaving only 4GB of RAM for
the "local" RAM. The result will actually be MORE swapping
because a fixed amount of RAM has been pre-reserved for the
other machine's swap. With RAMster, everything is done dynamically,
so all that matters is the maximum of the sum of the RAM
used. You may even be able to *remove* ~2GB of RAM from each
of the systems and still never see any swapping to disk.
> > Thanks. Could you provide a pointer for this? I found
> > the SCST sourceforge page but no obvious references to
> > scst-in-ram-mode. (But also, since it appears to be
> > SCSI-related, I wonder if it also assumes a fixed size
> > target device, RAM or disk or ??)
>
> Yes, it is SCSI. You should be looking for SCST I/O modes. Read some
> docs and then send an email to the scst-mailing-list. If you speak about
> block-IO-performance then FC(in its class of price/performance factor)
> is more than capable of handling any workload. FC is a protocol designed
> for storage. No exotic fabric other than FC is needed.
> Folks who start with ethernet for block-IO, always start with bare
> minimal code and then for squeezing block-IO performance(aka version 2
> of the product), keep hacking repeatedly or go for a link-speed upgrade.
> Start with FC, period.
My point was that block I/O devices (AFAIK) always present a fixed
"size" to the kernel, and if this is also true of scst-in-ram-mode,
the same problem as swap-over-NBD occurs... it's not dynamic.
RAMster does not present a block-I/O storage-like interface;
it's using the Transcendent Memory interface, which is designed
for "slow RAM" of an unknown-and-dynamic size.
I'm not a storage expert either, but I do wonder if "no exotic
fabric other than FC" isn't an oxymoron ;-) FC is certainly
too exotic for me.
Dan
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 0/2] AF_PACKET fanout support
From: Tom Herbert @ 2011-07-06 0:46 UTC (permalink / raw)
To: David Miller; +Cc: victor, netdev, Willem Bruijn
In-Reply-To: <20110704.212002.1680758539791986198.davem@davemloft.net>
Dave,
Thanks for these patches! Is it possible you could use an alternative
term than "fanout"? I think this may be more often associated with a
transmit operation (e.g. multicast fanout).
Also, another useful mode of steering would be to steer packets to a
socket which was recently processed by a thread running on the same
CPU; somewhat analogous to RFS (cc'ed WIllem Bruijn who is already
working on this I believe).
Tom
On Mon, Jul 4, 2011 at 9:20 PM, David Miller <davem@davemloft.net> wrote:
>
> This is a fully functional version, I've tested both hash and
> load-balance modes successfully. I plan to commit this to
> net-next-2.6 very soon.
>
> Below is a test program that other people can play with
> if they want. It basically creates 4 threads, and creates
> an AF_PACKET fanout amongst them. Each thread prints out
> it's pid in parentheses every time it receives 10 packets.
> After each thread processes 10,000 packets, it exits.
>
> Try things like "./test eth0 hash", "./test eth0 lb", etc.
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
>
> --------------------
> #include <stddef.h>
> #include <stdlib.h>
> #include <stdio.h>
> #include <string.h>
>
> #include <sys/types.h>
> #include <sys/wait.h>
> #include <sys/socket.h>
> #include <sys/ioctl.h>
>
> #include <unistd.h>
>
> #include <linux/if_ether.h>
> #include <linux/if_packet.h>
>
> #include <net/if.h>
>
> static const char *device_name;
> static int fanout_type;
> static int fanout_id;
>
> #ifndef PACKET_FANOUT
> #define PACKET_FANOUT 18
> #define PACKET_FANOUT_HASH 0
> #define PACKET_FANOUT_LB 1
> #endif
>
> static int setup_socket(void)
> {
> int err, fd = socket(AF_PACKET, SOCK_RAW, htons(ETH_P_IP));
> struct sockaddr_ll ll;
> struct ifreq ifr;
> int fanout_arg;
>
> if (fd < 0) {
> perror("socket");
> return EXIT_FAILURE;
> }
>
> memset(&ifr, 0, sizeof(ifr));
> strcpy(ifr.ifr_name, device_name);
> err = ioctl(fd, SIOCGIFINDEX, &ifr);
> if (err < 0) {
> perror("SIOCGIFINDEX");
> return EXIT_FAILURE;
> }
>
> memset(&ll, 0, sizeof(ll));
> ll.sll_family = AF_PACKET;
> ll.sll_ifindex = ifr.ifr_ifindex;
> err = bind(fd, (struct sockaddr *) &ll, sizeof(ll));
> if (err < 0) {
> perror("bind");
> return EXIT_FAILURE;
> }
>
> fanout_arg = (fanout_id | (fanout_type << 16));
> err = setsockopt(fd, SOL_PACKET, PACKET_FANOUT,
> &fanout_arg, sizeof(fanout_arg));
> if (err) {
> perror("setsockopt");
> return EXIT_FAILURE;
> }
>
> return fd;
> }
>
> static void fanout_thread(void)
> {
> int fd = setup_socket();
> int limit = 10000;
>
> if (fd < 0)
> exit(fd);
>
> while (limit-- > 0) {
> char buf[1600];
> int err;
>
> err = read(fd, buf, sizeof(buf));
> if (err < 0) {
> perror("read");
> exit(EXIT_FAILURE);
> }
> if ((limit % 10) == 0)
> fprintf(stdout, "(%d) \n", getpid());
> }
>
> fprintf(stdout, "%d: Received 10000 packets\n", getpid());
>
> close(fd);
> exit(0);
> }
>
> int main(int argc, char **argp)
> {
> int fd, err;
> int i;
>
> if (argc != 3) {
> fprintf(stderr, "Usage: %s INTERFACE {hash|lb}\n", argp[0]);
> return EXIT_FAILURE;
> }
>
> if (!strcmp(argp[2], "hash"))
> fanout_type = PACKET_FANOUT_HASH;
> else if (!strcmp(argp[2], "lb"))
> fanout_type = PACKET_FANOUT_LB;
> else {
> fprintf(stderr, "Unknown fanout type [%s]\n", argp[2]);
> exit(EXIT_FAILURE);
> }
>
> device_name = argp[1];
> fanout_id = getpid() & 0xffff;
>
> for (i = 0; i < 4; i++) {
> pid_t pid = fork();
>
> switch (pid) {
> case 0:
> fanout_thread();
>
> case -1:
> perror("fork");
> exit(EXIT_FAILURE);
> }
> }
>
> for (i = 0; i < 4; i++) {
> int status;
>
> wait(&status);
> }
>
> return 0;
> }
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] vmxnet3: fix starving rx ring whenoc_skb kb fails
From: Shreyas Bhatewara @ 2011-07-06 0:34 UTC (permalink / raw)
To: David Miller
Cc: bhutchings@solarflare.com, pv-drivers@vmware.com,
netdev@vger.kernel.org, scottjg
In-Reply-To: <20110617.120900.550060204741705506.davem@davemloft.net>
If the rx ring is completely empty, then the device may never fire an rx
interrupt. Unfortunately, the rx interrupt is what triggers populating the
rx ring with fresh buffers, so this will cause networking to lock up.
This patch replenishes the skb in recv descriptor as soon as it is
peeled off while processing rx completions. If the skb/buffer
allocation fails, existing one is recycled and the packet in hand is
dropped. This way none of the RX desc is ever left empty, thus avoiding
starvation
Signed-off-by: Scott J. Goldman <scottjg@vmware.com>
Signed-off-by: Shreyas N Bhatewara <sbhatewara@vmware.com>
---
diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c b/drivers/net/vmxnet3/vmxnet3_drv.c
index 2c14736..fabcded 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -573,7 +573,7 @@ vmxnet3_rq_alloc_rx_buf(struct vmxnet3_rx_queue *rq, u32 ring_idx,
struct vmxnet3_cmd_ring *ring = &rq->rx_ring[ring_idx];
u32 val;
- while (num_allocated < num_to_alloc) {
+ while (num_allocated <= num_to_alloc) {
struct vmxnet3_rx_buf_info *rbi;
union Vmxnet3_GenericDesc *gd;
@@ -619,9 +619,15 @@ vmxnet3_rq_alloc_rx_buf(struct vmxnet3_rx_queue *rq, u32 ring_idx,
BUG_ON(rbi->dma_addr == 0);
gd->rxd.addr = cpu_to_le64(rbi->dma_addr);
- gd->dword[2] = cpu_to_le32((ring->gen << VMXNET3_RXD_GEN_SHIFT)
+ gd->dword[2] = cpu_to_le32((!ring->gen << VMXNET3_RXD_GEN_SHIFT)
| val | rbi->len);
+ /* Fill the last buffer but dont mark it ready, or else the
+ * device will think that the queue is full */
+ if (num_allocated == num_to_alloc)
+ break;
+
+ gd->dword[2] |= cpu_to_le32(ring->gen << VMXNET3_RXD_GEN_SHIFT);
num_allocated++;
vmxnet3_cmd_ring_adv_next2fill(ring);
}
@@ -1138,6 +1144,7 @@ vmxnet3_rq_rx_complete(struct vmxnet3_rx_queue *rq,
VMXNET3_REG_RXPROD, VMXNET3_REG_RXPROD2
};
u32 num_rxd = 0;
+ bool skip_page_frags = false;
struct Vmxnet3_RxCompDesc *rcd;
struct vmxnet3_rx_ctx *ctx = &rq->rx_ctx;
#ifdef __BIG_ENDIAN_BITFIELD
@@ -1148,11 +1155,12 @@ vmxnet3_rq_rx_complete(struct vmxnet3_rx_queue *rq,
&rxComp);
while (rcd->gen == rq->comp_ring.gen) {
struct vmxnet3_rx_buf_info *rbi;
- struct sk_buff *skb;
+ struct sk_buff *skb, *new_skb = NULL;
+ struct page *new_page = NULL;
int num_to_alloc;
struct Vmxnet3_RxDesc *rxd;
u32 idx, ring_idx;
-
+ struct vmxnet3_cmd_ring *ring = NULL;
if (num_rxd >= quota) {
/* we may stop even before we see the EOP desc of
* the current pkt
@@ -1163,6 +1171,7 @@ vmxnet3_rq_rx_complete(struct vmxnet3_rx_queue *rq,
BUG_ON(rcd->rqID != rq->qid && rcd->rqID != rq->qid2);
idx = rcd->rxdIdx;
ring_idx = rcd->rqID < adapter->num_rx_queues ? 0 : 1;
+ ring = rq->rx_ring + ring_idx;
vmxnet3_getRxDesc(rxd, &rq->rx_ring[ring_idx].base[idx].rxd,
&rxCmdDesc);
rbi = rq->buf_info[ring_idx] + idx;
@@ -1191,37 +1200,80 @@ vmxnet3_rq_rx_complete(struct vmxnet3_rx_queue *rq,
goto rcd_done;
}
+ skip_page_frags = false;
ctx->skb = rbi->skb;
- rbi->skb = NULL;
+ new_skb = dev_alloc_skb(rbi->len + NET_IP_ALIGN);
+ if (new_skb == NULL) {
+ /* Skb allocation failed, do not handover this
+ * skb to stack. Reuse it. Drop the existing pkt
+ */
+ rq->stats.rx_buf_alloc_failure++;
+ ctx->skb = NULL;
+ rq->stats.drop_total++;
+ skip_page_frags = true;
+ goto rcd_done;
+ }
pci_unmap_single(adapter->pdev, rbi->dma_addr, rbi->len,
PCI_DMA_FROMDEVICE);
skb_put(ctx->skb, rcd->len);
+
+ /* Immediate refill */
+ new_skb->dev = adapter->netdev;
+ skb_reserve(new_skb, NET_IP_ALIGN);
+ rbi->skb = new_skb;
+ rbi->dma_addr = pci_map_single(adapter->pdev,
+ rbi->skb->data, rbi->len,
+ PCI_DMA_FROMDEVICE);
+ rxd->addr = cpu_to_le64(rbi->dma_addr);
+ rxd->len = rbi->len;
+
} else {
- BUG_ON(ctx->skb == NULL);
+ BUG_ON(ctx->skb == NULL && !skip_page_frags);
+
/* non SOP buffer must be type 1 in most cases */
- if (rbi->buf_type == VMXNET3_RX_BUF_PAGE) {
- BUG_ON(rxd->btype != VMXNET3_RXD_BTYPE_BODY);
+ BUG_ON(rbi->buf_type != VMXNET3_RX_BUF_PAGE);
+ BUG_ON(rxd->btype != VMXNET3_RXD_BTYPE_BODY);
- if (rcd->len) {
- pci_unmap_page(adapter->pdev,
- rbi->dma_addr, rbi->len,
- PCI_DMA_FROMDEVICE);
+ /* If an sop buffer was dropped, skip all
+ * following non-sop fragments. They will be reused.
+ */
+ if (skip_page_frags)
+ goto rcd_done;
- vmxnet3_append_frag(ctx->skb, rcd, rbi);
- rbi->page = NULL;
- }
- } else {
- /*
- * The only time a non-SOP buffer is type 0 is
- * when it's EOP and error flag is raised, which
- * has already been handled.
+ new_page = alloc_page(GFP_ATOMIC);
+ if (unlikely(new_page == NULL)) {
+ /* Replacement page frag could not be allocated.
+ * Reuse this page. Drop the pkt and free the
+ * skb which contained this page as a frag. Skip
+ * processing all the following non-sop frags.
*/
- BUG_ON(true);
+ rq->stats.rx_buf_alloc_failure++;
+ dev_kfree_skb(ctx->skb);
+ ctx->skb = NULL;
+ skip_page_frags = true;
+ goto rcd_done;
+ }
+
+ if (rcd->len) {
+ pci_unmap_page(adapter->pdev,
+ rbi->dma_addr, rbi->len,
+ PCI_DMA_FROMDEVICE);
+
+ vmxnet3_append_frag(ctx->skb, rcd, rbi);
}
+
+ /* Immediate refill */
+ rbi->page = new_page;
+ rbi->dma_addr = pci_map_page(adapter->pdev, rbi->page,
+ 0, PAGE_SIZE,
+ PCI_DMA_FROMDEVICE);
+ rxd->addr = cpu_to_le64(rbi->dma_addr);
+ rxd->len = rbi->len;
}
+
skb = ctx->skb;
if (rcd->eop) {
skb->len += skb->data_len;
@@ -1243,26 +1295,27 @@ vmxnet3_rq_rx_complete(struct vmxnet3_rx_queue *rq,
}
rcd_done:
- /* device may skip some rx descs */
- rq->rx_ring[ring_idx].next2comp = idx;
- VMXNET3_INC_RING_IDX_ONLY(rq->rx_ring[ring_idx].next2comp,
- rq->rx_ring[ring_idx].size);
-
- /* refill rx buffers frequently to avoid starving the h/w */
- num_to_alloc = vmxnet3_cmd_ring_desc_avail(rq->rx_ring +
- ring_idx);
- if (unlikely(num_to_alloc > VMXNET3_RX_ALLOC_THRESHOLD(rq,
- ring_idx, adapter))) {
- vmxnet3_rq_alloc_rx_buf(rq, ring_idx, num_to_alloc,
- adapter);
-
- /* if needed, update the register */
- if (unlikely(rq->shared->updateRxProd)) {
- VMXNET3_WRITE_BAR0_REG(adapter,
- rxprod_reg[ring_idx] + rq->qid * 8,
- rq->rx_ring[ring_idx].next2fill);
- rq->uncommitted[ring_idx] = 0;
- }
+ /* device may have skipped some rx descs */
+ ring->next2comp = idx;
+ num_to_alloc = vmxnet3_cmd_ring_desc_avail(ring);
+ ring = rq->rx_ring + ring_idx;
+ while (num_to_alloc) {
+ vmxnet3_getRxDesc(rxd, &ring->base[ring->next2fill].rxd,
+ &rxCmdDesc);
+ BUG_ON(!rxd->addr);
+
+ /* Recv desc is ready to be used by the device */
+ rxd->gen = ring->gen;
+ vmxnet3_cmd_ring_adv_next2fill(ring);
+ num_to_alloc--;
+ }
+
+ /* if needed, update the register */
+ if (unlikely(rq->shared->updateRxProd)) {
+ VMXNET3_WRITE_BAR0_REG(adapter,
+ rxprod_reg[ring_idx] + rq->qid * 8,
+ ring->next2fill);
+ rq->uncommitted[ring_idx] = 0;
}
vmxnet3_comp_ring_adv_next2proc(&rq->comp_ring);
diff --git a/drivers/net/vmxnet3/vmxnet3_int.h b/drivers/net/vmxnet3/vmxnet3_int.h
index 2e37985..a9cb3fa 100644
--- a/drivers/net/vmxnet3/vmxnet3_int.h
+++ b/drivers/net/vmxnet3/vmxnet3_int.h
@@ -69,10 +69,10 @@
/*
* Version numbers
*/
-#define VMXNET3_DRIVER_VERSION_STRING "1.1.9.0-k"
+#define VMXNET3_DRIVER_VERSION_STRING "1.1.14.0-k"
/* a 32-bit int, each byte encode a verion number in VMXNET3_DRIVER_VERSION */
-#define VMXNET3_DRIVER_VERSION_NUM 0x01010900
+#define VMXNET3_DRIVER_VERSION_NUM 0x01010E00
#if defined(CONFIG_PCI_MSI)
/* RSS only makes sense if MSI-X is supported. */
^ permalink raw reply related
* Re: [BUG] bd4265fe36 bridge: Only flood unreg groups... breaks DHCP setup
From: Herbert Xu @ 2011-07-05 23:58 UTC (permalink / raw)
To: Michael Guntsche; +Cc: netdev, davem
In-Reply-To: <20110705204200@it-loops.com>
Michael Guntsche <mike@it-loops.com> wrote:
>
> Looking at the changes between rc5 and rc6 I noticed commit
>
> bd4265fe365c0f3945d: bridge: Only flood unregistered groups to routers
Oops, that was definitely my fault. This patch should fix your
problem.
bridge: Always flood broadcast packets
As is_multicast_ether_addr returns true on broadcast packets as
well, we need to explicitly exclude broadcast packets so that
they're always flooded. This wasn't an issue before as broadcast
packets were considered to be an unregistered multicast group,
which were always flooded. However, as we now only flood such
packets to router ports, this is no longer acceptable.
Reported-by: Michael Guntsche <mike@it-loops.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/net/bridge/br_device.c b/net/bridge/br_device.c
index c188c80..32b8f9f 100644
--- a/net/bridge/br_device.c
+++ b/net/bridge/br_device.c
@@ -49,7 +49,9 @@ netdev_tx_t br_dev_xmit(struct sk_buff *skb, struct net_device *dev)
skb_pull(skb, ETH_HLEN);
rcu_read_lock();
- if (is_multicast_ether_addr(dest)) {
+ if (is_broadcast_ether_addr(dest))
+ br_flood_deliver(br, skb);
+ else if (is_multicast_ether_addr(dest)) {
if (unlikely(netpoll_tx_running(dev))) {
br_flood_deliver(br, skb);
goto out;
diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
index f3ac1e8..f06ee39 100644
--- a/net/bridge/br_input.c
+++ b/net/bridge/br_input.c
@@ -60,7 +60,7 @@ int br_handle_frame_finish(struct sk_buff *skb)
br = p->br;
br_fdb_update(br, p, eth_hdr(skb)->h_source);
- if (is_multicast_ether_addr(dest) &&
+ if (!is_broadcast_ether_addr(dest) && is_multicast_ether_addr(dest) &&
br_multicast_rcv(br, p, skb))
goto drop;
@@ -77,7 +77,9 @@ int br_handle_frame_finish(struct sk_buff *skb)
dst = NULL;
- if (is_multicast_ether_addr(dest)) {
+ if (is_broadcast_ether_addr(dest))
+ skb2 = skb;
+ else if (is_multicast_ether_addr(dest)) {
mdst = br_mdb_get(br, skb);
if (mdst || BR_INPUT_SKB_CB_MROUTERS_ONLY(skb)) {
if ((mdst && mdst->mglist) ||
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply related
* RE: [RFC] non-preemptible kernel socket for RAMster
From: Loke, Chetan @ 2011-07-05 22:27 UTC (permalink / raw)
To: Dan Magenheimer, netdev; +Cc: Konrad Wilk, linux-mm
In-Reply-To: <704d094e-7b81-480f-8363-327218d1b0ea@default>
> -----Original Message-----
> From: Dan Magenheimer [mailto:dan.magenheimer@oracle.com]
> Sent: July 05, 2011 3:19 PM
> To: Loke, Chetan; netdev@vger.kernel.org
> Cc: Konrad Wilk; linux-mm
> Subject: RE: [RFC] non-preemptible kernel socket for RAMster
>
> Actually, RAMster is using a much more flexible type of
> RAM-drive; it is built on top of Transcendent Memory
> and on top of zcache (and thus on top of cleancache and
> frontswap). A RAM-drive is fixed size so is not very suitable
> for the flexibility required for RAMster. For example,
> suppose you have two machines A and B. At one point in
> time A is overcommitted and needs to swap and B is relatively
> idle. Then later, B is overcommitted and needs to swap and
> A is relatively idle. RAMster can handle this entirely
> dynamically, a RAM-drive cannot.
Again, iff NBD works with a ram-drive then you really wouldn't need to
do anything. How often are you going to re-size your remote-SWAP? Plus,
you can make nbd-server listen on multiple ports - Google(Linux NBD)
returned: http://www.fi.muni.cz/~kripac/orac-nbd/ . Look at the
nbd-server code to see if it launches multiple kernel-threads for
servicing different ports. If not, one can enhance it and scale that way
too. But nbd-server today can service multiple-ports(that is effectively
servicing multiple clients). So why not add NBD-filesystem-filters to
make it point to local/remote swap?
>
> Thanks. Could you provide a pointer for this? I found
> the SCST sourceforge page but no obvious references to
> scst-in-ram-mode. (But also, since it appears to be
> SCSI-related, I wonder if it also assumes a fixed size
> target device, RAM or disk or ??)
>
Yes, it is SCSI. You should be looking for SCST I/O modes. Read some
docs and then send an email to the scst-mailing-list. If you speak about
block-IO-performance then FC(in its class of price/performance factor)
is more than capable of handling any workload. FC is a protocol designed
for storage. No exotic fabric other than FC is needed.
Folks who start with ethernet for block-IO, always start with bare
minimal code and then for squeezing block-IO performance(aka version 2
of the product), keep hacking repeatedly or go for a link-speed upgrade.
Start with FC, period.
> Dan
Chetan Loke
^ permalink raw reply
* Re: [Bugme-new] [Bug 38102] New: BUG kmalloc-2048: Poison overwritten
From: Neil Horman @ 2011-07-05 22:06 UTC (permalink / raw)
To: Eric Dumazet
Cc: Alexey Zaytsev, Michael Büsch, Andrew Morton, netdev,
Gary Zambrano, bugme-daemon, David S. Miller, Pekka Pietikainen,
Florian Schirmer, Felix Fietkau, Michael Buesch
In-Reply-To: <1309896940.2545.34.camel@edumazet-laptop>
On Tue, Jul 05, 2011 at 10:15:40PM +0200, Eric Dumazet wrote:
> Le mardi 05 juillet 2011 à 22:02 +0200, Eric Dumazet a écrit :
> > Le mardi 05 juillet 2011 à 15:53 -0400, Neil Horman a écrit :
> > > I think this is a goo idea, at least for testing. It seems odd to me that we
> > > have the B44_DMARX_PTR value which indicates (ostensibly) the pointer to the
> > > descriptor to be processed next (the documentation isnt' very verbose on the
> > > subject), along with the EOT bit on a descriptor. It seems like both the
> > > register and the bit are capable of conveying the same (or at least overlapping)
> > > information.
> > >
> > > I think what I'm having the most trouble with is understanding when the hw looks
> > > at the EOT bit in the descriptor. If it completes a DMA and sees the EOT bit
> > > set, does the next DMA occur to the descriptor pointed to by the DMARX_ADDR
> > > register? Of does it stall until such time as the DMARX_PTR register is rotated
> > > around? What if it doesn't see the EOT bit set? Does it just keep going with
> > > the next descriptor?
>
> Since there is no OWN bit (at least not on the online doc I got : it
> says the rx_ring is read only by the NIC), I would say we really need to
> advance DMARX_PTR to signal NIC a new entry is available for following
> incoming frames.
>
> This is the reason rx_pending max value is B44_RX_RING_SIZE - 1, or else
> chip could loop on a circular rx_ring.
>
Agree, although that still leaves open the question of what exactly should get
written into the DMARX_PTR. Is it an index of the descriptor number, or a byte
offset.
Regardless, I think we ned to fix up the looping so as to prevent an EOT reset
jumping outside of our valid ring window. Alexey, theres better ways to do
this, but if in the interim, you could please try this patch, it makes the valid
receive window for b44 cover the entire ring, so as to avoid this problem. It
will at least help support or refute this theory. Note its not exactly the same
as my previous patch. If you set the default ring pending to 512, the math in
the b44_alloc_rx_skb path is wrong, we skip the EOT bit as well as the first
entry in the ring. At 511 it should work out properly.
Thanks
Neil
diff --git a/drivers/net/b44.c b/drivers/net/b44.c
index 3d247f3..b7f5ed1 100644
--- a/drivers/net/b44.c
+++ b/drivers/net/b44.c
@@ -57,7 +57,7 @@
#define B44_MAX_MTU 1500
#define B44_RX_RING_SIZE 512
-#define B44_DEF_RX_RING_PENDING 200
+#define B44_DEF_RX_RING_PENDING 511
#define B44_RX_RING_BYTES (sizeof(struct dma_desc) * \
B44_RX_RING_SIZE)
#define B44_TX_RING_SIZE 512
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply related
* Hello
From: Dulce Cupen @ 2011-07-05 19:10 UTC (permalink / raw)
Please be informed that you have
$250,000.00 Lodged in our Western Union to
transfer to you as Compensation.
Please Contact Email: wumt.solodavid.uk@msnzone.cn
^ permalink raw reply
* Hello
From: Dulce Cupen @ 2011-07-05 19:47 UTC (permalink / raw)
Please be informed that you have
$250,000.00 Lodged in our Western Union to
transfer to you as Compensation.
Please Contact Email: wumt.solodavid.uk@msnzone.cn
^ permalink raw reply
* Re: possible bridge regression in "bridge: implement [add/del]_slave ops"?
From: Stephen Hemminger @ 2011-07-05 21:28 UTC (permalink / raw)
To: Alexander Stein; +Cc: David S. Miller, bridge, netdev, linux-kernel
In-Reply-To: <201106301033.23997.alexander.stein@systec-electronic.com>
I just put a fix for the detection of bridge pseudo-device being up
into the current rstp code available at:
git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/rstp.git
^ permalink raw reply
* RE: [PATCH 2/2] packet: Add fanout support.
From: Loke, Chetan @ 2011-07-05 21:10 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Victor Julien, David Miller, netdev
In-Reply-To: <1309890032.2545.8.camel@edumazet-laptop>
> -----Original Message-----
> From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
> Sent: July 05, 2011 2:21 PM
> To: Loke, Chetan
> Cc: Victor Julien; David Miller; netdev@vger.kernel.org
> Subject: RE: [PATCH 2/2] packet: Add fanout support.
>
> Le mardi 05 juillet 2011 à 13:35 -0400, Loke, Chetan a écrit :
>
> > Sure, a lookup is needed(to steer what I call - Hot/Cold flows) and
> > was proposed by me on the oisf mailing list. Always, use the ip_id
> bit
> > then? Another problem that needs to be solved is, what if some
> > decoders are overloaded, then what? How will this scheme work? How
> > will we utilize other CPUs? RPS is needed for sure.
> >
> > If we maintain a i) per port lookup-table ii) 2^20 flows/table and
> > iii) 16 bytes/flow(one can also squeeze it down to 8 bytes) then we
> > will need around 32MB worth memory/port. It's not a huge memory
> > pressure for folks who want to use linux for doing IPS/IDS sort of
> > stuff.
> >
> > User-space decoders end up copying the packet anyways. So fanout can
> > be implemented in user-space to achieve effective CPU utilization.
> > As long as we don't bounce on different CPU-socket we could be ok.
>
> This is the problem we want to address.
>
> Going into user-space to perform the fanout is what you already have
> today, with one socket, one thread doing the fanout to worker threads.
>
> David patch is non adaptative : its a hash on N queue, with a fixed
> hash
> function.
>
> What you want is to add another 'control queue' where new flows are
> directed. Then user application is able to reinject into kernel flow
> director the "This flow should go to queue X" information.
>
I like the term - 'kernel-flow-director'. The problem with rebalancing from user-space is that we will need to have some 'idle' period before we inject flow-redirection event into the kernel. And for bursty workloads this may be problematic. We may have to rebalance often. And then we will have to export the 'rebalance-idle-interval' knob.
And users may have to tune it for their workloads etc.
> Or, let the kernel do a mix of rxhash and loadbalance : Be able to
> select a queue for a new flow without user land control, using a Flow
> hash table.
>
This is exactly what I had proposed. Hash{== lookup of hot/cold flows}+LB{== kernel-flow-director} is what we need.
So something like:
hot_fanout_id = is_flow_active(rx_hash,lookup_table);
if (hot_fanout_id)
/* This flow is Hot */
steer_to(hot_fanout_id);
else {
/* This flow is cold - Get next_rr fanout_id */
fanout_rr_next(...);
...
steer_to(cold_fanout_id);
}
And,
1)hash on <src_ip_addr,dst_ip_addr,src_port,dst_port>
2)store the ip_id from the first fragment in the flow_hash_table for matching subsequent ip_fragments.
One corner case - If the first fragment arrives out-of-order(OOO).
2.1) user has configured - assemble-fragments: In this case it doesn’t matter.
2.2) user has configured - fwd-as-is: Redirect OOO-fragments to the next_rr_fanout_id.
2.2.1)
And so we may have to set a bit in hash_lookup_table for a flow indicating it arrived 'OOO'.
So, is_flow_active will have to lookup twice. First using ip_id as 3rd var in jhash. And second lookup using ports as 3rd var. Worst case there will be two lookups on OOO.
OR
2.2.2) Effectively treat this fragment as 'assemble-fragments' case(?) as in 2.1).
So {hash+LB} together, should take care of the fragmented/non-fragmented flow.
We will have to purge the flow-entry at some point to avoid false routing. Don't know if the control-queue that you mentioned above can be used for purging flows?
Or the control-queue itself can be mmap'd so that user-space can clear 'a' flow-entry?
Chetan Loke
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox