On 18 Feb 2025, at 10:58, Roi Dayan wrote:
> On 17/02/2025 10:43, Eelco Chaudron wrote: >>>> Hi Roi, >>>> >>>> Sorry for the late response; I was quite busy with other tasks. However, I >>>> did find some time to dive into this piece of code. (I also found some >>>> other areas for improvement and will send patches later.) >>>> >>>> The cache is nothing more than a neighbor table, and having a port in the >>>> output does not provide any benefits. In fact, it adds more confusion, as >>>> the port is not related to the entry at all; i.e., it does not represent >>>> the egress port. The actual egress port is determined by the OpenFlow >>>> rules. >>>> >>>> This differs from, for example, the kernel neighbor table, which does show >>>> the actual egress port. Given this, I believe it’s best to keep the >>>> current output, as it clearly indicates that the packet will exit via the >>>> mentioned bridge using the existing OpenFlow rules. >>>> >>>> Cheers, >>>> >>>> Eelco >>> Hi, >>> >>> Ok we can drop this patch but we thought it could improve output as we >>> didn't >>> really see a scenario were ip is configured on port A while there will be an >>> openflow rule to force output to port B anyway. >> Not sure what configuration you are referring to, but for 99%, the port the >> system IP is assigned on will not be the output port. Mainly because the >> default NORMAL rule will not allow this. In addition, if you are able to >> force the output to a physical port with custom OpenFlow rules, this will >> only work on DPDK ports with a bifurcated driver. > > > Hi Eelco, > > Thanks for the explanation, I was looking it the wrong way. Don’t worry, it was a good exercise from my side to better understand the code ;) //Eelco _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
