[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <67253734d93744a2b3b05d4a0bbe4a8f@AcuMS.aculab.com>
Date: Fri, 8 Dec 2017 15:01:31 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Marcelo Ricardo Leitner' <marcelo.leitner@...il.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
From: Marcelo Ricardo Leitner
> Sent: 08 December 2017 14:57
>
> 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.
...
It isn't only the double indirect, the indirect call itself isn't 'fun'.
I think there are other hot paths where you've replaced a sizeof()
with a ?: clause.
Caching the result might be much better.
David
Powered by blists - more mailing lists