netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jes Sorensen <jes.sorensen@gmail.com>
To: Or Gerlitz <gerlitz.or@gmail.com>
Cc: Linux Netdev List <netdev@vger.kernel.org>,
	Kernel Team <kernel-team@fb.com>,
	Saeed Mahameed <saeedm@mellanox.com>,
	Ilan Tayari <ilant@mellanox.com>, Jes Sorensen <jsorensen@fb.com>
Subject: Re: [PATCH 7/7] mlx5: Do not build eswitch_offloads if CONFIG_MLX5_EN_ESWITCH_OFFLOADS is set
Date: Sat, 27 May 2017 22:23:58 -0400	[thread overview]
Message-ID: <e7c36f4e-788a-89dd-e92e-e6a31004758a@gmail.com> (raw)
In-Reply-To: <CAJ3xEMgeBaE9q6sucXtOQTBLAvZvf_d0eGvMsGbVa2vWc21R-Q@mail.gmail.com>

On 05/27/2017 05:02 PM, Or Gerlitz wrote:
> On Sat, May 27, 2017 at 12:16 AM, Jes Sorensen <jes.sorensen@gmail.com> wrote:
>> This gets rid of the temporary #ifdef spaghetti and allows the code to
>> compile without offload support enabled.
> 
> Hi Jes,
> 
> I am pretty sure we can do that exercise you're up to without any
> spaghetti cooking and even put more code under that CONFIG directive
> (en_rep.c), I'll take that with Saeed.

Hi Or,

I want to avoid adding #ifdef CONFIG_foo to the main code in order to 
keep it readable. I did it gradually to make sure I didn't break 
anything and to allow for it to be bisected in case something did break. 
If we can move out more code from places like en_rep.c into 
eswitch_offload.c and get it disabled that way that would be great, but 
I like to limit the number of #ifdefs we add to the actual code.

> Just wondering, you are motivated by a wish to put some mlx5
> functionalities under their own CONFIG directives which could be
> useful when backporting the latest upstream driver into older kernel
> and being able not to deal with parts of it, right? in that respect,
> are you using SRIOV but not the offloads mode?

The motivation is two-fold, the primary is to be able to disable 
features not being used for those who compile a custom kernel and who 
wish to reduce the codebase compiled. It also makes it more flexible 
when back porting the code to older kernels since it is easier to pick 
out a smaller subset. I was going to look into making TC support etc. 
optional next, but I wanted to have a discussion about this patchset first.

Cheers,
Jes

  reply	other threads:[~2017-05-28  2:24 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-26 21:16 [PATCH 0/7] mlx5: Make eswitch_offloads a compile option Jes Sorensen
2017-05-26 21:16 ` [PATCH 1/7] mlx5: Allow support for eswitch offloads to be disabled Jes Sorensen
2017-05-26 21:16 ` [PATCH 2/7] mlx5: eswitch vlan functionality is only called if SRIOV_OFFLOADS is set Jes Sorensen
2017-05-26 21:16 ` [PATCH 3/7] mlx5: Disable {add,del}_offloaded_rule() code if eswitch offloads are disabled Jes Sorensen
2017-05-26 21:16 ` [PATCH 4/7] mlx5: Stub out eswitch offload vport functions Jes Sorensen
2017-05-26 21:16 ` [PATCH 5/7] mlx5: Stub out create_vport_rx_rule when eswitch_offloads disabled Jes Sorensen
2017-05-26 21:16 ` [PATCH 6/7] mlx5: Stub out sqs2vport functions Jes Sorensen
2017-05-26 21:16 ` [PATCH 7/7] mlx5: Do not build eswitch_offloads if CONFIG_MLX5_EN_ESWITCH_OFFLOADS is set Jes Sorensen
2017-05-27 21:02   ` Or Gerlitz
2017-05-28  2:23     ` Jes Sorensen [this message]
2017-05-28  6:03       ` Or Gerlitz
2017-06-02 20:22         ` Jes Sorensen
2017-06-03 19:37           ` Or Gerlitz
2017-06-03 22:06             ` Saeed Mahameed
2017-06-04 17:07             ` Or Gerlitz
2017-06-05 20:51             ` Jes Sorensen
2017-06-05 21:53               ` Saeed Mahameed
2017-06-06 21:46                 ` Jes Sorensen
2017-06-07  4:06                   ` Saeed Mahameed
2017-06-07 15:19                     ` Jes Sorensen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e7c36f4e-788a-89dd-e92e-e6a31004758a@gmail.com \
    --to=jes.sorensen@gmail.com \
    --cc=gerlitz.or@gmail.com \
    --cc=ilant@mellanox.com \
    --cc=jsorensen@fb.com \
    --cc=kernel-team@fb.com \
    --cc=netdev@vger.kernel.org \
    --cc=saeedm@mellanox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).