On Tue, Sep 20, 2022 at 2:21 PM David Marchand <david.march...@redhat.com> wrote:
> On Mon, Sep 12, 2022 at 4:47 PM Flavio Leitner <f...@redhat.com> wrote: > > On Mon, Sep 12, 2022 at 5:52 AM David Marchand < > david.march...@redhat.com> wrote: > >> On Fri, Sep 9, 2022 at 7:58 PM Flavio Leitner <f...@redhat.com> wrote: > >> > > >> > Thanks for working on this patch! > >> > > >> > It seems possible to change this patch later when the other TSO series > >> > gets merged to disable TSO only on the affected port. > >> > Mike, any thoughts? > >> > >> It should be what this patch already does: disable TSO only for the > >> affected port as I mentionned in the commitlog below. > >> Can you clarify? > > > > > > Oops, I should have added more context. The issue is that TSO is > all-or-nothing > > because there is no software fallback currently [see > netdev_send_prepare_packet()]. > > So, if the problem happens and the reconnection with disabled TSO > succeeds, all > > TSO packets to that port will be dropped. The question is "should we > allow the update > > but run the risk of dropping packets or fail to update?" > > > > The software fallback is provided in the posted TSO series. In that > case, we can > > have a per-port TSO knob because if it gets disabled, the packets will > be segmented > > in software and not dropped. > > So, the patch makes sense with the posted TSO series applied, but I am > not so sure > > with the current code. > > > > What do you think? > > Ok, I get your point now. > > Btw, I still have some review to finish on the TSO series. > For the time being, I will mark my patch as "Changes requested", > rebase it and test on top of TSO series. > It sounds like a plan to me, thanks David. fbl _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
