On Mon, Mar 22, 2021 at 01:48:07PM +0800, Bin Meng wrote:
> Hi David,
> 
> On Mon, Mar 22, 2021 at 1:24 PM David Gibson
> <da...@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
> > > <da...@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.

Ok, I see what you're saying, and indeed it already pads to 60 bytes,
rather than 64 on the Rx side.

-- 
David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!
http://www.ozlabs.org/~dgibson

Attachment: signature.asc
Description: PGP signature

Reply via email to