Conversation
There was a problem hiding this comment.
are they upstreamed? can you format the patch properly, author, description, bla, bla
There was a problem hiding this comment.
These changes are not upstreamed. Please provide an example of how patch files should be formatted.
There was a problem hiding this comment.
The patch files have been reformatted as requested. A PR has been created to upstream libnl3 changes, but there have been no PRs merged in that project in 2021, so these patches remain necessary.
3f4c34d to
a0c399c
Compare
8d820c9 to
1de29ea
Compare
There was a problem hiding this comment.
why are we remove the validation?
There was a problem hiding this comment.
@lguohan nl_addr_valid() arguments are supposed to be a pointer to an ASCII string and an address family value (AF_MPLS, AF_INET, AF_INET6)... it then uses these to validate that the string format contains an address for the specified family.
The removed calls to nl_addr_valid() were instead passing in a pointer to a binary address and the length of the binary address... this is completely wrong. For most cases, the length of the binary address would not match any of the values of supported address families, so nl_addr_valid() would return true. But if the binary address was an MPLS label stack with 3 labels, then the length would match the value of AF_DECnet (12) and it attempts to parse the binary address as if it were an ASCII string... this fails and nl_addr_valid() returns false.
There was a problem hiding this comment.
can you put the above explaination into the this patch file?
There was a problem hiding this comment.
@lguohan explanation is added to patch file.
36f7338 to
ce5205f
Compare
There was a problem hiding this comment.
Instead of removing the validation, can we fix the arguments.
replace nl_addr_get_len(addr) with nl_addr_get_family(addr)
There was a problem hiding this comment.
@smahesh That still isn't valid. Look at the code for nl_addr_valid() in libnl3. It is looking for an ASCII string and validating the string format. addr does not container a string, The return from nl_addr_get_binary_addr() is not a string.
We would have to first convert addr to string. It's pointless. nl_addr_valid() is not used anywhere else in libnl3, so I do not know why someone decided to use it in these MPLS functions.
There was a problem hiding this comment.
nl_addr_valid() is using the route_nh_set which is not mpls specific. this is the IP functions. how can this function pass now?
There was a problem hiding this comment.
@lguohan RTA_NEWDST is specific to MPLS. NEWDST contains the MPLS labelstack associated with the NH.
There was a problem hiding this comment.
need description here, what does enable/disable mean here.
ab18f4d to
90d5aa8
Compare
There was a problem hiding this comment.
can you make it more readable, make it multi-line, limit by 80 char per line?
|
i am only review the libnl part, for the yang model part, it should be reviewed in the sonic yang subgroup meeting. @rlhui, |
e6cd1ae to
2fc8eb8
Compare
|
/azp run |
|
Commenter does not have sufficient privileges for PR 7195 in repo Azure/sonic-buildimage |
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
I was not aware this PR contains yang changes until last week. @qbdwlr could email the yang subgroup sonic-yang-subgroup@googlegroups.com and @anshuv-mfst to request for review asap. |
|
Looks good to me.. waiting for builds to pass. |
|
@lguohan @smaheshm Please review/approve this PR. The sonic-swss PR (sonic-net/sonic-swss#1686) will not build successfully until this PR is merged to master. |
|
For posterity can you add the link to libnl3 upstream patch in the description section. Thanks! |
What I did
SONiC buildimage support for MPLS:
Why I did it
SONiC libnl3 support for MPLS
How I verified it
Unit-tests in sonic-swss/tests/test_mpls.py and sonic-utilities/tests
System tests in sonic-mgmt
Details if related
Refer to HLD: sonic-net/SONiC#706
PR to upstream to libnl3 project: thom311/libnl#284