On Thu, Dec 15, 2016 at 04:12:05PM +0200, Or Gerlitz wrote:
> On 12/15/2016 3:50 PM, Simon Horman wrote:
> >>Zero bits on the mask signify a "don't care" on the corresponding bits
> >>in key. Some HWs require those bits on the key to be zero. Since these
> >>bits are masked anyway, it's okay to provide the masked key to all
> >>drivers.
> >>
> >>Fixes: 5b33f48842fa ('net/flower: Introduce hardware offload support')
> >>
> >While I don't have a specific use case in mind that this change would break
> >it seems to me that it would be better to handle hardware requirements
> >at the driver level.
>
> Simon, again, since these bits are masked anyway, it would be correct to
> provide the masked key to the hw device.
>
> E.g no matter if the flow key/mask provided to the HW device is is
> 1.1.1.10/24 or 1.1.1.0/24, the user expects to the same matching, so
> nothing can't happen if we provide the latter to the driver.
> >While I don't have a specific use case in mind that this change would break
> >it seems to me that it would be better to handle hardware requirements
> >at the driver level.
>
> Even though, makes no sense to pass unmasked key down. Is is only
> confusing. This patch fixes it.
It seems somewhat arbitrary to me to allow such filters in software
but not pass then down to the driver layer. But I don't feel strongly
about this and I am happy for the patch to progress as-is.
