Re: [RFC] Removal of M_FLOWID flag from m_flags [WAS: Add support for hardware transmit rate limiting queues]

[K. Macy]

On Wed, Nov 19, 2014 at 1:34 PM, Hans Petter Selasky  wrote:
> On 11/19/14 21:46, K. Macy wrote:
>>
>> Hi Hans,
>>
>> It mostly looks fine, but it's a large change and there are some
>> places in the patch where it isn't clear that the right thing is being
>> done by looking at the patch alone. Please give us some time to
>> review.
>>
>
> No problem. Do you think you need more than a week?

(Didn't CC the others last time)

I probably won't. But I speak only for myself. However, I don't think
it's fair to ask you to wait more than two. I've been on the other end
of that too many times myself.

-K
___
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: [RFC] Removal of M_FLOWID flag from m_flags [WAS: Add support for hardware transmit rate limiting queues]

[Hans Petter Selasky]

On 11/19/14 21:46, K. Macy wrote:

Hi Hans,

It mostly looks fine, but it's a large change and there are some
places in the patch where it isn't clear that the right thing is being
done by looking at the patch alone. Please give us some time to
review.



No problem. Do you think you need more than a week?

--HPS

___
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: General Protection Fault in prelist_remove()

[Ryan Stone]

On Tue, Nov 18, 2014 at 2:21 AM, Mark Johnston  wrote:
> https://people.freebsd.org/~markj/patches/nd6_dad_races.diff

I haven't had the chance to study the patch in detail, but I can
confirm that it at least fixes the crashes that I was seeing earlier.
___
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: [RFC] Removal of M_FLOWID flag from m_flags [WAS: Add support for hardware transmit rate limiting queues]

[K. Macy]

Hi Hans,

It mostly looks fine, but it's a large change and there are some
places in the patch where it isn't clear that the right thing is being
done by looking at the patch alone. Please give us some time to
review.


Thanks.

-K

On Wed, Nov 19, 2014 at 11:02 AM, Hans Petter Selasky  wrote:
> Hi,
>
> The M_FLOWID flag is marked as deprecated in the FreeBSD kernel code and the
> patch below completely removes it. I suggest we will now be using the
> "m_pkthdr.rsstype" also known as "M_HASHTYPE" to decide if the flowid value
> is valid or not. When the "rsstype" is set to "M_HASHTYPE_NONE" the
> "m_pkthdr.flowid" field is not valid. Else this field contains valid data
> for both TX and RX direction.
>
> Background:
> ===
>
> The network drivers today use the "rsstype" field only when receiving
> traffic. After my patch it is also used when sending traffic, and probably
> we should rename it.
>
> The reason for using the rsstype field for transmit, is to avoid introducing
> another field in the MBUF's packet header in order to steer outgoing traffic
> into special multiple purpose hardware FIFOs. This new feature should
> coexist with the existing flowid mechanism, and this is achieved by
> introducing a new hash type which I've named "M_HASHTYPE_HWRING" in my
> patch. This type can be selected by upper layers when generating traffic for
> lower layers, to indicate that the traffic is of a special kind and should
> have special treatment by the hardware, like rate-limiting. Hardware which
> doesn't support M_HASHTYPE_HWRING will send out the packets like usual.
>
>
> Patch is available from here:
> =
> http://home.selasky.org:8192/m_flowid_removal.diff
>
>
> Comments are appreciated!
>
>
> --HPS
> ___
> 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: [RFC] Removal of M_FLOWID flag from m_flags [WAS: Add support for hardware transmit rate limiting queues]

[Hans Petter Selasky]

On 11/19/14 20:32, Adrian Chadd wrote:

The RSS hash is also used for:

* TCP timers,
* UDP transmit, and
* the transmit path in RSS aware drivers (igb / ixgbe)



I know, and the RSS flowid values are still preserved as before in the 
receive path. It is just about how you tell the upper/lower layers that 
there is something in the "m_pkthdr.flowid" which they can use to 
accelerate traffic.


--HPS
___
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: [RFC] Removal of M_FLOWID flag from m_flags [WAS: Add support for hardware transmit rate limiting queues]

[Adrian Chadd]

The RSS hash is also used for:

* TCP timers,
* UDP transmit, and
* the transmit path in RSS aware drivers (igb / ixgbe)


-adrian


On 19 November 2014 11:25, Hans Petter Selasky  wrote:
> On 11/19/14 20:23, Adrian Chadd wrote:
>>
>> Hm, how are we going to have the RSS stuff work at the same time as
>> the hardware flow steering stuff you're prototyping?
>>
>
> Hi Adrain,
>
> RSS is only the receive side and its functionality is not touched. I'm just
> re-using the RSS fields for the transmit side, where the "rsstype" is
> currently not used.
>
> Do you see anything broken in my patch?
>
> --HPS
>
___
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: [RFC] Removal of M_FLOWID flag from m_flags [WAS: Add support for hardware transmit rate limiting queues]

[Michael Tuexen]

On 19 Nov 2014, at 20:02, Hans Petter Selasky  wrote:

> Hi,
> 
> The M_FLOWID flag is marked as deprecated in the FreeBSD kernel code and the 
> patch below completely removes it. I suggest we will now be using the 
> "m_pkthdr.rsstype" also known as "M_HASHTYPE" to decide if the flowid value 
> is valid or not. When the "rsstype" is set to "M_HASHTYPE_NONE" the 
> "m_pkthdr.flowid" field is not valid. Else this field contains valid data for 
> both TX and RX direction.
> 
> Background:
> ===
> 
> The network drivers today use the "rsstype" field only when receiving 
> traffic. After my patch it is also used when sending traffic, and probably we 
> should rename it.
> 
> The reason for using the rsstype field for transmit, is to avoid introducing 
> another field in the MBUF's packet header in order to steer outgoing traffic 
> into special multiple purpose hardware FIFOs. This new feature should coexist 
> with the existing flowid mechanism, and this is achieved by introducing a new 
> hash type which I've named "M_HASHTYPE_HWRING" in my patch. This type can be 
> selected by upper layers when generating traffic for lower layers, to 
> indicate that the traffic is of a special kind and should have special 
> treatment by the hardware, like rate-limiting. Hardware which doesn't support 
> M_HASHTYPE_HWRING will send out the packets like usual.
> 
> 
> Patch is available from here:
> =
> http://home.selasky.org:8192/m_flowid_removal.diff
> 
> 
> Comments are appreciated!
Before finally committing this, drop me a note. All the SCTP changes need to be 
ported upstream.
Depending on the time and if it is OK for you, I would try to integrate this 
upstream and push
it down to FreeBSD. Then you can commit the rest. This is simpler for me than 
reintegrating your
changes upstream...

Best regards
Michael
> 
> 
> --HPS
> ___
> 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: [RFC] Removal of M_FLOWID flag from m_flags [WAS: Add support for hardware transmit rate limiting queues]

[Hans Petter Selasky]

On 11/19/14 20:23, Adrian Chadd wrote:

Hm, how are we going to have the RSS stuff work at the same time as
the hardware flow steering stuff you're prototyping?



Hi Adrain,

RSS is only the receive side and its functionality is not touched. I'm 
just re-using the RSS fields for the transmit side, where the "rsstype" 
is currently not used.


Do you see anything broken in my patch?

--HPS

___
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: [RFC] Removal of M_FLOWID flag from m_flags [WAS: Add support for hardware transmit rate limiting queues]

[Adrian Chadd]

Hm, how are we going to have the RSS stuff work at the same time as
the hardware flow steering stuff you're prototyping?



-adrian


On 19 November 2014 11:02, Hans Petter Selasky  wrote:
> Hi,
>
> The M_FLOWID flag is marked as deprecated in the FreeBSD kernel code and the
> patch below completely removes it. I suggest we will now be using the
> "m_pkthdr.rsstype" also known as "M_HASHTYPE" to decide if the flowid value
> is valid or not. When the "rsstype" is set to "M_HASHTYPE_NONE" the
> "m_pkthdr.flowid" field is not valid. Else this field contains valid data
> for both TX and RX direction.
>
> Background:
> ===
>
> The network drivers today use the "rsstype" field only when receiving
> traffic. After my patch it is also used when sending traffic, and probably
> we should rename it.
>
> The reason for using the rsstype field for transmit, is to avoid introducing
> another field in the MBUF's packet header in order to steer outgoing traffic
> into special multiple purpose hardware FIFOs. This new feature should
> coexist with the existing flowid mechanism, and this is achieved by
> introducing a new hash type which I've named "M_HASHTYPE_HWRING" in my
> patch. This type can be selected by upper layers when generating traffic for
> lower layers, to indicate that the traffic is of a special kind and should
> have special treatment by the hardware, like rate-limiting. Hardware which
> doesn't support M_HASHTYPE_HWRING will send out the packets like usual.
>
>
> Patch is available from here:
> =
> http://home.selasky.org:8192/m_flowid_removal.diff
>
>
> Comments are appreciated!
>
>
> --HPS
___
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"

[RFC] Removal of M_FLOWID flag from m_flags [WAS: Add support for hardware transmit rate limiting queues]

[Hans Petter Selasky]

Hi,

The M_FLOWID flag is marked as deprecated in the FreeBSD kernel code and 
the patch below completely removes it. I suggest we will now be using 
the "m_pkthdr.rsstype" also known as "M_HASHTYPE" to decide if the 
flowid value is valid or not. When the "rsstype" is set to 
"M_HASHTYPE_NONE" the "m_pkthdr.flowid" field is not valid. Else this 
field contains valid data for both TX and RX direction.


Background:
===

The network drivers today use the "rsstype" field only when receiving 
traffic. After my patch it is also used when sending traffic, and 
probably we should rename it.


The reason for using the rsstype field for transmit, is to avoid 
introducing another field in the MBUF's packet header in order to steer 
outgoing traffic into special multiple purpose hardware FIFOs. This new 
feature should coexist with the existing flowid mechanism, and this is 
achieved by introducing a new hash type which I've named 
"M_HASHTYPE_HWRING" in my patch. This type can be selected by upper 
layers when generating traffic for lower layers, to indicate that the 
traffic is of a special kind and should have special treatment by the 
hardware, like rate-limiting. Hardware which doesn't support 
M_HASHTYPE_HWRING will send out the packets like usual.



Patch is available from here:
=
http://home.selasky.org:8192/m_flowid_removal.diff


Comments are appreciated!


--HPS
___
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"

Jenkins build is back to normal : FreeBSD_HEAD #1865

[jenkins-admin]

See 

___
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"