[ovs-dev] [PATCH v2 0/2] nsh: rework NSH netlink keys and actions

Yang, Yi yi.y.yang at intel.com
Fri Aug 18 22:07:43 UTC 2017


On Sat, Aug 19, 2017 at 01:36:57AM +0800, Ben Pfaff wrote:
> On Fri, Aug 18, 2017 at 07:38:56AM +0800, Yi Yang wrote:
> > v1->v2
> >   - Rework per kernel datapath review comments
> >   - Add new NSH key ttl
> >   - Add many helpers in nsh.h and replace much code
> >     with these helpers
> >   - nsh.h includes the lasted NSH spec
> >   - bits of flags and mdtype have a change
> > 
> > This patch seires reworks NSH netlink keys and actions
> > per kernel datapath requirments. OVS_KEY_ATTR_NSH is
> > changed as a nested key, encap_nsh and decap_nsh are
> > renamed as push_nsh and pop_nsh. PUSH_NSH used nested
> > OVS_KEY_ATTR_NSH keys to transfer NSH header data.
> > 
> > It also adds new NSH key 'ttl' to follow the lasted
> > IETF NSH draft:
> > 
> > https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/
> > 
> > I have double confirmed from one of its authors, this
> > is a final version which will be approved as IETF RFC,
> > the NSH header format won't be change anymore.
> 
> I think it's very wise to make 2.8 compliant with the latest NSH draft.
> It looks like that's patch 2.
> 
> It seems less valuable to me to rework the internals other than to gain
> this compliance, since as far as I can tell the kernel-side details are
> still under review and have not been applied to net-next.  I don't think
> it's worth closely tracking the proposals there.
> 
> Would you mind sending a patch that just makes the NSH implementation
> compliant with the latest Internet-Draft, without irrelevant changes?
> That is more suitable for a stable branch.

Ben, I'm not sure what part you mean is irreleant change. I remove
struct flow_nsh and use struct ovs_key_nsh because a new field ttl
result in struct flow_nsh isn't 64 bits aligned, I think it is better
to use struct ovs_key_nsh, path_hdr corresponds to two keys spi and si
this isn't my invention, mpls_lse is just such case, it even
corresponds n keys :-)

Most part is optimization because the same struct in struct flow and in
netlink, so we can use memcpy to replace multiple assignment statements.

In my perspective, this version is clearer. I do test them before I send
them, so don't worry stability issue, my real sfc test environment can
make sure this.

So please do let me know what parts I have to keep intact.

> 
> Thanks,
> 
> Ben.


More information about the dev mailing list