All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Alexander Aring <aahringo@redhat.com>
Cc: Alexander Aring <alex.aring@gmail.com>,
	Stefan Schmidt <stefan@datenfreihafen.org>,
	linux-wpan@vger.kernel.org,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Eric Dumazet <edumazet@google.com>,
	netdev@vger.kernel.org, David Girault <david.girault@qorvo.com>,
	Romuald Despres <romuald.despres@qorvo.com>,
	Frederic Blain <frederic.blain@qorvo.com>,
	Nicolas Schodet <nico@ni.fr.eu.org>,
	Guilhem Imberton <guilhem.imberton@qorvo.com>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Subject: Re: [PATCH wpan-next v2 0/2] ieee802154: Beaconing support
Date: Tue, 31 Jan 2023 12:25:25 +0100	[thread overview]
Message-ID: <20230131122525.7bd35c2b@xps-13> (raw)
In-Reply-To: <CAK-6q+gqQgFxqBUAhHDMaWv9VfuKa=bCVee_oSLQeVtk_G8=ow@mail.gmail.com>

Hi Alexander,

> > > > > Changes in v2:
> > > > > * Clearly state in the commit log llsec is not supported yet.
> > > > > * Do not use mlme transmission helpers because we don't really need to
> > > > >   stop the queue when sending a beacon, as we don't expect any feedback
> > > > >   from the PHY nor from the peers. However, we don't want to go through
> > > > >   the whole net stack either, so we bypass it calling the subif helper
> > > > >   directly.
> > > > >  
> > >
> > > moment, we use the mlme helpers to stop tx  
> >
> > No, we no longer use the mlme helpers to stop tx when sending beacons
> > (but true MLME transmissions, we ack handling and return codes will be
> > used for other purposes).
> >  
> 
> then we run into an issue overwriting the framebuffer while the normal
> transmit path is active?

Crap, yes you're right. That's not gonna work.

The net core acquires HARD_TX_LOCK() to avoid these issues and we are
no bypassing the net core without taking care of the proper frame
transmissions either (which would have worked with mlme_tx_one()). So I
guess there are two options:

* Either we deal with the extra penalty of stopping the queue and
  waiting for the beacon to be transmitted with an mlme_tx_one() call,
  as proposed initially.

* Or we hardcode our own "net" transmit helper, something like:

mac802154_fast_mlme_tx() {
	struct net_device *dev = skb->dev;
	struct netdev_queue *txq;

	txq = netdev_core_pick_tx(dev, skb, NULL);
	cpu = smp_processor_id();
	HARD_TX_LOCK(dev, txq, cpu);
	if (!netif_xmit_frozen_or_drv_stopped(txq))
		netdev_start_xmit(skb, dev, txq, 0);
	HARD_TX_UNLOCK(dev, txq);
}

Note1: this is very close to generic_xdp_tx() which tries to achieve the
same goal: sending packets, bypassing qdisc et al. I don't know whether
it makes sense to define it under mac802154/tx.c or core/dev.c and give
it another name, like generic_tx() or whatever would be more
appropriate. Or even adapting generic_xdp_tx() to make it look more
generic and use that function instead (without the xdp struct pointer).

Note2: I am wondering if it makes sense to disable bh here as well?

Once we settle, I send a patch.

Thanks,
Miquèl

  reply	other threads:[~2023-01-31 11:25 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-25 10:29 [PATCH wpan-next v2 0/2] ieee802154: Beaconing support Miquel Raynal
2023-01-25 10:29 ` [PATCH wpan-next v2 1/2] ieee802154: Add support for user beaconing requests Miquel Raynal
2023-01-25 10:29 ` [PATCH wpan-next v2 2/2] mac802154: Handle basic beaconing Miquel Raynal
2023-01-27  1:45 ` [PATCH wpan-next v2 0/2] ieee802154: Beaconing support Alexander Aring
2023-01-27  1:48   ` Alexander Aring
2023-01-30  9:55     ` Miquel Raynal
2023-01-31  0:21       ` Alexander Aring
2023-01-31 11:25         ` Miquel Raynal [this message]
2023-02-01 17:15           ` Alexander Aring
2023-02-03 15:19             ` Miquel Raynal
2023-02-06  1:41               ` Alexander Aring
2023-01-28 13:15 ` Stefan Schmidt

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=20230131122525.7bd35c2b@xps-13 \
    --to=miquel.raynal@bootlin.com \
    --cc=aahringo@redhat.com \
    --cc=alex.aring@gmail.com \
    --cc=davem@davemloft.net \
    --cc=david.girault@qorvo.com \
    --cc=edumazet@google.com \
    --cc=frederic.blain@qorvo.com \
    --cc=guilhem.imberton@qorvo.com \
    --cc=kuba@kernel.org \
    --cc=linux-wpan@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=nico@ni.fr.eu.org \
    --cc=pabeni@redhat.com \
    --cc=romuald.despres@qorvo.com \
    --cc=stefan@datenfreihafen.org \
    --cc=thomas.petazzoni@bootlin.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 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.