Re: [net-next v41] mctp pcc: Implement MCTP over PCC Transport

[Adam Young <admiyo@amperemail.onmicrosoft.com>]

On 5/10/26 22:19, Jeremy Kerr wrote:
> Hi Adam,
>
> You keep sending out versions of this patch which have not accommodated
> items of previous feedback. It is not clear if this is intentional, but
> if you do disagree with some request for change, then respond to that
> request, rather than silently ignoring it.
>
> Alternatively, if it's not clear what the request is, then please
> respond to that thread and ask for clarification.
>
> Seeing changes without previous change requests either implemented or
> rejected through discussion is making the review process pretty
> frustrating, and is a primary reason why this has taken 40 versions so
> far.

Sorry, I should have been more explicit here.  I am not certain what is 
going to happen with fragmentation, so I want to be protected against 
future changes.

The check in validate_xmit_skb() is good, as it protects against the 
current set up. So my option was to put a comment in here and hope both 
changes happened together, or to just try and get this portion of the 
driver solid against the change.

And I thought that was what you were suggesting in the comment. The 
original comment sounded more like an "here is an optimization" instead 
of "this is important enough to kick back"

As for spacing, I get that there is a style, but it really should be 
encoded in checkstyle.sh or something and automated.  My own tendency is 
to put way too many spaces in to chunk things together, and I end up 
going over-draconian on stripping them out to try and meet the expected 
layout.

So, no, I am not intentionally skipping things.  I am really, really 
trying to catch all the nits and get this driver into an acceptable 
state.  I really appreciate the effort you have put in to review, as it 
would be dead in the water without your feedback.


>
>> Changes from Previous version
>>
>> Remove check for skb_is_nonlinear(skb) as it is done in skb_linearize(skb)
>> Removed comment about BE support
>> Spacing changes after gotos
> This change is good, but hasn't been applied to the part of the driver I
> had commented on.
>
>> +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);
>> +
>> +       if (header_length < sizeof(pcc_header.command) + sizeof(struct mctp_hdr))
>> +               goto error;
>> +
>> +       // If the reported size is larger than the shared memory minus headers,
>> +       // something is wrong and treat the buffer as corrupted data.
>> +       if (header_length > inbox->chan->shmem_size - PCC_EXTRA_LEN)
>> +               goto error;
>> +
>> +       if (memcmp(&pcc_header.command, MCTP_SIGNATURE, MCTP_SIGNATURE_LENGTH) != 0)
>> +               goto error;
>> +
>> +       size = header_length + PCC_EXTRA_LEN;
>> +       skb = netdev_alloc_skb(mctp_pcc_ndev->ndev, size);
>> +       if (!skb)
>> +               goto error;
> As I mentioned on v40, space after this.
Sorry, I have been reformatting a bunch.  Added it in and then removed it.
>
>> +       skb_put(skb, size);
>> +       skb->protocol = htons(ETH_P_MCTP);
>> +       memcpy_fromio(skb->data, inbox->chan->shmem, size);
>> +       dev_dstats_rx_add(mctp_pcc_ndev->ndev, size);
>> +       skb_pull(skb, sizeof(pcc_header));
>> +       skb_reset_mac_header(skb);
>> +       skb_reset_network_header(skb);
>> +       cb = __mctp_cb(skb);
>> +       cb->halen = 0;
>> +       netif_rx(skb);
>> +       return;
> And one after this.
>
>> +error:
>> +       dev_dstats_rx_dropped(mctp_pcc_ndev->ndev);
>> +}
>> +
>> +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;
>> +
>> +       /* Consolidated a fragmented packet into contiguous memory */
>> +       if (skb_linearize(skb))
>> +               goto error;
> You have removed the unnecessary is_linear check, but the entire
> linearize is unnecessary. From v39:
>
>    skb_linearize() already has the skb_is_nonlinear() check.
>    
>    However, you don't need to call skb_linearize() anyway, as that will
>    happen for you in validate_xmit_skb(), since the driver does not
>    advertise support for nonlinear skbs.
>
>> +
>> +       if (skb_cow_head(skb, sizeof(*pcc_header)))
>> +               goto error;
> ... and, if you're going for spacing updates, may as well do one here
> too
>
>> +       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;
>> +
>> +       if (mbox_send_message(mpnd->outbox.chan->mchan, skb) < 0) {
>> +               // Remove the header in case it gets sent again
>> +               skb_pull(skb, sizeof(*pcc_header));
>> +               netif_stop_queue(ndev);
>> +               return NETDEV_TX_BUSY;
>> +       }
>> +
>> +       return NETDEV_TX_OK;
> And here.
>
>> +error:
>> +       dev_dstats_tx_dropped(ndev);
>> +       kfree_skb(skb);
>> +       return NETDEV_TX_OK;
>> +}
>> +
>> +static void mctp_pcc_tx_prepare(struct mbox_client *cl, void *mssg)
>> +{
>> +       struct mctp_pcc_ndev *mctp_pcc_ndev;
>> +       struct mctp_pcc_mailbox *outbox;
>> +       struct sk_buff *skb = mssg;
>> +
>> +       mctp_pcc_ndev = container_of(cl, struct mctp_pcc_ndev, outbox.client);
>> +       outbox = &mctp_pcc_ndev->outbox;
>> +
>> +       /* The PCC Mailbox typically does not make use of the mssg pointer
>> +        * The mctp-over pcc driver is the only client that uses it.
>> +        * This value should always be non-null; it is possible
>> +        * that a change in the Mailbox level will break that assumption.
>> +        */
>> +       if (!skb) {
>> +               netdev_warn_once(mctp_pcc_ndev->ndev,
>> +                                "%s called with null message.\n", __func__);
>> +               return;
>> +       }
>> +
>> +       if (skb->len > outbox->chan->shmem_size) {
>> +               dev_dstats_tx_dropped(mctp_pcc_ndev->ndev);
>> +               return;
>> +       }
>> +       memcpy_toio(outbox->chan->shmem, skb->data, skb->len);
>> +
>> +       /*
>> +        * This packet could still be dropped in the PCC layer,
>> +        * But the only place that could deal with that is mctp_pcc_tx_done.
>> +        * That is called from the Hard-IRQ handler, and it is not safe to
>> +        * call stats functions from HARD-IRQ context.
>> +        */
> Your other option, if you prefer, is to do an irq-safe stats update.
> This is essentially open-coding dev_dstats_tx_add(), but using the
> irqsave/irqrestore variants of begin/end. Something like:
>
> 	struct pcpu_dstats *dstats = this_cpu_ptr(dev->dstats);
> 	unsigned long flags;
>
> 	flags = u64_stats_update_begin_irqsave(&dstats->syncp);
> 	u64_stats_inc(&dstats->tx_packets);
> 	u64_stats_add(&dstats->tx_bytes, skb->len);
> 	u64_stats_update_end_irqrestore(&dstats->syncp, flags);
>
> (but your current approach is okay too

Thanks for the approach.  I will possibly incorporate this in a future 
patch.  I have another approach in mind I want to try first.


>
> Cheers,
>
>
> Jeremy