[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171208145630.GE3328@localhost.localdomain>
Date: Fri, 8 Dec 2017 12:56:30 -0200
From: Marcelo Ricardo Leitner <marcelo.leitner@...il.com>
To: David Laight <David.Laight@...LAB.COM>
Cc: 'Xin Long' <lucien.xin@...il.com>,
network dev <netdev@...r.kernel.org>,
"linux-sctp@...r.kernel.org" <linux-sctp@...r.kernel.org>,
Neil Horman <nhorman@...driver.com>,
"davem@...emloft.net" <davem@...emloft.net>
Subject: Re: [PATCHv2 net-next 04/12] sctp: implement make_datafrag for
sctp_stream_interleave
On Fri, Dec 08, 2017 at 02:06:04PM +0000, David Laight wrote:
> From: Xin Long
> > Sent: 08 December 2017 13:04
> ...
> > @@ -264,8 +264,8 @@ struct sctp_datamsg *sctp_datamsg_from_user(struct sctp_association *asoc,
> > frag |= SCTP_DATA_SACK_IMM;
> > }
> >
> > - chunk = sctp_make_datafrag_empty(asoc, sinfo, len, frag,
> > - 0, GFP_KERNEL);
> > + chunk = asoc->stream.si->make_datafrag(asoc, sinfo, len, frag,
> > + GFP_KERNEL);
>
> I know that none of the sctp code is very optimised, but that indirect
> call is going to be horrid.
Yeah.. but there is no way to avoid the double derreference
considering we only have the asoc pointer in there and we have to
reach the contents of the data chunk operations struct, and the .si
part is the same as 'stream' part as it's a constant offset.
Due to the for() in there, we could add a variable to store
asoc->stream.si outside the for and then we can do only a single deref
inside it. Xin, can you please try and see if the generated code is
different?
Other suggestions?
Marcelo
Powered by blists - more mailing lists