> 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 > <mailto: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. Best regards, Yan. > > thanks > -- PMM
