Re: SCTP changes needed

2014-12-05 Thread Michael Tuexen
On 01 Dec 2014, at 12:47, Hans Petter Selasky h...@selasky.org wrote:

 Hi Michael,
 
 As a followup to:
 https://svnweb.freebsd.org/changeset/base/275358
 
 Please find attached a separate SCTP patch as requested.
Committed in
https://svnweb.freebsd.org/changeset/base/275483

Thanks a lot for providing the patch!

Best regards
Michael
 
 The attached patch re-enables flowids in the SCTP code as before. Until this 
 patch is committed the SCTP code will not take full advantage of the 
 multiple-transmit capabilities as found in many network adapters.
 
 --HPS
 sctp_m_flowid_removal.diff___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


SCTP changes needed

2014-12-01 Thread Hans Petter Selasky

Hi Michael,

As a followup to:
https://svnweb.freebsd.org/changeset/base/275358

Please find attached a separate SCTP patch as requested.

The attached patch re-enables flowids in the SCTP code as before. Until 
this patch is committed the SCTP code will not take full advantage of 
the multiple-transmit capabilities as found in many network adapters.


--HPS
Index: sys/netinet/sctp_indata.c
===
--- sys/netinet/sctp_indata.c	(revision 275354)
+++ sys/netinet/sctp_indata.c	(working copy)
@@ -2296,7 +2296,7 @@
 struct sockaddr *src, struct sockaddr *dst,
 struct sctphdr *sh, struct sctp_inpcb *inp,
 struct sctp_tcb *stcb, struct sctp_nets *net, uint32_t * high_tsn,
-uint8_t use_mflowid, uint32_t mflowid,
+uint8_t mflowtype, uint32_t mflowid,
 uint32_t vrf_id, uint16_t port)
 {
 	struct sctp_data_chunk *ch, chunk_buf;
@@ -2391,7 +2391,7 @@
 stcb-sctp_ep-last_abort_code = SCTP_FROM_SCTP_INDATA + SCTP_LOC_19;
 sctp_abort_association(inp, stcb, m, iphlen,
 src, dst, sh, op_err,
-use_mflowid, mflowid,
+mflowtype, mflowid,
 vrf_id, port);
 return (2);
 			}
@@ -2406,7 +2406,7 @@
 stcb-sctp_ep-last_abort_code = SCTP_FROM_SCTP_INDATA + SCTP_LOC_19;
 sctp_abort_association(inp, stcb, m, iphlen,
 src, dst, sh, op_err,
-use_mflowid, mflowid,
+mflowtype, mflowid,
 vrf_id, port);
 return (2);
 			}
@@ -2475,7 +2475,7 @@
 	m, iphlen,
 	src, dst,
 	sh, op_err,
-	use_mflowid, mflowid,
+	mflowtype, mflowid,
 	vrf_id, port);
 	return (2);
 }
Index: sys/netinet/sctp_input.c
===
--- sys/netinet/sctp_input.c	(revision 275354)
+++ sys/netinet/sctp_input.c	(working copy)
@@ -86,7 +86,7 @@
 struct sockaddr *src, struct sockaddr *dst, struct sctphdr *sh,
 struct sctp_init_chunk *cp, struct sctp_inpcb *inp,
 struct sctp_tcb *stcb, int *abort_no_unlock,
-uint8_t use_mflowid, uint32_t mflowid,
+uint8_t mflowtype, uint32_t mflowid,
 uint32_t vrf_id, uint16_t port)
 {
 	struct sctp_init *init;
@@ -101,7 +101,7 @@
 	if (ntohs(cp-ch.chunk_length)  sizeof(struct sctp_init_chunk)) {
 		op_err = sctp_generate_cause(SCTP_CAUSE_INVALID_PARAM, );
 		sctp_abort_association(inp, stcb, m, iphlen, src, dst, sh, op_err,
-		use_mflowid, mflowid,
+		mflowtype, mflowid,
 		vrf_id, port);
 		if (stcb)
 			*abort_no_unlock = 1;
@@ -113,7 +113,7 @@
 		/* protocol error... send abort */
 		op_err = sctp_generate_cause(SCTP_CAUSE_INVALID_PARAM, );
 		sctp_abort_association(inp, stcb, m, iphlen, src, dst, sh, op_err,
-		use_mflowid, mflowid,
+		mflowtype, mflowid,
 		vrf_id, port);
 		if (stcb)
 			*abort_no_unlock = 1;
@@ -123,7 +123,7 @@
 		/* invalid parameter... send abort */
 		op_err = sctp_generate_cause(SCTP_CAUSE_INVALID_PARAM, );
 		sctp_abort_association(inp, stcb, m, iphlen, src, dst, sh, op_err,
-		use_mflowid, mflowid,
+		mflowtype, mflowid,
 		vrf_id, port);
 		if (stcb)
 			*abort_no_unlock = 1;
@@ -133,7 +133,7 @@
 		/* protocol error... send abort */
 		op_err = sctp_generate_cause(SCTP_CAUSE_INVALID_PARAM, );
 		sctp_abort_association(inp, stcb, m, iphlen, src, dst, sh, op_err,
-		use_mflowid, mflowid,
+		mflowtype, mflowid,
 		vrf_id, port);
 		if (stcb)
 			*abort_no_unlock = 1;
@@ -143,7 +143,7 @@
 		/* protocol error... send abort */
 		op_err = sctp_generate_cause(SCTP_CAUSE_INVALID_PARAM, );
 		sctp_abort_association(inp, stcb, m, iphlen, src, dst, sh, op_err,
-		use_mflowid, mflowid,
+		mflowtype, mflowid,
 		vrf_id, port);
 		if (stcb)
 			*abort_no_unlock = 1;
@@ -155,7 +155,7 @@
 		op_err = sctp_generate_cause(SCTP_BASE_SYSCTL(sctp_diag_info_code),
 		Problem with AUTH parameters);
 		sctp_abort_association(inp, stcb, m, iphlen, src, dst, sh, op_err,
-		use_mflowid, mflowid,
+		mflowtype, mflowid,
 		vrf_id, port);
 		if (stcb)
 			*abort_no_unlock = 1;
@@ -186,7 +186,7 @@
 			op_err = sctp_generate_cause(SCTP_BASE_SYSCTL(sctp_diag_info_code),
 			No listener);
 			sctp_send_abort(m, iphlen, src, dst, sh, 0, op_err,
-			use_mflowid, mflowid,
+			mflowtype, mflowid,
 			vrf_id, port);
 		}
 		goto outnow;
@@ -200,7 +200,7 @@
 		SCTPDBG(SCTP_DEBUG_INPUT3, sctp_handle_init: sending INIT-ACK\n);
 		sctp_send_initiate_ack(inp, stcb, m, iphlen, offset, src, dst,
 		sh, cp,
-		use_mflowid, mflowid,
+		mflowtype, mflowid,
 		vrf_id, port,
 		((stcb == NULL) ? SCTP_HOLDS_LOCK : SCTP_NOT_LOCKED));
 	}
@@ -434,7 +434,7 @@
 struct sockaddr *src, struct sockaddr *dst, struct sctphdr *sh,
 struct sctp_init_ack_chunk *cp, struct sctp_tcb *stcb,
 struct sctp_nets *net, int *abort_no_unlock,
-uint8_t use_mflowid, uint32_t mflowid,
+uint8_t mflowtype, uint32_t mflowid,
 uint32_t vrf_id)
 {
 	struct 

Re: SCTP changes needed

2014-12-01 Thread Michael Tuexen
On 01 Dec 2014, at 12:47, Hans Petter Selasky h...@selasky.org wrote:

 Hi Michael,
 
 As a followup to:
 https://svnweb.freebsd.org/changeset/base/275358
 
 Please find attached a separate SCTP patch as requested.
 
 The attached patch re-enables flowids in the SCTP code as before. Until this 
 patch is committed the SCTP code will not take full advantage of the 
 multiple-transmit capabilities as found in many network adapters.
OK. Thanks. I'll commit them ASAP. Still need to integrate some other changes 
upstream
to get them synced. I'll ping you once the stuff is committed.

Best regards
Michael
 
 --HPS
 sctp_m_flowid_removal.diff___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: SCTP changes needed

2014-12-01 Thread Adrian Chadd
Hi,

We also need to figure out what we can do with SCTP and flowid.

The way SCTP is using the mbuf field in said mbufs is going to collide
with hardware and RSS flowids. :(



-adrian


On 1 December 2014 at 04:20, Michael Tuexen tue...@freebsd.org wrote:
 On 01 Dec 2014, at 12:47, Hans Petter Selasky h...@selasky.org wrote:

 Hi Michael,

 As a followup to:
 https://svnweb.freebsd.org/changeset/base/275358

 Please find attached a separate SCTP patch as requested.

 The attached patch re-enables flowids in the SCTP code as before. Until this 
 patch is committed the SCTP code will not take full advantage of the 
 multiple-transmit capabilities as found in many network adapters.
 OK. Thanks. I'll commit them ASAP. Still need to integrate some other changes 
 upstream
 to get them synced. I'll ping you once the stuff is committed.

 Best regards
 Michael

 --HPS
 sctp_m_flowid_removal.diff___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org