From: Stephen Hemminger <shemminger@vyatta.com>
To: Andy Grover <andy.grover@oracle.com>
Cc: rdreier@cisco.com, rds-devel@oss.oracle.com,
general@lists.openfabrics.org, netdev@vger.kernel.org
Subject: Re: [PATCH 03/21] RDS: Congestion-handling code
Date: Mon, 26 Jan 2009 19:48:20 -0800 [thread overview]
Message-ID: <20090126194820.41cdb7f5@extreme> (raw)
In-Reply-To: <1233022678-9259-4-git-send-email-andy.grover@oracle.com>
On Mon, 26 Jan 2009 18:17:40 -0800
Andy Grover <andy.grover@oracle.com> wrote:
> RDS handles per-socket congestion by updating peers with a complete
> congestion map (8KB). This code keeps track of these maps for itself
> and ones received from peers.
>
> Signed-off-by: Andy Grover <andy.grover@oracle.com>
> ---
> drivers/infiniband/ulp/rds/cong.c | 424 +++++++++++++++++++++++++++++++++++++
> 1 files changed, 424 insertions(+), 0 deletions(-)
> create mode 100644 drivers/infiniband/ulp/rds/cong.c
>
> diff --git a/drivers/infiniband/ulp/rds/cong.c b/drivers/infiniband/ulp/rds/cong.c
> new file mode 100644
> index 0000000..b7c49d2
> --- /dev/null
> +++ b/drivers/infiniband/ulp/rds/cong.c
> @@ -0,0 +1,424 @@
> +/*
> + * Copyright (c) 2007 Oracle. All rights reserved.
> + *
> + * This software is available to you under a choice of one of two
> + * licenses. You may choose to be licensed under the terms of the GNU
> + * General Public License (GPL) Version 2, available from the file
> + * COPYING in the main directory of this source tree, or the
> + * OpenIB.org BSD license below:
> + *
> + * Redistribution and use in source and binary forms, with or
> + * without modification, are permitted provided that the following
> + * conditions are met:
> + *
> + * - Redistributions of source code must retain the above
> + * copyright notice, this list of conditions and the following
> + * disclaimer.
> + *
> + * - Redistributions in binary form must reproduce the above
> + * copyright notice, this list of conditions and the following
> + * disclaimer in the documentation and/or other materials
> + * provided with the distribution.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
> + * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
> + * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
> + * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
> + * SOFTWARE.
> + *
> + */
> +#include <linux/types.h>
> +#include <linux/rbtree.h>
> +
> +#include "rds.h"
> +
> +/*
> + * This file implements the receive side of the unconventional congestion
> + * management in RDS.
> + *
> + * Messages waiting in the receive queue on the receiving socket are accounted
> + * against the sockets SO_RCVBUF option value. Only the payload bytes in the
> + * message are accounted for. If the number of bytes queued equals or exceeds
> + * rcvbuf then the socket is congested. All sends attempted to this socket's
> + * address should return block or return -EWOULDBLOCK.
> + *
> + * Applications are expected to be reasonably tuned such that this situation
> + * very rarely occurs. An application encountering this "back-pressure" is
> + * considered a bug.
> + *
> + * This is implemented by having each node maintain bitmaps which indicate
> + * which ports on bound addresses are congested. As the bitmap changes it is
> + * sent through all the connections which terminate in the local address of the
> + * bitmap which changed.
> + *
> + * The bitmaps are allocated as connections are brought up. This avoids
> + * allocation in the interrupt handling path which queues messages on sockets.
> + * The dense bitmaps let transports send the entire bitmap on any bitmap change
> + * reasonably efficiently. This is much easier to implement than some
> + * finer-grained communication of per-port congestion. The sender does a very
> + * inexpensive bit test to test if the port it's about to send to is congested
> + * or not.
> + */
> +
> +/*
> + * Interaction with poll is a tad tricky. We want all processes stuck in
> + * poll to wake up and check whether a congested destination became uncongested.
> + * The really sad thing is we have no idea which destinations the application
> + * wants to send to - we don't even know which rds_connections are involved.
> + * So until we implement a more flexible rds poll interface, we have to make
> + * do with this:
> + * We maintain a global counter that is incremented each time a congestion map
> + * update is received. Each rds socket tracks this value, and if rds_poll
> + * finds that the saved generation number is smaller than the global generation
> + * number, it wakes up the process.
> + */
> +static atomic_t rds_cong_generation = ATOMIC_INIT(0);
> +
> +/*
> + * Congestion monitoring
> + */
> +static LIST_HEAD(rds_cong_monitor);
> +static DEFINE_RWLOCK(rds_cong_monitor_lock);
> +
> +/*
> + * Yes, a global lock. It's used so infrequently that it's worth keeping it
> + * global to simplify the locking. It's only used in the following
> + * circumstances:
> + *
> + * - on connection buildup to associate a conn with its maps
> + * - on map changes to inform conns of a new map to send
> + *
> + * It's sadly ordered under the socket callback lock and the connection lock.
> + * Receive paths can mark ports congested from interrupt context so the
> + * lock masks interrupts.
> + */
So this is starting to look like another "Oracle special" like AIO
and HugeTLB. That has lots of caveat restrictions on the application.
next prev parent reply other threads:[~2009-01-27 3:48 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-27 2:17 [ofa-general] [PATCH 0/21] Reliable Datagram Sockets (RDS) Andy Grover
2009-01-27 2:17 ` [ofa-general] [PATCH 01/21] RDS: Socket interface Andy Grover
2009-01-27 3:46 ` Stephen Hemminger
2009-01-29 3:17 ` [ofa-general] " Andrew Grover
2009-01-27 4:11 ` David Miller
2009-01-29 20:22 ` [ofa-general] ***SPAM*** " Andrew Grover
2009-01-27 12:08 ` Evgeniy Polyakov
2009-01-29 4:02 ` [ofa-general] " Andrew Grover
2009-01-29 16:24 ` Evgeniy Polyakov
2009-01-27 2:17 ` [ofa-general] [PATCH 02/21] RDS: Main header file Andy Grover
2009-01-27 7:34 ` Rémi Denis-Courmont
2009-01-27 19:27 ` [ofa-general] " Andrew Grover
2009-01-27 13:05 ` Evgeniy Polyakov
2009-01-27 19:23 ` [ofa-general] ***SPAM*** " Andrew Grover
2009-01-27 19:24 ` Steve Wise
2009-01-27 2:17 ` [PATCH 03/21] RDS: Congestion-handling code Andy Grover
2009-01-27 3:48 ` Stephen Hemminger [this message]
2009-01-27 19:15 ` Andrew Grover
2009-01-27 13:10 ` Evgeniy Polyakov
2009-01-27 19:10 ` Andrew Grover
2009-01-28 22:57 ` Roland Dreier
2009-01-29 2:39 ` [ofa-general] " Andy Grover
2009-01-27 2:17 ` [PATCH 04/21] RDS: Transport code Andy Grover
2009-01-27 13:18 ` Evgeniy Polyakov
2009-01-27 19:36 ` Andrew Grover
2009-01-27 21:56 ` [ofa-general] " Evgeniy Polyakov
2009-01-27 22:15 ` [ofa-general] ***SPAM*** " Andrew Grover
2009-01-27 2:17 ` [ofa-general] [PATCH 05/21] RDS: Info and stats Andy Grover
2009-01-27 13:28 ` Evgeniy Polyakov
2009-01-27 2:17 ` [PATCH 06/21] RDS: Connection handling Andy Grover
2009-01-27 13:34 ` Evgeniy Polyakov
2009-01-27 13:47 ` Oliver Neukum
2009-01-27 13:51 ` Evgeniy Polyakov
2009-01-27 16:28 ` [ofa-general] " Steve Wise
2009-01-29 3:03 ` ***SPAM*** " Andrew Grover
2009-01-29 8:03 ` Evgeniy Polyakov
2009-01-27 2:17 ` [PATCH 07/21] RDS: loopback Andy Grover
2009-01-27 2:17 ` [PATCH 08/21] RDS: sysctls Andy Grover
2009-01-27 2:17 ` [PATCH 09/21] RDS: Message parsing Andy Grover
2009-01-27 2:17 ` [PATCH 10/21] RDS: send.c Andy Grover
2009-01-27 2:17 ` [PATCH 11/21] RDS: recv.c Andy Grover
2009-01-27 2:17 ` [PATCH 12/21] RDS: RDMA support Andy Grover
2009-01-27 2:17 ` [ofa-general] [PATCH 13/21] RDS/IB: Infiniband transport Andy Grover
2009-01-27 2:17 ` [PATCH 14/21] RDS/IB: Ring-handling code Andy Grover
2009-01-27 2:17 ` [PATCH 15/21] RDS/IB: Implement RDMA ops using FMRs Andy Grover
2009-01-27 2:17 ` [PATCH 16/21] RDS/IB: Implement IB-specific datagram send Andy Grover
2009-01-27 2:17 ` [PATCH 17/21] RDS/IB: Receive datagrams via IB Andy Grover
2009-01-29 0:05 ` [ofa-general] " Roland Dreier
2009-01-29 2:20 ` Andy Grover
2009-01-29 21:02 ` Olaf Kirch
2009-01-29 21:47 ` [ofa-general] " Roland Dreier
2009-01-27 2:17 ` [PATCH 18/21] RDS/IB: Stats and sysctls Andy Grover
2009-01-27 2:17 ` [PATCH 19/21] RDS: Documentation Andy Grover
2009-01-27 2:17 ` [PATCH 20/21] RDS: Kconfig and Makefile Andy Grover
2009-01-28 22:59 ` Roland Dreier
2009-01-29 2:19 ` [ofa-general] " Andy Grover
2009-01-29 5:14 ` Roland Dreier
2009-01-27 2:17 ` [PATCH 21/21] RDS: Add AF and PF #defines for RDS sockets Andy Grover
2009-01-27 7:27 ` Rémi Denis-Courmont
2009-01-27 19:31 ` [ofa-general] " Andrew Grover
2009-01-27 15:34 ` [ofa-general] [PATCH 0/21] Reliable Datagram Sockets (RDS) Steve Wise
2009-01-27 19:29 ` ***SPAM*** " Andrew Grover
2009-01-28 22:37 ` Roland Dreier
2009-01-29 1:29 ` [ofa-general] " Andy Grover
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090126194820.41cdb7f5@extreme \
--to=shemminger@vyatta.com \
--cc=andy.grover@oracle.com \
--cc=general@lists.openfabrics.org \
--cc=netdev@vger.kernel.org \
--cc=rdreier@cisco.com \
--cc=rds-devel@oss.oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).