On Mon, May 22, 2023 at 7:55 AM Dumitru Ceara <dce...@redhat.com> wrote: > > On 5/17/23 18:46, Ihar Hrachyshka wrote: > > Thank you Dumitru! See below. > > > > On Tue, May 16, 2023 at 9:41 AM Dumitru Ceara <dce...@redhat.com> wrote: > >> I'm not necessarily rejecting this change. I just wanted to bring up an > >> alternative approach (I'm not sure if it's possible to implement it > >> though): > >> > >> The CMS (e.g., Neutron) probably knows before hand the reduced MTU value > >> it should impose on the localnet port. That means it might be possible > >> to just implement all this through logical flows that use > >> 'check_pkt_larger()'. > >> > > > > I think I mentioned this alternative in my cover letter for the > > series. (At least one of the variations.) > > > > I don't understand the specifics of what you are describing here > > though. Yes, CMS may do calculations for the "desired path MTU". But > > what's the mechanism for CMS to pass this information down to the OVN > > controller? ACL? I don't think the space of possible actions that > > would allow CMS itself to define the behavior is available to CMS. > > > > Perhaps you mean (as I think we discussed before in private) the > > approach where OVN northd creates Logical_Flow objects that would > > implement the behavior. If so, yes that could be possible. But note > > that northd doesn't know the desired path MTU (because it's not CMS > > and OVN northbound database API doesn't support MTU primitive for > > ports.) So the best we could do in the alternative way is implement > > half of the solution via Logical_Flow (the one that sends ICMP replies > > for "too-big" frames), leaving the other half (tagging the "too-big" > > frames based on interface MTU for processing by the Logical_Flows) to > > OVN controller. I think I listed this variation of the approach in my > > cover letter, but please let me know if it's not sufficient. > > > > (The split could be avoided if OVN adds a MTU attribute to its ports. > > But I of course am not trying to tackle this in this series, for > > obvious reasons. But MTU for ports is - in my mind - a worthy feature > > to have in OVN, if you ask me.) > > I was referring to this last part: adding MTU for ports and ovn-northd > translating those to logical flows that use check_pkt_larger() and set > REGBIT_PKT_LARGER. I was also hoping to see logical flows that generate > the ICMP error packets. But there's indeed no obvious way of doing that > because we need to act only on traffic that's destined to remote > hypervisors and that's not really an ovn-northd concept but more of an > ovn-controller one. > > If we go for your current approach and later add MTU for OVN ports, do > we need to be careful now in order to avoid complicated upgrades later? >
I'm trying to think what complications could arise. Isn't it just generating effectively the same flows, now via Logical_Flow path? The flows act on local frames generated by regular VIF ports, so it shouldn't affect the rest of cluster that e.g. some of them are generated by Logical_Flow path and some through the proposed solution. Or am I talking about something else? > Regards, > Dumitru > _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
