All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jun Zhao <mypopydev@gmail.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: monstr@monstr.eu, David Miller <davem@davemloft.net>,
	John Williams <john.williams@petalogix.com>,
	netdev@vger.kernel.org
Subject: Re: ICMP packets - ll_temac with Microblaze
Date: Thu, 22 Dec 2011 00:01:42 +0800	[thread overview]
Message-ID: <1324483302.6471.3.camel@barry.pixelworks.com> (raw)
In-Reply-To: <1324482285.2301.9.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>

On Wed, 2011-12-21 at 16:44 +0100, Eric Dumazet wrote:
> Le mercredi 21 décembre 2011 à 16:30 +0100, Eric Dumazet a écrit :
> > Le mercredi 21 décembre 2011 à 15:24 +0100, Michal Simek a écrit :
> > > Eric Dumazet wrote:
> > > > Le mercredi 21 décembre 2011 à 14:28 +0100, Michal Simek a écrit :
> > > > 
> > > >> ok. Can you provide me any background why size should be setup by
> > > >> size = SKB_WITH_OVERHEAD(ksize(data));
> > > >> and not to use size which is passed to kmalloc in __alloc_skb.
> > > > 
> > > > Its all about memory accounting (based on skb->truesize)
> > > > 
> > > > Prior to the patch, we could fool memory accounting because skbs claimed
> > > > to use less memory than what they really used.
> > > > 
> > > > And crash machines eventually.
> > > > 
> > > > Now memory accouting is fixed, we probably need to change some points in
> > > > the kernel, where we previously accepted a small skb, but not a very
> > > > large one.
> > > > 
> > > > Since "ping" probably uses SOCK_RAW sockets, I'll try this one :
> > > > 
> > > > (We dont care of _this_ skb truesize, only on the count of previously
> > > > queued packets)
> > > > 
> > > > 
> > > > diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
> > > > index 0da505c..a809a48 100644
> > > > --- a/net/packet/af_packet.c
> > > > +++ b/net/packet/af_packet.c
> > > > @@ -1631,8 +1631,7 @@ static int packet_rcv(struct sk_buff *skb, struct net_device *dev,
> > > >  	if (snaplen > res)
> > > >  		snaplen = res;
> > > >  
> > > > -	if (atomic_read(&sk->sk_rmem_alloc) + skb->truesize >=
> > > > -	    (unsigned)sk->sk_rcvbuf)
> > > > +	if (atomic_read(&sk->sk_rmem_alloc) >= (unsigned)sk->sk_rcvbuf)
> > > >  		goto drop_n_acct;
> > > >  
> > > >  	if (skb_shared(skb)) {
> > > > @@ -1763,7 +1762,7 @@ static int tpacket_rcv(struct sk_buff *skb, struct net_device *dev,
> > > >  	if (po->tp_version <= TPACKET_V2) {
> > > >  		if (macoff + snaplen > po->rx_ring.frame_size) {
> > > >  			if (po->copy_thresh &&
> > > > -				atomic_read(&sk->sk_rmem_alloc) + skb->truesize
> > > > +				atomic_read(&sk->sk_rmem_alloc)
> > > >  				< (unsigned)sk->sk_rcvbuf) {
> > > >  				if (skb_shared(skb)) {
> > > >  					copy_skb = skb_clone(skb, GFP_ATOMIC);
> > > > 
> > > > 
> > > > 
> > > > 
> > > 
> > > It doesn't work too.
> > > It is possible to see this behavior on qemu. What about if I prepare you package with cross toolchain, rootfs
> > > and you can add debug message where you want?
> > > 
> > > I have also tried ll_temac driver with ppc440 and behavior is the same.
> > > 
> > > Max FRAME_SIZE pass to netdev_alloc_skb_ip_align is 7966. For this value ping works.
> > > (For ll_temac driver it is #define XTE_JUMBO_MTU 7948 from ll_temac.h)
> > 
> > I did several tests with MTU 9000 on my machines and it works well.
> > 
> > It seems my pings (iputils-sss20071127 or iputils-sss20101006) uses a
> > big enough RCVBUF
> > 
> > setsockopt(3, SOL_SOCKET, SO_RCVBUF, [65536], 4) = 0
> > getsockopt(3, SOL_SOCKET, SO_RCVBUF, [131072], [4]) = 0
> > 
> > Could you check with "strace ping..." what is doing busybox ?
> 
> I found it : Its too small for jumbo frames.
> 
> setsockopt(3, SOL_SOCKET, SO_RCVBUF, [7280], 4) = 0
> 
> networking/ping.c
> 
> 
>         /* set recv buf (needed if we can get lots of responses: flood ping,
>          * broadcast ping etc) */
>         sockopt = (datalen * 2) + 7 * 1024; /* giving it a bit of extra room */
>         setsockopt(pingsock, SOL_SOCKET, SO_RCVBUF, &sockopt, sizeof(sockopt));
> 
> 
> 
> --

Why receive buffer size MUST bigger than the jumbo frames size even if
the packet size is small?

> 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

  reply	other threads:[~2011-12-21 16:02 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-21 10:11 ICMP packets - ll_temac with Microblaze Michal Simek
2011-12-21 10:28 ` Eric Dumazet
2011-12-21 10:30   ` Michal Simek
2011-12-21 10:30   ` Eric Dumazet
2011-12-21 10:32     ` Michal Simek
2011-12-21 10:37       ` Eric Dumazet
2011-12-21 10:41         ` Michal Simek
2011-12-21 10:45           ` Eric Dumazet
2011-12-21 10:54             ` Michal Simek
2011-12-21 11:05               ` Eric Dumazet
2011-12-21 11:03             ` Eric Dumazet
2011-12-21 11:10               ` Michal Simek
2011-12-21 11:13                 ` Eric Dumazet
2011-12-21 11:50                   ` Michal Simek
2011-12-21 12:39                     ` Eric Dumazet
2011-12-21 13:28                       ` Michal Simek
2011-12-21 13:40                         ` Eric Dumazet
2011-12-21 14:24                           ` Michal Simek
2011-12-21 15:30                             ` Eric Dumazet
2011-12-21 15:44                               ` Eric Dumazet
2011-12-21 16:01                                 ` Jun Zhao [this message]
2011-12-21 16:05                                   ` Eric Dumazet
2011-12-21 16:11                                     ` Jun Zhao
2011-12-21 16:39                                     ` David Laight
2011-12-21 16:50                                       ` Eric Dumazet
2011-12-21 15:59                             ` Eric Dumazet
2011-12-21 17:11                               ` Eric Dumazet
2011-12-21 20:55                                 ` David Miller
2011-12-22  7:49                                   ` Michal Simek
2011-12-22  7:57                                     ` Eric Dumazet
2011-12-22  8:05                                       ` Michal Simek
2011-12-22 10:32 ` Michael Wang
2011-12-22 10:46   ` Eric Dumazet
2011-12-22 13:01     ` Michael Wang
2011-12-22 13:21       ` Eric Dumazet
2011-12-22 13:42         ` Michael Wang

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=1324483302.6471.3.camel@barry.pixelworks.com \
    --to=mypopydev@gmail.com \
    --cc=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=john.williams@petalogix.com \
    --cc=monstr@monstr.eu \
    --cc=netdev@vger.kernel.org \
    /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.