On 7/28/22 08:16, Nobuhiro MIKI wrote: > On Thu, Apr 28, 2022 at 04:53:44PM +0900, Nobuhiro MIKI wrote: >> On Mon, Apr 25, 2022 at 05:59:59PM +0200, Ilya Maximets wrote: >>> Hi. Sorry for the late reply. >>> >>> The feature might be interesting indeed, but the port-based implementation >>> is preferred. Creating and maintaining new actions is much more difficult >>> and all other lightweight-tunnel-based stuff is implemented as tunnel ports, >>> not separate actions. So, it's better to re-use the common infrastructure. >> >> Hi Ilya, >> >> Thank you for your helpful advice. >> I'll plan and re-implement this feature using a port-based approach. Then >> I'll >> test whether it achieves our requirements, e.g. how flexible it is to control >> SIDs. It may take a few weeks, but let me discuss it again in this ML. > > Hi Ilya, > > I've reimplemented it with a port-based approach, please see the patch below: > > https://mail.openvswitch.org/pipermail/ovs-dev/2022-July/395536.html > > The design is similar to other tunnel ports like VXLAN and GRE. > Could you please review it when you have time?
Hi. Thanks! Sorry, we're in a "release" mode these days, so not much time spent on reviews for new features. I glanced over the patch and it adds support only for the userspace datapath, IIUC. I also looked at the kernel code and didn't find a way to create a kernel port for this type of a tunnel. Do you know if that is something that can be addressed from the kernel side? Best regards, Ilya Maximets. _______________________________________________ discuss mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
