qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] hw/net: fsl_etsec: Tx padding length should exclude CRC


From: Bin Meng
Subject: Re: [PATCH] hw/net: fsl_etsec: Tx padding length should exclude CRC
Date: Mon, 22 Mar 2021 13:48:07 +0800

Hi David,

On Mon, Mar 22, 2021 at 1:24 PM David Gibson
<david@gibson.dropbear.id.au> wrote:
>
> On Mon, Mar 22, 2021 at 12:33:06PM +0800, Bin Meng wrote:
> > Hi David,
> >
> > On Mon, Mar 22, 2021 at 12:11 PM David Gibson
> > <david@gibson.dropbear.id.au> wrote:
> > >
> > > On Tue, Mar 16, 2021 at 04:15:05PM +0800, Bin Meng wrote:
> > > > As the comment of tx_padding_and_crc() says: "Never add CRC in QEMU",
> > > > min_frame_len should excluce CRC, so it should be 60 instead of 64.
> > >
> > > Sorry, your reasoning still isn't clear to me.  If qemu is not adding
> > > the CRC, what is?
> >
> > No one is padding CRC in QEMU. QEMU network backends pass payload
> > without CRC in between.
>
> Ok, but the CRCs must be added if the packets are bridged onto a real
> device, yes?  Where does that happen?

I've never used it like that before. What's the command line to test that?

> >
> > > Will it always append a CRC after this padding is complete?
> >
> > No.
>
> If that's true, then won't the packets still be shorter than expected
> if we only pad to 60 bytes?

In QEMU packets are transmitted without CRC between network backends,
and when a NIC receives a packet, the minimum required payload length
is 60 bytes without a CRC.

Regards,
Bin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]