From: Andi Kleen <andi@firstfloor.org>
To: Christoph Lameter <cl@linux-foundation.org>
Cc: David Miller <davem@davemloft.net>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: Add PGM protocol support to the IP stack
Date: Mon, 22 Mar 2010 18:43:06 +0100 [thread overview]
Message-ID: <877hp4i76d.fsf@basil.nowhere.org> (raw)
In-Reply-To: <alpine.DEB.2.00.1003221146260.17230@router.home> (Christoph Lameter's message of "Mon, 22 Mar 2010 11:51:08 -0500 (CDT)")
Christoph Lameter <cl@linux-foundation.org> writes:
> On Mon, 22 Mar 2010, Andi Kleen wrote:
>
>> Multicast reliable kernel protocols are somewhat new, I guess one
>> would need to make sure to come up with a clean generic interface
>> for them first.
>
> It has been around for a long time in another OS. I wonder if I should use
> the socket API realized there as a model or come up with something new
> from scratch?
If the other API doesn't have a serious flaw I guess it's better
to aim for a sub/superset at least, to make porting applications easier.
>
> What I have right now is:
>
> 1. Opening a socket
>
> A. Native PGM
>
> fd = socket(AF_INET, SOCK_RDM, IPPROTO_PGM)
RDM = Reliable ? Multicast ?
> B. PGM over UDP
>
> fd = socket(AF_INET, SOCK_RDM, IPPROTO_UDP)
>
> C. PGM over SHM (?)
>
> fd = socket(AF_UNIX, SOCK_RDM, 0)
Not sure how that should work.
> 3. Sending and receiving
>
> Use the usual socket read and write operations and the various flavors of waiting
> for a packet via select, poll, epoll etc.
>
> Packet sizes are determined by the number of packets in a single sendmsg() unless
Number of bytes surely?
> overridden by the RM_SET_MESSAGE_BOUNDARY socket option.
That's unusual to have such a option (except the MTU). What is it good for?
>
> 4. Transmitter Socket Options
>
>
> A. Setting the window size / rate.
>
> struct pgm_send_window x;
> x.RateKbitsPerSec = 56;
> x.WindowSizeInMsecs = 60000;
> x.WindowSizeinBytes = 10000000;
>
> setsockopt(fd, SOCK_RDM, RM_RATE_WINDOW_SIZE, &x, sizeof(x));
>
> Default is sending at 56Kbps with a buffer of 10 Megabytes and buffering for a minute.
That's a very large buffer for a socket. It would be better to use the usual
auto shrinking/increasing mechanisms.
> B. FEC mode
>
> struct pgm_fec_info x;
>
> x.FECBlocksize = 255;
> x.FECProActivePackets = 0;
> x.FECGroupSize = 0;
> x.fFECOnDemandParityEnabled = 1;
>
> setsockopt(fd, SOCK_RDM, RM_FEC_MODE, &x, sizeof(x));
Is that mode really needed?
> /* Socket API structures (established by M$DN) */
> struct pgm_receiver_stats {
> u64 NumODataPacketsReceived; /* Number of ODATA (original) sequences */
It's difficult to maintain 64 bit counters on 32bit hosts on all targets.
But I guess it would be ok to only fill in 32bit in this case.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
next prev parent reply other threads:[~2010-03-22 17:43 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-18 17:58 Add PGM protocol support to the IP stack Christoph Lameter
2010-03-18 21:58 ` Christoph Lameter
2010-03-19 17:18 ` Andi Kleen
2010-03-19 21:53 ` David Miller
2010-03-19 22:26 ` H. Peter Anvin
2010-03-22 14:24 ` Christoph Lameter
2010-03-22 14:20 ` Christoph Lameter
2010-03-22 16:36 ` Andi Kleen
2010-03-22 16:51 ` Christoph Lameter
2010-03-22 17:43 ` Andi Kleen [this message]
2010-03-22 18:07 ` Christoph Lameter
2010-03-22 18:53 ` Andi Kleen
2010-03-22 19:32 ` Christoph Lameter
2010-03-26 17:33 ` Christoph Lameter
2010-03-27 13:11 ` Andi Kleen
2010-03-27 16:54 ` Martin Sustrik
2010-03-29 14:50 ` Christoph Lameter
2010-03-29 15:00 ` Christoph Lameter
2010-03-29 21:43 ` Andi Kleen
2010-03-29 23:01 ` H. Peter Anvin
2010-03-30 18:12 ` Christoph Lameter
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=877hp4i76d.fsf@basil.nowhere.org \
--to=andi@firstfloor.org \
--cc=cl@linux-foundation.org \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--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.