On Tue, Mar 9, 2021 at 8:30 PM Yan Vugenfirer <yvuge...@redhat.com> wrote: > > > > On 9 Mar 2021, at 12:13 PM, Peter Maydell <peter.mayd...@linaro.org> wrote: > > On Tue, 9 Mar 2021 at 09:01, Bin Meng <bmeng...@gmail.com> wrote: > > > Hi Jason, > > On Tue, Mar 9, 2021 at 5:00 PM Bin Meng <bmeng...@gmail.com> wrote: > > > Hi Jason, > > On Tue, Mar 9, 2021 at 4:57 PM Jason Wang <jasow...@redhat.com> wrote: > > > > On 2021/3/9 4:35 下午, Bin Meng wrote: > > Hi Jason, > > On Tue, Mar 9, 2021 at 4:23 PM Jason Wang <jasow...@redhat.com> wrote: > > > On 2021/3/8 6:22 下午, Peter Maydell wrote: > > I think the key thing we need to do here is make a decision > and be clear about what we're doing. There are three options > I can see: > > (1) we say that the net API demands that backends pad > packets they emit to the minimum ethernet frame length > unless they specifically are intending to emit a short frame, > and we fix any backends that don't comply (or equivalently, > add support in the core code for a backend to mark itself > as "I don't pad; please do it for me"). > > (2) we say that the networking subsystem doesn't support > short packets, and just have the common code always enforce > padding short frames to the minimum length somewhere between > when it receives a packet from a backend and passes it to > a NIC model. > > (3) we say that it's the job of the NIC models to pad > short frames as they see them coming in. > > > I'm not sure how much value we can gain from (1). So (2) looks better to me. > > Bin or Philippe, want to send a new version? > > I think this series does what (2) asks for. Or am I missing anything? > > > > It only did the padding for user/TAP. > > > > (hit send too soon ...) > > Ah, so we want this: > > if (sender->info->type != NET_CLIENT_DRIVER_NIC) > > correct? > > > No, option (2) is "always pad short packets regardless of > sender->info->type". Even if a NIC driver sends out a short > packet, we want to pad it, because we might be feeding it to > something that assumes it does not see short packets. > > > Some thought on this option - in such case with virtio-net, can we also get > an indication from the device that the packet will be padded? > Currently we are padding short packets in Windows driver (this is MS > certification requirement), and it will be nice not do to this in the guest > if device will announce such capability. >
This is more of a virtio-net specification question. virtio-net should expose a register bit to control this behavior, just like a real world NIC does. Regards, Bin
