All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hideo AOKI <haoki@redhat.com>
To: David Miller <davem@davemloft.net>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	vladislav.yasevich@hp.com, netdev <netdev@vger.kernel.org>,
	lksctp-developers@lists.sourceforge.net
Cc: Takahiro Yasui <tyasui@redhat.com>,
	Masami Hiramatsu <mhiramat@redhat.com>,
	Satoshi Oshima <satoshi.oshima.fk@hitachi.com>,
	billfink@mindspring.com, Andi Kleen <andi@firstfloor.org>,
	Evgeniy Polyakov <johnpol@2ka.mipt.ru>,
	Stephen Hemminger <shemminger@linux-foundation.org>,
	yoshfuji@linux-ipv6.org,
	Yumiko Sugita <yumiko.sugita.yf@hitachi.com>,
	haoki@redhat.com
Subject: [PATCH 4/4] [SCTP]: using new interface
Date: Sun, 30 Dec 2007 03:54:26 -0500	[thread overview]
Message-ID: <47775CC2.3040501@redhat.com> (raw)
In-Reply-To: <47775B25.7020401@redhat.com>

This patch replaces present memory accounting calls with new interface
in SCTP.

Cc: Satoshi Oshima <satoshi.oshima.fk@hitachi.com>
Cc: Masami Hiramatsu <mhiramat@redhat.com>
signed-off-by: Takahiro Yasui <tyasui@redhat.com>
signed-off-by: Hideo Aoki <haoki@redhat.com>
---

 include/net/sctp/sctp.h |    3 +--
 net/sctp/protocol.c     |    2 +-
 net/sctp/sm_statefuns.c |    2 +-
 net/sctp/socket.c       |   11 ++++++-----
 net/sctp/ulpevent.c     |    2 +-
 net/sctp/ulpqueue.c     |    2 +-
 6 files changed, 11 insertions(+), 11 deletions(-)

diff -pruN net-2.6.25-t12t19m-p3/include/net/sctp/sctp.h net-2.6.25-t12t19m-p4/include/net/sctp/sctp.h
--- net-2.6.25-t12t19m-p3/include/net/sctp/sctp.h	2007-12-27 10:18:58.000000000 -0500
+++ net-2.6.25-t12t19m-p4/include/net/sctp/sctp.h	2007-12-29 20:59:06.000000000 -0500
@@ -463,8 +463,7 @@ static inline void sctp_skb_set_owner_r(
 	skb->destructor = sctp_sock_rfree;
 	atomic_add(event->rmem_len, &sk->sk_rmem_alloc);
 	/*
-	 * This mimics the behavior of
-	 * sk_stream_set_owner_r
+	 * This mimics the behavior of skb_set_owner_r
 	 */
 	sk->sk_forward_alloc -= event->rmem_len;
 }
diff -pruN net-2.6.25-t12t19m-p3/net/sctp/protocol.c net-2.6.25-t12t19m-p4/net/sctp/protocol.c
--- net-2.6.25-t12t19m-p3/net/sctp/protocol.c	2007-12-27 10:19:02.000000000 -0500
+++ net-2.6.25-t12t19m-p4/net/sctp/protocol.c	2007-12-29 20:59:06.000000000 -0500
@@ -1109,7 +1109,7 @@ SCTP_STATIC __init int sctp_init(void)
 	sysctl_sctp_rmem[1] = (1500 *(sizeof(struct sk_buff) + 1));
 	sysctl_sctp_rmem[2] = max(sysctl_sctp_rmem[1], max_share);

-	sysctl_sctp_wmem[0] = SK_STREAM_MEM_QUANTUM;
+	sysctl_sctp_wmem[0] = SK_MEM_QUANTUM;
 	sysctl_sctp_wmem[1] = 16*1024;
 	sysctl_sctp_wmem[2] = max(64*1024, max_share);

diff -pruN net-2.6.25-t12t19m-p3/net/sctp/sm_statefuns.c net-2.6.25-t12t19m-p4/net/sctp/sm_statefuns.c
--- net-2.6.25-t12t19m-p3/net/sctp/sm_statefuns.c	2007-12-27 10:19:02.000000000 -0500
+++ net-2.6.25-t12t19m-p4/net/sctp/sm_statefuns.c	2007-12-29 20:59:06.000000000 -0500
@@ -5866,7 +5866,7 @@ static int sctp_eat_data(const struct sc
 	/*
 	 * Also try to renege to limit our memory usage in the event that
 	 * we are under memory pressure
-	 * If we can't renege, don't worry about it, the sk_stream_rmem_schedule
+	 * If we can't renege, don't worry about it, the sk_rmem_schedule
 	 * in sctp_ulpevent_make_rcvmsg will drop the frame if we grow our
 	 * memory usage too much
 	 */
diff -pruN net-2.6.25-t12t19m-p3/net/sctp/socket.c net-2.6.25-t12t19m-p4/net/sctp/socket.c
--- net-2.6.25-t12t19m-p3/net/sctp/socket.c	2007-12-27 10:19:02.000000000 -0500
+++ net-2.6.25-t12t19m-p4/net/sctp/socket.c	2007-12-29 20:59:06.000000000 -0500
@@ -174,7 +174,8 @@ static inline void sctp_set_owner_w(stru
 				sizeof(struct sctp_chunk);

 	atomic_add(sizeof(struct sctp_chunk), &sk->sk_wmem_alloc);
-	sk_charge_skb(sk, chunk->skb);
+	sk->sk_wmem_queued += chunk->skb->truesize;
+	sk_mem_charge(sk, chunk->skb->truesize);
 }

 /* Verify that this is a valid address. */
@@ -6035,10 +6036,10 @@ static void sctp_wfree(struct sk_buff *s
 	atomic_sub(sizeof(struct sctp_chunk), &sk->sk_wmem_alloc);

 	/*
-	 * This undoes what is done via sk_charge_skb
+	 * This undoes what is done via sctp_set_owner_w and sk_mem_charge
 	 */
 	sk->sk_wmem_queued   -= skb->truesize;
-	sk->sk_forward_alloc += skb->truesize;
+	sk_mem_uncharge(sk, skb->truesize);

 	sock_wfree(skb);
 	__sctp_write_space(asoc);
@@ -6059,9 +6060,9 @@ void sctp_sock_rfree(struct sk_buff *skb
 	atomic_sub(event->rmem_len, &sk->sk_rmem_alloc);

 	/*
-	 * Mimic the behavior of sk_stream_rfree
+	 * Mimic the behavior of sock_rfree
 	 */
-	sk->sk_forward_alloc += event->rmem_len;
+	sk_mem_uncharge(sk, event->rmem_len);
 }


diff -pruN net-2.6.25-t12t19m-p3/net/sctp/ulpevent.c net-2.6.25-t12t19m-p4/net/sctp/ulpevent.c
--- net-2.6.25-t12t19m-p3/net/sctp/ulpevent.c	2007-12-27 10:19:02.000000000 -0500
+++ net-2.6.25-t12t19m-p4/net/sctp/ulpevent.c	2007-12-29 20:59:06.000000000 -0500
@@ -700,7 +700,7 @@ struct sctp_ulpevent *sctp_ulpevent_make
 	if (rx_count >= asoc->base.sk->sk_rcvbuf) {

 		if ((asoc->base.sk->sk_userlocks & SOCK_RCVBUF_LOCK) ||
-		   (!sk_stream_rmem_schedule(asoc->base.sk, chunk->skb)))
+		    (!sk_rmem_schedule(asoc->base.sk, chunk->skb->truesize)))
 			goto fail;
 	}

diff -pruN net-2.6.25-t12t19m-p3/net/sctp/ulpqueue.c net-2.6.25-t12t19m-p4/net/sctp/ulpqueue.c
--- net-2.6.25-t12t19m-p3/net/sctp/ulpqueue.c	2007-12-27 10:19:02.000000000 -0500
+++ net-2.6.25-t12t19m-p4/net/sctp/ulpqueue.c	2007-12-29 20:59:06.000000000 -0500
@@ -1046,7 +1046,7 @@ void sctp_ulpq_renege(struct sctp_ulpq *
 		sctp_ulpq_partial_delivery(ulpq, chunk, gfp);
 	}

-	sk_stream_mem_reclaim(asoc->base.sk);
+	sk_mem_reclaim(asoc->base.sk);
 	return;
 }

-- 
Hitachi Computer Products (America) Inc.

  parent reply	other threads:[~2007-12-30  8:59 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-30  8:47 [PATCH 0/4] New interface for memory accounting (take 1) Hideo AOKI
2007-12-30  8:51 ` [PATCH 1/4] [CORE]: introducing new memory accounting interface Hideo AOKI
2007-12-30  8:51 ` [PATCH 2/4] [CORE]: adding memory accounting points Hideo AOKI
2007-12-31  7:58   ` David Miller
2007-12-31 18:52     ` Hideo AOKI
2007-12-30  8:53 ` [PATCH 3/4] [TCP]: using new interface Hideo AOKI
2007-12-30  8:54 ` Hideo AOKI [this message]
2007-12-31  7:34 ` [PATCH 0/4] New interface for memory accounting (take 1) David Miller
2007-12-31 15:17   ` Eric Dumazet
2007-12-31 19:03     ` Hideo AOKI
2007-12-31 23:01     ` David Miller
2007-12-31 18:46   ` Hideo AOKI

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=47775CC2.3040501@redhat.com \
    --to=haoki@redhat.com \
    --cc=andi@firstfloor.org \
    --cc=billfink@mindspring.com \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=johnpol@2ka.mipt.ru \
    --cc=lksctp-developers@lists.sourceforge.net \
    --cc=mhiramat@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=satoshi.oshima.fk@hitachi.com \
    --cc=shemminger@linux-foundation.org \
    --cc=tyasui@redhat.com \
    --cc=vladislav.yasevich@hp.com \
    --cc=yoshfuji@linux-ipv6.org \
    --cc=yumiko.sugita.yf@hitachi.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.