sctp: rename asoc intl_enable to asoc peer.intl_capable
To keep consistent with other asoc features, we move intl_enable to peer.intl_capable in asoc. Signed-off-by: Xin Long <lucien.xin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
This commit is contained in:

committed by
David S. Miller

parent
1c13475368
commit
da1f6d4de7
@@ -1679,28 +1679,30 @@ struct sctp_association {
|
||||
__be16 addip_disabled_mask;
|
||||
|
||||
/* These are capabilities which our peer advertised. */
|
||||
__u8 ecn_capable:1, /* Can peer do ECN? */
|
||||
__u16 ecn_capable:1, /* Can peer do ECN? */
|
||||
ipv4_address:1, /* Peer understands IPv4 addresses? */
|
||||
ipv6_address:1, /* Peer understands IPv6 addresses? */
|
||||
hostname_address:1, /* Peer understands DNS addresses? */
|
||||
asconf_capable:1, /* Does peer support ADDIP? */
|
||||
prsctp_capable:1, /* Can peer do PR-SCTP? */
|
||||
reconf_capable:1, /* Can peer do RE-CONFIG? */
|
||||
auth_capable:1; /* Is peer doing SCTP-AUTH? */
|
||||
|
||||
/* sack_needed : This flag indicates if the next received
|
||||
* : packet is to be responded to with a
|
||||
* : SACK. This is initialized to 0. When a packet
|
||||
* : is received sack_cnt is incremented. If this value
|
||||
* : reaches 2 or more, a SACK is sent and the
|
||||
* : value is reset to 0. Note: This is used only
|
||||
* : when no DATA chunks are received out of
|
||||
* : order. When DATA chunks are out of order,
|
||||
* : SACK's are not delayed (see Section 6).
|
||||
*/
|
||||
__u8 sack_needed:1, /* Do we need to sack the peer? */
|
||||
intl_capable:1, /* Can peer do INTERLEAVE */
|
||||
auth_capable:1, /* Is peer doing SCTP-AUTH? */
|
||||
/* sack_needed:
|
||||
* This flag indicates if the next received
|
||||
* packet is to be responded to with a
|
||||
* SACK. This is initialized to 0. When a packet
|
||||
* is received sack_cnt is incremented. If this value
|
||||
* reaches 2 or more, a SACK is sent and the
|
||||
* value is reset to 0. Note: This is used only
|
||||
* when no DATA chunks are received out of
|
||||
* order. When DATA chunks are out of order,
|
||||
* SACK's are not delayed (see Section 6).
|
||||
*/
|
||||
sack_needed:1, /* Do we need to sack the peer? */
|
||||
sack_generation:1,
|
||||
zero_window_announced:1;
|
||||
|
||||
__u32 sack_cnt;
|
||||
|
||||
__u32 adaptation_ind; /* Adaptation Code point. */
|
||||
@@ -2049,8 +2051,7 @@ struct sctp_association {
|
||||
|
||||
__u8 need_ecne:1, /* Need to send an ECNE Chunk? */
|
||||
temp:1, /* Is it a temporary association? */
|
||||
force_delay:1,
|
||||
intl_enable:1;
|
||||
force_delay:1;
|
||||
|
||||
__u8 strreset_enable;
|
||||
__u8 strreset_outstanding; /* request param count on the fly */
|
||||
|
Reference in New Issue
Block a user