From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
To: David Laight <David.Laight@ACULAB.COM>
Cc: 'Xin Long' <lucien.xin@gmail.com>,
network dev <netdev@vger.kernel.org>,
"linux-sctp@vger.kernel.org" <linux-sctp@vger.kernel.org>,
Neil Horman <nhorman@tuxdriver.com>,
Vlad Yasevich <vyasevich@gmail.com>,
"davem@davemloft.net" <davem@davemloft.net>
Subject: Re: [PATCHv3 net-next] sctp: prepare asoc stream for stream reconf
Date: Fri, 06 Jan 2017 15:56:38 +0000 [thread overview]
Message-ID: <20170106155638.GD3771@localhost.localdomain> (raw)
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6DB025926D@AcuExch.aculab.com>
On Fri, Jan 06, 2017 at 03:50:36PM +0000, David Laight wrote:
> From: Xin Long
> > Sent: 06 January 2017 14:19
> > sctp stream reconf, described in RFC 6525, needs a structure to
> > save per stream information in assoc, like stream state.
> >
> > In the future, sctp stream scheduler also needs it to save some
> > stream scheduler params and queues.
> >
> > This patchset is to prepare the stream array in assoc for stream
> > reconf. It defines sctp_stream that includes stream arrays inside
> > to replace ssnmap.
> >
> > Note that we use different structures for IN and OUT streams, as
> > the members in per OUT stream will get more and more different
> > from per IN stream.
> ...
> > /* What is the current SSN number for this stream? */
> > -static inline __u16 sctp_ssn_peek(struct sctp_stream *stream, __u16 id)
> > -{
> > - return stream->ssn[id];
> > -}
> > +#define sctp_ssn_peek(stream, type, sid) \
> > + ((stream)->type[sid].ssn)
> >
> > /* Return the next SSN number for this stream. */
> > -static inline __u16 sctp_ssn_next(struct sctp_stream *stream, __u16 id)
> > -{
> > - return stream->ssn[id]++;
> > -}
> > +#define sctp_ssn_next(stream, type, sid) \
> > + ((stream)->type[sid].ssn++)
> >
> > /* Skip over this ssn and all below. */
> > -static inline void sctp_ssn_skip(struct sctp_stream *stream, __u16 id,
> > - __u16 ssn)
> > -{
> > - stream->ssn[id] = ssn+1;
> > -}
> > -
> > +#define sctp_ssn_skip(stream, type, sid, ssn) \
> > + ((stream)->type[sid].ssn = ssn + 1)
> ...
>
> Is there any reason to convert these from inline functions to #defines?
> Inline functions give better type checking and are usually preferred.
Yes, it's to avoid specializing these and also avoid a condition in
them. Now inbound and outbound streams are handled by different structs.
Please see the new struct sctp_stream definition.
Marcelo
WARNING: multiple messages have this Message-ID (diff)
From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
To: David Laight <David.Laight@ACULAB.COM>
Cc: "'Xin Long'" <lucien.xin@gmail.com>,
network dev <netdev@vger.kernel.org>,
"linux-sctp@vger.kernel.org" <linux-sctp@vger.kernel.org>,
Neil Horman <nhorman@tuxdriver.com>,
Vlad Yasevich <vyasevich@gmail.com>,
"davem@davemloft.net" <davem@davemloft.net>
Subject: Re: [PATCHv3 net-next] sctp: prepare asoc stream for stream reconf
Date: Fri, 6 Jan 2017 13:56:38 -0200 [thread overview]
Message-ID: <20170106155638.GD3771@localhost.localdomain> (raw)
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6DB025926D@AcuExch.aculab.com>
On Fri, Jan 06, 2017 at 03:50:36PM +0000, David Laight wrote:
> From: Xin Long
> > Sent: 06 January 2017 14:19
> > sctp stream reconf, described in RFC 6525, needs a structure to
> > save per stream information in assoc, like stream state.
> >
> > In the future, sctp stream scheduler also needs it to save some
> > stream scheduler params and queues.
> >
> > This patchset is to prepare the stream array in assoc for stream
> > reconf. It defines sctp_stream that includes stream arrays inside
> > to replace ssnmap.
> >
> > Note that we use different structures for IN and OUT streams, as
> > the members in per OUT stream will get more and more different
> > from per IN stream.
> ...
> > /* What is the current SSN number for this stream? */
> > -static inline __u16 sctp_ssn_peek(struct sctp_stream *stream, __u16 id)
> > -{
> > - return stream->ssn[id];
> > -}
> > +#define sctp_ssn_peek(stream, type, sid) \
> > + ((stream)->type[sid].ssn)
> >
> > /* Return the next SSN number for this stream. */
> > -static inline __u16 sctp_ssn_next(struct sctp_stream *stream, __u16 id)
> > -{
> > - return stream->ssn[id]++;
> > -}
> > +#define sctp_ssn_next(stream, type, sid) \
> > + ((stream)->type[sid].ssn++)
> >
> > /* Skip over this ssn and all below. */
> > -static inline void sctp_ssn_skip(struct sctp_stream *stream, __u16 id,
> > - __u16 ssn)
> > -{
> > - stream->ssn[id] = ssn+1;
> > -}
> > -
> > +#define sctp_ssn_skip(stream, type, sid, ssn) \
> > + ((stream)->type[sid].ssn = ssn + 1)
> ...
>
> Is there any reason to convert these from inline functions to #defines?
> Inline functions give better type checking and are usually preferred.
Yes, it's to avoid specializing these and also avoid a condition in
them. Now inbound and outbound streams are handled by different structs.
Please see the new struct sctp_stream definition.
Marcelo
next prev parent reply other threads:[~2017-01-06 15:56 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-06 14:18 [PATCHv3 net-next] sctp: prepare asoc stream for stream reconf Xin Long
2017-01-06 14:18 ` Xin Long
2017-01-06 15:50 ` David Laight
2017-01-06 15:50 ` David Laight
2017-01-06 15:56 ` Marcelo Ricardo Leitner [this message]
2017-01-06 15:56 ` Marcelo Ricardo Leitner
2017-01-06 18:42 ` Marcelo Ricardo Leitner
2017-01-06 18:42 ` Marcelo Ricardo Leitner
2017-01-07 2:07 ` David Miller
2017-01-07 2:07 ` 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=20170106155638.GD3771@localhost.localdomain \
--to=marcelo.leitner@gmail.com \
--cc=David.Laight@ACULAB.COM \
--cc=davem@davemloft.net \
--cc=linux-sctp@vger.kernel.org \
--cc=lucien.xin@gmail.com \
--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.