From: Eric Dumazet <eric.dumazet@gmail.com>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: netdev@vger.kernel.org, davem@davemloft.net, socketcan@hartkopp.net
Subject: Re: [PATCH] Generalize socket rx gap / receive queue overflow cmsg (v3)
Date: Sat, 10 Oct 2009 06:59:53 +0200 [thread overview]
Message-ID: <4AD014C9.2010801@gmail.com> (raw)
In-Reply-To: <20091009235631.GA31501@hmsreliant.think-freely.org>
Neil Horman a écrit :
> Ok, take 3 with Erics new notes
>
> Change Notes:
>
> 1) Modified inlining of sock_recv_ts_and_drops to be more efficient
>
> 2) modify getsockopt for SO_RXQ_OVFL to gurantee only a 1 or 0 return
>
> =============================================================
>
>
> Create a new socket level option to report number of queue overflows
>
> Recently I augmented the AF_PACKET protocol to report the number of frames lost
> on the socket receive queue between any two enqueued frames. This value was
> exported via a SOL_PACKET level cmsg. AFter I completed that work it was
> requested that this feature be generalized so that any datagram oriented socket
> could make use of this option. As such I've created this patch, It creates a
> new SOL_SOCKET level option called SO_RXQ_OVFL, which when enabled exports a
> SOL_SOCKET level cmsg that reports the nubmer of times the sk_receive_queue
> overflowed between any two given frames. It also augments the AF_PACKET
> protocol to take advantage of this new feature (as it previously did not touch
> sk->sk_drops, which this patch uses to record the overflow count). Tested
> successfully by me.
>
> Notes:
>
> 1) Unlike my previous patch, this patch simply records the sk_drops value, which
> is not a number of drops between packets, but rather a total number of drops.
> Deltas must be computed in user space.
>
> 2) While this patch currently works with datagram oriented protocols, it will
> also be accepted by non-datagram oriented protocols. I'm not sure if thats
> agreeable to everyone, but my argument in favor of doing so is that, for those
> protocols which aren't applicable to this option, sk_drops will always be zero,
> and reporting no drops on a receive queue that isn't used for those
> non-participating protocols seems reasonable to me. This also saves us having
> to code in a per-protocol opt in mechanism.
>
> 3) This applies cleanly to net-next assuming that commit
> 977750076d98c7ff6cbda51858bb5a5894a9d9ab (my af packet cmsg patch) is reverted
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
I read your patch and found one error (at the very end)
Feel free to resubmit with my
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>
> +inline void sock_recv_drops(struct msghdr *msg, struct sock *sk, struct sk_buff *skb)
> +{
> + if (sock_flag(sk, SOCK_RXQ_OVFL) && skb && skb->dropcount)
> + put_cmsg(msg, SOL_SOCKET, SO_RXQ_OVFL,
> + sizeof(__u32), &skb->dropcount);
> +}
> +
> +void sock_recv_ts_and_drops(struct msghdr *msg, struct sock *sk,
> + struct sk_buff *skb)
> +{
> + sock_recv_timestamp(msg, sk, skb);
> + sock_recv_drops(msg, sk, skb);
> + put_cmsg(msg, SOL_SOCKET, SO_RXQ_OVFL, sizeof(__u32), &skb->dropcount);
It's already part of sock_recv_drops()
> +}
> +EXPORT_SYMBOL_GPL(sock_recv_ts_and_drops);
> +
next prev parent reply other threads:[~2009-10-10 5:00 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-07 18:08 [PATCH] Generalize socket rx gap / receive queue overflow cmsg Neil Horman
2009-10-08 1:05 ` Eric Dumazet
2009-10-08 13:54 ` Neil Horman
2009-10-08 14:45 ` Eric Dumazet
2009-10-08 17:20 ` Neil Horman
2009-10-09 19:35 ` [PATCH] Generalize socket rx gap / receive queue overflow cmsg (v2) Neil Horman
2009-10-09 21:31 ` Eric Dumazet
2009-10-09 23:21 ` Neil Horman
2009-10-09 23:56 ` [PATCH] Generalize socket rx gap / receive queue overflow cmsg (v3) Neil Horman
2009-10-10 4:59 ` Eric Dumazet [this message]
2009-10-10 5:12 ` Eric Dumazet
2009-10-10 12:35 ` [PATCH] Generalize socket rx gap / receive queue overflow cmsg (v4) Neil Horman
2009-10-12 4:38 ` Eric Dumazet
2009-10-12 5:48 ` Oliver Hartkopp
2009-10-12 10:01 ` David Miller
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=4AD014C9.2010801@gmail.com \
--to=eric.dumazet@gmail.com \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=nhorman@tuxdriver.com \
--cc=socketcan@hartkopp.net \
/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.