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: Tue, 3 Jun 2025 20:03:34 +0800 [thread overview]
Message-ID: <c2034f07-5422-4ab1-952e-f7d74d0675a7@huawei.com> (raw)
In-Reply-To: <9e3e0739-b859-4a62-954e-2b13f7d5dd85@amperemail.onmicrosoft.com>
在 2025/6/3 4:51, Adam Young 写道:
>
> On 5/30/25 02:19, lihuisong (C) wrote:
>>
>> 在 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.
>
> I think you missed version 21.
>
> Version 21 of this function ends with:
> memcpy_toio(buffer, skb->data, skb->len);
> rc = mpnd->outbox.chan->mchan->mbox->ops->send_data
> (mpnd->outbox.chan->mchan, NULL);
> spin_unlock_irqrestore(&mpnd->lock, flags);
> if ACPI_FAILURE(rc)
> goto err_drop;
> dev_dstats_tx_add(ndev, len);
> dev_consume_skb_any(skb);
> return NETDEV_TX_OK;
> err_drop:
> dev_dstats_tx_dropped(ndev);
> kfree_skb(skb);
> return NETDEV_TX_OK;
>
>
> Once the memcpy_toio completes, the driver will not look at the packet
> again. if the Kernel did change it at this point, it would not affect
> the flow. The send of the packet is checked vi rc returned from
> send_data, and it tags the packet as dropped. Is this not sufficient?
>
Yes, it is not enough.
Once send_data() return success, platform can receive an interrupt,but
the processing of the platform has not ended.
This processing includes handling data and then triggering an interrupt
to notify OS.
>
>
>
next prev parent reply other threads:[~2025-06-03 12:03 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 PCC Transport 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)
2025-06-02 20:51 ` Adam Young
2025-06-03 12:03 ` lihuisong (C) [this message]
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=c2034f07-5422-4ab1-952e-f7d74d0675a7@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;
as well as URLs for NNTP newsgroup(s).