All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org, vyasevich@gmail.com,
	nhorman@tuxdriver.com, linux-sctp@vger.kernel.org,
	David.Laight@ACULAB.COM, alexander.duyck@gmail.com
Subject: Re: [PATCH 0/2] sctp: Add GSO support
Date: Tue, 03 May 2016 11:49:18 +0000	[thread overview]
Message-ID: <20160503114918.GD5676@localhost.localdomain> (raw)
In-Reply-To: <20160502.191614.608026435064266168.davem@davemloft.net>

On Mon, May 02, 2016 at 07:16:14PM -0400, David Miller wrote:
> From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> Date: Fri, 29 Apr 2016 18:33:31 -0300
> 
> > This patchset adds sctp GSO support.
> > 
> > Performance tests indicates that increases throughput by 10% if using
> > bigger chunk sizes, specially if bigger than MTU. For small chunks, it
> > doesn't help much if not using heavy firewall rules.
> > 
> > For small chunks it will probably be of more use once we get something
> > like MSG_MORE as David Laight had suggested.
> > 
> > I believe I could address all comments from the RFC attempt.
> 
> Are these packets idempotent?
> 
> Ie. if we GRO a bunch of SCTP frames on receive and that GRO frame is
> forwarded rather than received locally, is the same exact packet
> stream emitted on transmit?

Forward path is not going to happen because we can't do GRO for SCTP,
unfortunatelly. We would have to somehow maintain frame boundaries (as
I did for GSO here) (so that AUTH chunks have a delimited scope, for
example) and that's not feasible with the current way we do GRO. Well,
at least I couldn't see how.

So this is just for pure tx path, no forwarding involved.

  Marcelo


WARNING: multiple messages have this Message-ID (diff)
From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org, vyasevich@gmail.com,
	nhorman@tuxdriver.com, linux-sctp@vger.kernel.org,
	David.Laight@ACULAB.COM, alexander.duyck@gmail.com
Subject: Re: [PATCH 0/2] sctp: Add GSO support
Date: Tue, 3 May 2016 08:49:18 -0300	[thread overview]
Message-ID: <20160503114918.GD5676@localhost.localdomain> (raw)
In-Reply-To: <20160502.191614.608026435064266168.davem@davemloft.net>

On Mon, May 02, 2016 at 07:16:14PM -0400, David Miller wrote:
> From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> Date: Fri, 29 Apr 2016 18:33:31 -0300
> 
> > This patchset adds sctp GSO support.
> > 
> > Performance tests indicates that increases throughput by 10% if using
> > bigger chunk sizes, specially if bigger than MTU. For small chunks, it
> > doesn't help much if not using heavy firewall rules.
> > 
> > For small chunks it will probably be of more use once we get something
> > like MSG_MORE as David Laight had suggested.
> > 
> > I believe I could address all comments from the RFC attempt.
> 
> Are these packets idempotent?
> 
> Ie. if we GRO a bunch of SCTP frames on receive and that GRO frame is
> forwarded rather than received locally, is the same exact packet
> stream emitted on transmit?

Forward path is not going to happen because we can't do GRO for SCTP,
unfortunatelly. We would have to somehow maintain frame boundaries (as
I did for GSO here) (so that AUTH chunks have a delimited scope, for
example) and that's not feasible with the current way we do GRO. Well,
at least I couldn't see how.

So this is just for pure tx path, no forwarding involved.

  Marcelo

  reply	other threads:[~2016-05-03 11:49 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-29 21:33 [PATCH 0/2] sctp: Add GSO support Marcelo Ricardo Leitner
2016-04-29 21:33 ` Marcelo Ricardo Leitner
2016-04-29 21:33 ` [PATCH 1/2] skbuff: export skb_gro_receive Marcelo Ricardo Leitner
2016-04-29 21:33   ` Marcelo Ricardo Leitner
2016-04-29 21:33 ` [PATCH 2/2] sctp: Add GSO support Marcelo Ricardo Leitner
2016-04-29 21:33   ` Marcelo Ricardo Leitner
2016-04-29 21:38 ` [PATCH 0/2] " Marcelo Ricardo Leitner
2016-04-29 21:38   ` Marcelo Ricardo Leitner
2016-05-02 23:16 ` David Miller
2016-05-02 23:16   ` David Miller
2016-05-03 11:49   ` Marcelo Ricardo Leitner [this message]
2016-05-03 11:49     ` Marcelo Ricardo Leitner
2016-05-03 16:09     ` David Miller
2016-05-03 16:09       ` David Miller
2016-05-03 16:47       ` Marcelo Ricardo Leitner
2016-05-03 16:47         ` Marcelo Ricardo Leitner

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=20160503114918.GD5676@localhost.localdomain \
    --to=marcelo.leitner@gmail.com \
    --cc=David.Laight@ACULAB.COM \
    --cc=alexander.duyck@gmail.com \
    --cc=davem@davemloft.net \
    --cc=linux-sctp@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=nhorman@tuxdriver.com \
    --cc=vyasevich@gmail.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 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.