All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yury Norov <yury.norov@gmail.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
	Vadim Fedorenko <vadim.fedorenko@linux.dev>,
	netdev@vger.kernel.org,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	linux-kernel@vger.kernel.org, Eric Dumazet <edumazet@google.com>,
	Mark Brown <broonie@kernel.org>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	Jakub Kicinski <kuba@kernel.org>,
	Herve Codina <herve.codina@bootlin.com>,
	Paolo Abeni <pabeni@redhat.com>,
	linuxppc-dev@lists.ozlabs.org,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH v3 RESEND 3/6] bitmap: Make bitmap_onto() available to users
Date: Mon, 12 Feb 2024 11:13:13 -0800	[thread overview]
Message-ID: <Zcptyd/AWrDD3EAL@yury-ThinkPad> (raw)
In-Reply-To: <Zcos9F3ZCX5c936p@smile.fi.intel.com>

On Mon, Feb 12, 2024 at 04:36:36PM +0200, Andy Shevchenko wrote:
> On Mon, Feb 12, 2024 at 03:20:22PM +0100, Herve Codina wrote:
> > On Mon, 12 Feb 2024 16:01:38 +0200
> > Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> 
> ...
> 
> > Agree, the bitmap_onto() code is simpler to understand than its help.
> > 
> > I introduced bitmap_off() to be the "reverse" bitmap_onto() operations
> > and I preferred to avoid duplicating function that do the same things.
> > 
> > On my side, I initially didn't use the bitmap_*() functions and did the the
> > bits manipulation by hand.
> > During the review, it was suggested to use the bitmap_*() family and I followed
> > this suggestion.
> 
> I also would go this way, the problems I see with the current implementation are:

Sure, opencoding and duplicating the functionality is always a bad
idea.

> - being related to NUMA (and as Rasmus once pointed out better to be there);

It's 'related to NUMA' for the only reason - it's used by NUMA only.
Nothing NUMA-specific in the function itself.

Now that we've got a non-NUMA user, the bitmap_onto() is not related
to NUMA anymore.

> - unclear naming, esp. proposed bitmap_off();

That's I agree. Scatter/gather from your last approach sound better.
Do you plan to send a v2?

> - the quite hard to understand help text

Yes, we need a picture that would illustrate what actually happens

> - atomicity when it's not needed (AFAICT).

Agree. A series of atomic ops is not atomic. For example

        if (test_bit(n, map))
                set_bit(m, map);

is not atomic as a whole. And this is what we do in bitmap_onto/off()
in a loop. This must be fixed by using underscoded version.

> > I did tests to be sure that bitmap_onto() and bitmap_off() did
> > exactly the same things as my previous code did.
> 
> Yuri, what do you think about all this?

I think your scatter/gather is better then this onto/off by naming and
implementation. If you'll send a v2, and it would work for Herve, I'd
prefer scatter/gather. But we can live with onto/off as well.

Thanks,
Yury

WARNING: multiple messages have this Message-ID (diff)
From: Yury Norov <yury.norov@gmail.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Herve Codina <herve.codina@bootlin.com>,
	Vadim Fedorenko <vadim.fedorenko@linux.dev>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, Andrew Lunn <andrew@lunn.ch>,
	Mark Brown <broonie@kernel.org>,
	Christophe Leroy <christophe.leroy@csgroup.eu>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Subject: Re: [PATCH v3 RESEND 3/6] bitmap: Make bitmap_onto() available to users
Date: Mon, 12 Feb 2024 11:13:13 -0800	[thread overview]
Message-ID: <Zcptyd/AWrDD3EAL@yury-ThinkPad> (raw)
In-Reply-To: <Zcos9F3ZCX5c936p@smile.fi.intel.com>

On Mon, Feb 12, 2024 at 04:36:36PM +0200, Andy Shevchenko wrote:
> On Mon, Feb 12, 2024 at 03:20:22PM +0100, Herve Codina wrote:
> > On Mon, 12 Feb 2024 16:01:38 +0200
> > Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> 
> ...
> 
> > Agree, the bitmap_onto() code is simpler to understand than its help.
> > 
> > I introduced bitmap_off() to be the "reverse" bitmap_onto() operations
> > and I preferred to avoid duplicating function that do the same things.
> > 
> > On my side, I initially didn't use the bitmap_*() functions and did the the
> > bits manipulation by hand.
> > During the review, it was suggested to use the bitmap_*() family and I followed
> > this suggestion.
> 
> I also would go this way, the problems I see with the current implementation are:

Sure, opencoding and duplicating the functionality is always a bad
idea.

> - being related to NUMA (and as Rasmus once pointed out better to be there);

It's 'related to NUMA' for the only reason - it's used by NUMA only.
Nothing NUMA-specific in the function itself.

Now that we've got a non-NUMA user, the bitmap_onto() is not related
to NUMA anymore.

> - unclear naming, esp. proposed bitmap_off();

That's I agree. Scatter/gather from your last approach sound better.
Do you plan to send a v2?

> - the quite hard to understand help text

Yes, we need a picture that would illustrate what actually happens

> - atomicity when it's not needed (AFAICT).

Agree. A series of atomic ops is not atomic. For example

        if (test_bit(n, map))
                set_bit(m, map);

is not atomic as a whole. And this is what we do in bitmap_onto/off()
in a loop. This must be fixed by using underscoded version.

> > I did tests to be sure that bitmap_onto() and bitmap_off() did
> > exactly the same things as my previous code did.
> 
> Yuri, what do you think about all this?

I think your scatter/gather is better then this onto/off by naming and
implementation. If you'll send a v2, and it would work for Herve, I'd
prefer scatter/gather. But we can live with onto/off as well.

Thanks,
Yury

  reply	other threads:[~2024-02-12 19:14 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-12  7:56 [PATCH v3 RESEND 0/6] Add support for QMC HDLC Herve Codina
2024-02-12  7:56 ` Herve Codina
2024-02-12  7:56 ` [PATCH v3 RESEND 1/6] net: wan: " Herve Codina
2024-02-12  7:56   ` Herve Codina
2024-02-12 12:22   ` Andy Shevchenko
2024-02-12 12:22     ` Andy Shevchenko
2024-02-22 12:05     ` Herve Codina
2024-02-22 12:05       ` Herve Codina
2024-02-22 13:19       ` Andy Shevchenko
2024-02-22 13:19         ` Andy Shevchenko
2024-02-22 13:21         ` Herve Codina
2024-02-22 13:21           ` Herve Codina
2024-02-12  7:56 ` [PATCH v3 RESEND 2/6] MAINTAINERS: Add the Freescale QMC HDLC driver entry Herve Codina
2024-02-12  7:56   ` Herve Codina
2024-02-12  7:56 ` [PATCH v3 RESEND 3/6] bitmap: Make bitmap_onto() available to users Herve Codina
2024-02-12  7:56   ` Herve Codina
2024-02-12 12:27   ` Andy Shevchenko
2024-02-12 12:27     ` Andy Shevchenko
2024-02-12 13:37     ` Herve Codina
2024-02-12 13:37       ` Herve Codina
2024-02-12 14:01       ` Andy Shevchenko
2024-02-12 14:01         ` Andy Shevchenko
2024-02-12 14:20         ` Herve Codina
2024-02-12 14:20           ` Herve Codina
2024-02-12 14:36           ` Andy Shevchenko
2024-02-12 14:36             ` Andy Shevchenko
2024-02-12 19:13             ` Yury Norov [this message]
2024-02-12 19:13               ` Yury Norov
2024-02-15 17:46               ` Herve Codina
2024-02-15 17:46                 ` Herve Codina
2024-02-15 19:17                 ` Andy Shevchenko
2024-02-15 19:17                   ` Andy Shevchenko
2024-02-21 13:44                   ` Herve Codina
2024-02-21 13:44                     ` Herve Codina
2024-02-21 14:30                     ` Andy Shevchenko
2024-02-21 14:30                       ` Andy Shevchenko
2024-02-12  7:56 ` [PATCH v3 RESEND 4/6] bitmap: Introduce bitmap_off() Herve Codina
2024-02-12  7:56   ` Herve Codina
2024-02-12  9:45   ` Rasmus Villemoes
2024-02-12  9:45     ` Rasmus Villemoes
2024-02-12 18:37   ` Yury Norov
2024-02-12 18:37     ` Yury Norov
2024-02-12 18:41     ` Yury Norov
2024-02-12 18:41       ` Yury Norov
2024-02-12  7:56 ` [PATCH v3 RESEND 5/6] net: wan: fsl_qmc_hdlc: Add runtime timeslots changes support Herve Codina
2024-02-12  7:56   ` Herve Codina
2024-02-12  7:56 ` [PATCH v3 RESEND 6/6] net: wan: fsl_qmc_hdlc: Add framer support Herve Codina
2024-02-12  7:56   ` Herve Codina
2024-02-12  7:56 ` [RESEND PATCH v3 0/6] Add support for QMC HDLC Herve Codina
2024-02-12  7:56   ` Herve Codina
2024-02-12  7:56 ` [RESEND PATCH v3 1/6] net: wan: " Herve Codina
2024-02-12  7:56   ` Herve Codina
2024-02-12  7:56 ` [RESEND PATCH v3 2/6] MAINTAINERS: Add the Freescale QMC HDLC driver entry Herve Codina
2024-02-12  7:56   ` Herve Codina
2024-02-12  7:56 ` [RESEND PATCH v3 3/6] bitmap: Make bitmap_onto() available to users Herve Codina
2024-02-12  7:56   ` Herve Codina
2024-02-12  7:56 ` [RESEND PATCH v3 4/6] bitmap: Introduce bitmap_off() Herve Codina
2024-02-12  7:56   ` Herve Codina
2024-02-12  7:56 ` [RESEND PATCH v3 5/6] net: wan: fsl_qmc_hdlc: Add runtime timeslots changes support Herve Codina
2024-02-12  7:56   ` Herve Codina
2024-02-12  7:56 ` [RESEND PATCH v3 6/6] net: wan: fsl_qmc_hdlc: Add framer support Herve Codina
2024-02-12  7:56   ` Herve Codina
2024-02-12  8:05 ` [PATCH v3 RESEND 0/6] Add support for QMC HDLC Herve Codina
2024-02-12  8:05   ` Herve Codina

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=Zcptyd/AWrDD3EAL@yury-ThinkPad \
    --to=yury.norov@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=broonie@kernel.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=herve.codina@bootlin.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=vadim.fedorenko@linux.dev \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.