mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jeremy Kerr <jk@codeconstruct.com.au>
To: Adam Young <admiyo@os.amperecomputing.com>,
	Tony Nguyen <anthony.l.nguyen@intel.com>,
	Przemek Kitszel <przemyslaw.kitszel@intel.com>,
	 Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Matt Johnston <matt@codeconstruct.com.au>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Sudeep Holla <sudeep.holla@arm.com>,
	Jonathan Cameron <Jonathan.Cameron@huawei.com>,
	 Huisong Li <lihuisong@huawei.com>
Subject: Re: [net-next v42] mctp pcc: Implement MCTP over PCC Transport
Date: Mon, 18 May 2026 21:06:17 -0700	[thread overview]
Message-ID: <bca423e86899791f96c626b10f816ac1bff8059e.camel@codeconstruct.com.au> (raw)
In-Reply-To: <20260518203900.30720-1-admiyo@os.amperecomputing.com>

Hi Adam,

> diff --git a/drivers/net/ethernet/intel/stYNFrCT b/drivers/net/ethernet/intel/stYNFrCT
> new file mode 100644
> index 0000000000000000000000000000000000000000..9b01d1e909f20fe037eea685116d344a2165db52
> GIT binary patch
> literal 564073

[1255 lines of b85 data]

I think something leaked into your commit?

> +static void mctp_pcc_client_rx_callback(struct mbox_client *cl, void *mssg)
> +{
> +       struct acpi_pcct_ext_pcc_shared_memory pcc_header;
> +       struct mctp_pcc_ndev *mctp_pcc_ndev;
> +       struct mctp_pcc_mailbox *inbox;
> +       struct mctp_skb_cb *cb;
> +       struct sk_buff *skb;
> +       u32 header_length;
> +       int size;
> +
> +       mctp_pcc_ndev = container_of(cl, struct mctp_pcc_ndev, inbox.client);
> +       inbox = &mctp_pcc_ndev->inbox;
> +       memcpy_fromio(&pcc_header, inbox->chan->shmem, sizeof(pcc_header));
> +
> +       // The message must at least have the PCC command indicating it is an MCTP
> +       // message followed by the MCTP header, or we have a malformed message.
> +       // This may be run on big endian system, but the data in the buffer is
> +       // explicitly little endian.
> +       header_length = le32_to_cpu(pcc_header.length);

Is this still OK with pcc_header.length being a u32 (and not a __le32?)

> +static netdev_tx_t mctp_pcc_tx(struct sk_buff *skb, struct net_device *ndev)
> +{
> +       struct acpi_pcct_ext_pcc_shared_memory *pcc_header;
> +       struct mctp_pcc_ndev *mpnd = netdev_priv(ndev);
> +       int len = skb->len;
> +
> +       if (skb_cow_head(skb, sizeof(*pcc_header)))
> +               goto error;
> +
> +       pcc_header = skb_push(skb, sizeof(*pcc_header));
> +       pcc_header->signature = PCC_SIGNATURE | mpnd->outbox.index;
> +       pcc_header->flags = PCC_CMD_COMPLETION_NOTIFY;
> +       memcpy(&pcc_header->command, MCTP_SIGNATURE, MCTP_SIGNATURE_LENGTH);
> +       pcc_header->length = len + MCTP_SIGNATURE_LENGTH;

You're doing the endian conversion on read, but not on write. What was
the decision on whether you need it or not?

> +
> +       if (skb->len > mpnd->outbox.chan->shmem_size)
> +               goto error;
> +
> +       if (mbox_send_message(mpnd->outbox.chan->mchan, skb) < 0) {
> +               netif_stop_queue(ndev);
> +               /*
> +                * There is a possibility that the mailbox was cleared on
> +                * another thread between the failed send attempt and
> +                * stopping the queue.  If that is the case, and we don't restart
> +                * the queue, it will remain permanently stopped.  To test,
> +                * try submitting the message again. If successful, restart the
> +                * queue.
> +                */
> +               if (mbox_send_message(mpnd->outbox.chan->mchan, skb) >= 0) {
> +                       netif_wake_queue(ndev);

The retry is a bit odd; you can simplify this race handling by doing the
stop_queue pessimistically, and the re-starting the queue on success:

    netif_stop_queue();
    if (mbox_send_message(...) >= 0) {
        netif_start_queue();
    }

I don't think you need a wake (vs start), since you're running in the
same softirq context as the stop.

Cheers,


Jeremy

  parent reply	other threads:[~2026-05-19  4:06 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-18 20:38 Adam Young
2026-05-19  3:51 ` Adam Young
2026-05-19  4:06 ` Jeremy Kerr [this message]
2026-05-20 21:45   ` Adam Young
2026-05-20 23:49   ` Adam Young
2026-05-21  2:22 ` Adam Young

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=bca423e86899791f96c626b10f816ac1bff8059e.camel@codeconstruct.com.au \
    --to=jk@codeconstruct.com.au \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=admiyo@os.amperecomputing.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=anthony.l.nguyen@intel.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=kuba@kernel.org \
    --cc=lihuisong@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matt@codeconstruct.com.au \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=przemyslaw.kitszel@intel.com \
    --cc=sudeep.holla@arm.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

all inboxes | Powered by JetHome®