mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "lihuisong (C)" <lihuisong@huawei.com>
To: Adam Young <admiyo@amperemail.onmicrosoft.com>
Cc: <netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Jonathan Cameron <Jonathan.Cameron@huawei.com>,
	<admiyo@os.amperecomputing.com>,
	Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	Jeremy Kerr <jk@codeconstruct.com.au>,
	"Eric Dumazet" <edumazet@google.com>,
	Matt Johnston <matt@codeconstruct.com.au>,
	Paolo Abeni <pabeni@redhat.com>, Jakub Kicinski <kuba@kernel.org>
Subject: Re: [PATCH net-next v20 1/1] mctp pcc: Implement MCTP over PCC Transport
Date: Fri, 30 May 2025 14:19:37 +0800	[thread overview]
Message-ID: <807e5ea9-ed04-4203-b4a6-bf90952e7934@huawei.com> (raw)
In-Reply-To: <a9f67a55-3471-46b3-bd02-757b0796658a@amperemail.onmicrosoft.com>


在 2025/4/29 2:48, Adam Young 写道:
>
> On 4/24/25 09:03, lihuisong (C) wrote:
>>> +    rc = mctp_pcc_initialize_mailbox(dev, &mctp_pcc_ndev->inbox,
>>> +                     context.inbox_index);
>>> +    if (rc)
>>> +        goto free_netdev;
>>> +    mctp_pcc_ndev->inbox.client.rx_callback = 
>>> mctp_pcc_client_rx_callback;
>> It is good to move the assignemnt of  rx_callback pointer to 
>> initialize inbox mailbox.
>
>
> The other changes are fine, but this one I do not agree with.
>
> The rx callback only makes sense for one of the two mailboxes, and 
> thus is not appropriate for a generic function.
>
> Either  initialize_mailbox needs more complex logic, or would blindly 
> assign the callback to both mailboxes, neither of which simplifies or 
> streamlines the code.  That function emerged as a way to reduce 
> duplication.  Lets keep it that way.
>
It depends on you. But please reply my below comment. I didn't see any 
change about it in next version.

-->

> +static netdev_tx_t mctp_pcc_tx(struct sk_buff *skb, struct net_device 
> *ndev)
> +{
> +    struct mctp_pcc_ndev *mpnd = netdev_priv(ndev);
> +    struct mctp_pcc_hdr *mctp_pcc_header;
> +    void __iomem *buffer;
> +    unsigned long flags;
> +    int len = skb->len;
> +    int rc;
> +
> +    rc = skb_cow_head(skb, sizeof(struct mctp_pcc_hdr));
> +    if (rc)
> +        goto err_drop;
> +
> +    mctp_pcc_header = skb_push(skb, sizeof(struct mctp_pcc_hdr));
> +    mctp_pcc_header->signature = cpu_to_le32(PCC_MAGIC | 
> mpnd->outbox.index);
> +    mctp_pcc_header->flags = cpu_to_le32(PCC_HEADER_FLAGS);
> +    memcpy(mctp_pcc_header->mctp_signature, MCTP_SIGNATURE,
> +           MCTP_SIGNATURE_LENGTH);
> +    mctp_pcc_header->length = cpu_to_le32(len + MCTP_SIGNATURE_LENGTH);
> +
> +    spin_lock_irqsave(&mpnd->lock, flags);
> +    buffer = mpnd->outbox.chan->shmem;
> +    memcpy_toio(buffer, skb->data, skb->len);
> + mpnd->outbox.chan->mchan->mbox->ops->send_data(mpnd->outbox.chan->mchan,
> +                            NULL);
> +    spin_unlock_irqrestore(&mpnd->lock, flags);
> +
Why does it not need to know if the packet is sent successfully?
It's possible for the platform not to finish to send the packet after 
executing this unlock.
In this moment, the previous packet may be modified by the new packet to 
be sent.

  reply	other threads:[~2025-05-30  6:19 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-23 22:01 [PATCH net-next v20 0/1] MCTP Over " admiyo
2025-04-23 22:01 ` [PATCH net-next v20 1/1] mctp pcc: Implement MCTP over " admiyo
2025-04-24  9:57   ` Jonathan Cameron
2025-04-28 18:57     ` Adam Young
2025-04-29  4:08       ` Jeremy Kerr
2025-04-24 13:03   ` lihuisong (C)
2025-04-28 18:48     ` Adam Young
2025-05-30  6:19       ` lihuisong (C) [this message]
2025-06-02 20:51         ` Adam Young
2025-06-03 12:03           ` lihuisong (C)
2025-07-13 23:50             ` 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=807e5ea9-ed04-4203-b4a6-bf90952e7934@huawei.com \
    --to=lihuisong@huawei.com \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=admiyo@amperemail.onmicrosoft.com \
    --cc=admiyo@os.amperecomputing.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=jk@codeconstruct.com.au \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matt@codeconstruct.com.au \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.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®