On Mon, Sep 12, 2022 at 4:47 PM Flavio Leitner <[email protected]> wrote: > On Mon, Sep 12, 2022 at 5:52 AM David Marchand <[email protected]> > wrote: >> On Fri, Sep 9, 2022 at 7:58 PM Flavio Leitner <[email protected]> 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. -- David Marchand _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
