All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Borkmann <dborkman@redhat.com>
To: linux-sctp@vger.kernel.org
Subject: Re: Socket buffer autotuning
Date: Tue, 13 Aug 2013 10:47:05 +0000	[thread overview]
Message-ID: <520A0EA9.7070706@redhat.com> (raw)
In-Reply-To: <CAGugRbWZMasbRMkt01VU7OOU2N0C_YaE7orkwALPrFa+yBCDPg@mail.gmail.com>

On 08/13/2013 12:23 PM, Michael Welzl wrote:
> On 13. aug. 2013, at 12:09, Daniel Borkmann wrote:
>> On 08/12/2013 02:33 PM, Michael Tuexen wrote:
>>> On Aug 12, 2013, at 2:23 PM, Karl Heiss <kheiss@gmail.com> wrote:
>>>
>>>> All,
>>>>
>>>> A recent post to the netdev mailing list made it clear that SCTP
>>>> doesn't support socket buffer autotuning.  All of a sudden, many of
>>>> our benchmarks start to make sense...  Has there been any
>>>> work/investigation to support this?  I suspect that there might be
>>>> some difficulty due to the multihoming nature of SCTP, but I haven't
>>>> taken the time to really investigate this avenue...  Any insight it
>>>> greatly appreciated.
>>> I think some work was already done:
>>> http://heim.ifi.uio.no/michawe/research/projects/new-transport/implementing-sctp-auto-buffer-tuning.html
>>> Not sure about the current status.
>>> I'm CCing Michael as he most likely knows.
>>
>> Thanks for sharing this link Michael!
>>
>> I'm currently on vacation, but when I'm back, I'll also take a look
>> at it and see what we can do with buffer autotuning on Linux. I already
>> started end of last week to do some experimenting.
>
> Cool! Getting Linux SCTP up to speed would be a wonderful thing!
>
> In case you're interested, Michael Tuexen and I once sat down to create a list of issues that we believe Linux SCTP could have, and it's on these slides:
> http://heim.ifi.uio.no/~michawe/research/publications/caia-feb11.pdf
> no. 28 - 30
>
> Note that this was a few years ago... still, one or two of the issues might still exist?!
>
> Besides, Morten Hustveit has also began with pluggable congestion control in the SCTP in which he also did the auto-buffer tuning work:
> http://heim.ifi.uio.no/~michawe/research/projects/new-transport/implementing-sctp-pluggable-congestion-control.html
>
> but from the look of the graphs at this page, it never really worked. Still, this is probably a cleanly done starting point.

Thanks for all the links.

I will most certainly have a look at those i.e. pluggable cong.control
and auto buffer tuning and also open issues from the slides when I'm
back from vacation!

Cheers,
Daniel

  parent reply	other threads:[~2013-08-13 10:47 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-12 12:23 Socket buffer autotuning Karl Heiss
2013-08-12 12:33 ` Michael Tuexen
2013-08-13 10:09 ` Daniel Borkmann
2013-08-13 10:47 ` Daniel Borkmann [this message]
2013-08-13 10:50 ` Michael Welzl
2013-08-13 10:53 ` Daniel Borkmann

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=520A0EA9.7070706@redhat.com \
    --to=dborkman@redhat.com \
    --cc=linux-sctp@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.