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: > > On Mon, 8 Mar 2021 at 03:48, Jason Wang <jasow...@redhat.com> wrote: > >> Do we need to care about other type of networking backends? E.g socket. > >> > >> Or at least we should keep the padding logic if we can't audit all of > >> the backends. > > 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 think (3) is pretty clearly the worst of these, since it > > requires every NIC model to handle it; it has no advantages > > over (2) that I can see. I don't have a strong take on whether > > we'd rather have (1) or (2): it's a tradeoff between whether > > we support modelling of short frames vs simplicity of code. > > I'd just like us to be clear about what point or points in > > the code have the responsibility for padding short frames. > > > 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? Regards, Bin
