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

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 <hps_at_selasky.org> 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