netdev - Re: [PATCH 7/7] mlx5: Do not build eswitch_offloads if CONFIG_MLX5_EN_ESWITCH

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 7 Jun 2017 11:19:43 -0400
From:   Jes Sorensen <jes.sorensen@...il.com>
To:     Saeed Mahameed <saeedm@....mellanox.co.il>,
        Jes Sorensen <jsorensen@...com>
Cc:     Or Gerlitz <gerlitz.or@...il.com>,
        Linux Netdev List <netdev@...r.kernel.org>,
        Kernel Team <kernel-team@...com>,
        Saeed Mahameed <saeedm@...lanox.com>,
        Ilan Tayari <ilant@...lanox.com>
Subject: Re: [PATCH 7/7] mlx5: Do not build eswitch_offloads if
 CONFIG_MLX5_EN_ESWITCH_OFFLOADS is set

On 06/07/2017 12:06 AM, Saeed Mahameed wrote:
> On Wed, Jun 7, 2017 at 12:46 AM, Jes Sorensen <jsorensen@...com> wrote:
>>> Hey Jes,
>>>
>>> It is not just about squashing patches, I am working on a series of
>>> patches to allow compiling out eswitch/eswitch_offloads/en_rep.c/en_tc
>>> altogether, it will come out cleaner as it will remove all ethernet
>>> sriov/eswitch VF representors and eswitch tc offloads stuff with one
>>> kconfig flag, and yet preserve standard QoS functionality from en_tc.
>>
>>
>> Saeed,
>>
>> I realize it is not just about squashing patches, however doing that to
>> someone else's patches is just broken. The Linux kernel way is to build on
>> top of patches, if they are valid, rather than throwing them all away and
>> doing it from scratch again bottom up. If there was something actually wrong
>> with my patches, and I would love to understand if that is the case, since I
>> don't know 1/100th of the hardware details that you know, then please share
>> those details.
> 
> Hey Jes,
> 
> Sorry for the inconvenience, I am working on a very similar patches,
> even before you posted yours.
> Your patches are fine, but as i said before, removing eswitch as is
> will introduce a small regression in Multi-PF configuration.
> 
> the issue is that lately we are having tons of discussions exactly
> about this and how to do the driver breakdown
> that makes everyone happy, so things are moving relatively slow, but
> my work on eswitch is converging.

Gotcha. I deliberately didn't disable eswitch itself in my patch, but 
only the offloading functionality, because of the old discussion 
mentioning that the eswitch needing to be initialized.

>> Sounds good.
>>
>>> I will post some patches for you to review by end of week.
>>
>>
>> Could we please start seeing this stuff happen in a public git tree so it is
>> possible to follow and contribute to the development? It is very frustrating
>> having to wait for things to appear and and not knowing whether a patch is
>> integrated or needs to be revised when you have things building on top of
>> it.
> 
> Sure, I will post some patches later today.
> I believe they will be fully ready by for submission by End of week.
> Again sorry about this.

Awesome!

Jes