netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Miller <davem@davemloft.net>
To: jon.maloy@ericsson.com
Cc: eric.dumazet@gmail.com, netdev@vger.kernel.org,
	paul.gortmaker@windriver.com, erik.hugne@ericsson.com,
	ying.xue@windriver.com, maloy@donjonn.com,
	tipc-discussion@lists.sourceforge.net
Subject: Re: [PATCH net-next v2 2/8] tipc: compensate for double accounting in socket rcv buffer
Date: Wed, 14 May 2014 13:37:16 -0400 (EDT)	[thread overview]
Message-ID: <20140514.133716.106221573887805156.davem@davemloft.net> (raw)
In-Reply-To: <A2BAEFC30C8FD34388F02C9B3121859D1C25134A@eusaamb103.ericsson.se>

From: Jon Maloy <jon.maloy@ericsson.com>
Date: Wed, 14 May 2014 12:53:45 +0000

> Because TCP can throw away packet in such situations, and TIPC cannot.

Just want to state for the record that I consider any transport,
even over directly connected ethernet, that cannot retransmit at
the socket level and does not accomodate packet reordering, to be
fundamentally flawed.

Even if you can absolutely prove that ethernet is %100 drop free and
will never reorder your frames, some of those things can always happen
in the system itself since memory is not infinite and your protocol
is not the only consumer of kernel memory in the system.

You have to accomodate packet drops, at any level, and recover in some
reasonable way from this.

So even with byte based flow control, TIPC I think will still have
fundamental issues with data handling.

  reply	other threads:[~2014-05-14 17:37 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-14  9:39 [PATCH net-next v2 0/8] tipc: bug fixes and improvements Jon Maloy
2014-05-14  9:39 ` [PATCH net-next v2 1/8] tipc: decrease connection flow control window Jon Maloy
2014-05-14 11:50   ` Eric Dumazet
2014-05-14 12:12     ` Jon Maloy
2014-05-14  9:39 ` [PATCH net-next v2 2/8] tipc: compensate for double accounting in socket rcv buffer Jon Maloy
2014-05-14 11:47   ` Eric Dumazet
2014-05-14 12:53     ` Jon Maloy
2014-05-14 17:37       ` David Miller [this message]
2014-05-14 17:52         ` Jon Maloy
2014-05-14 17:45       ` Eric Dumazet
2014-05-14 19:00         ` Jon Maloy
2014-05-14 19:42           ` Eric Dumazet
2014-05-15 13:25             ` Jon Maloy
2014-05-14  9:39 ` [PATCH net-next v2 3/8] tipc: don't record link RESET or ACTIVATE messages as traffic Jon Maloy
2014-05-14  9:39 ` [PATCH net-next v2 4/8] tipc: mark head of reassembly buffer as non-linear Jon Maloy
2014-05-14  9:39 ` [PATCH net-next v2 5/8] tipc: rename and move message reassembly function Jon Maloy
2014-05-14  9:39 ` [PATCH net-next v2 6/8] tipc: improve and extend media address conversion functions Jon Maloy
2014-05-14  9:39 ` [PATCH net-next v2 7/8] tipc: clean up neigbor discovery message reception Jon Maloy
2014-05-14  9:39 ` [PATCH net-next v2 8/8] tipc: merge port message reception into socket reception function Jon Maloy
2014-05-14 19:20 ` [PATCH net-next v2 0/8] tipc: bug fixes and improvements 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=20140514.133716.106221573887805156.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=erik.hugne@ericsson.com \
    --cc=jon.maloy@ericsson.com \
    --cc=maloy@donjonn.com \
    --cc=netdev@vger.kernel.org \
    --cc=paul.gortmaker@windriver.com \
    --cc=tipc-discussion@lists.sourceforge.net \
    --cc=ying.xue@windriver.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).