[linux-yocto] Review request 0/5: GRE Refresh [ US43662 ]
Bruce Ashfield
bruce.ashfield at windriver.com
Tue Aug 26 07:21:53 PDT 2014
On 14-08-26 05:56 AM, jianchuan.wang at windriver.com wrote:
> Summary: GRE Refresh
> Tech Review: Yang Shi
> Gatekeeper: Bruce Ashfield
> Lockdown Approval (if needed):
> Branch Tag: master for WRL 7
>
> IP Statement (form link or license statement, usually automated):
> Crypto URL(s) (if needed): see http://wiki.wrs.com/PBUeng/LinuxProductDivisionExportProcess
> Parent Template (where applicable):
>
>
> -------------------------------------
> Impacted area Impact y/n
> ------------------- -----------
> docs/tech-pubs n
> tests n
> build system n
> host dependencies n
> RPM/packaging n
> toolchain n
> kernel code y
> user code n
> configuration files n
> target configuration n
> Other n
> Applicable to Yocto/upstream n
>
>
> Comments (indicate scope for each "y" above):
> ---------------------------------------------
>
> 0001-gre-add-x-netns-support.patch
>
> This patch allows to switch the netns when packet is encapsulated or
> decapsulated. In other word, the encapsulated packet is received in a netns,
> where the lookup is done to find the tunnel. Once the tunnel is found, the
> packet is decapsulated and injecting into the corresponding interface which
> stands to another netns.
>
> 0002-gre-allow-changing-mac-address-when-device-is-up.patch
>
> There is no need to require forcing device down on a Ethernet GRE (gretap)
> tunnel to change the MAC address.
>
> 0003-ip6gre-add-x-netns-support.patch
>
> This patch allows to switch the netns when packet is encapsulated or
> decapsulated. In other word, the encapsulated packet is received in a netns,
> where the lookup is done to find the tunnel. Once the tunnel is found, the
> packet is decapsulated and injecting into the corresponding interface which
> stands to another netns.
>
> 0004-net-Generalize-checksum_init-functions.patch
>
> Create a general __skb_checksum_validate function (actually a
> macro) to subsume the various checksum_init functions. This
> function can either init the checksum, or do the full validation
> (logically checksum_init+skb_check_complete)-- a flag specifies
> if full vaidation is performed. Also, there is a flag to the function
> to indicate that zero checksums are allowed (to support optional
> UDP checksums).
>
> 0005-gre6-Call-skb_checksum_simple_validate.patch
>
> Use skb_checksum_simple_validate to verify checksum.
>
> 0001-GRE-enable-gre-feature.patch
>
> GRE: enable gre feature
>
> Added Files:
> ------------
> None
>
> Removed Files:
> --------------
> None
>
> Remaining Changes (diffstat):
> -----------------------------
> include/linux/skbuff.h | 93 +++++++++++++++++++++++++++++++++++++++++++++++++++
> net/ipv4/ip_gre.c | 7 ++++---
> net/ipv6/ip6_gre.c | 64 ++++++++++++++++++-----------------
> 3 files changed, 130 insertions(+), 34 deletions(-)
>
> Testing Commands:
> -----------------
>
> Testing gre both ipv4 and ipv6.
>
> Node A: 128.224.165.109
> Node B: 128.224.165.126
>
> The node A and node B configures For IPV4 as flows:
> node A:
> ip tunnel add grem mode gre remote 128.224.165.126 local 128.224.165.109 ttl 255
> ip link set grem up
> ip addr add 10.10.10.1/24 dev grem
> node B:
> ip tunnel add grem mode gre remote 128.224.165.109 local 128.224.165.126 ttl 255
> ip link set grem up
> ip addr add 10.10.10.2/24 dev grem
>
> The node A and node B configures For IPV6 as flows:
>
> node A:
> ip tunnel add sixbone mode sit remote 128.224.165.126 local 128.224.165.109 ttl 255
> ip link set sixbone up
> ip addr add 3ffe:406:5:1:5:a:2:1/96 dev sixbone
> #ip route add 3ffe::/15 dev sixbone
> node B:
> ip tunnel add sixbone mode sit remote 128.224.165.109 local 128.224.165.126 ttl 255
> ip link set sixbone up
> ip addr add 3ffe:406:5:1:5:a:2:2/96 dev sixbone
> #ip route add 3ffe::/15 dev sixbone
gk
Bruce
>
> Testing, Expected Results:
> --------------------------
>
> After configuring sucessfully, ping each other is ok.
>
> Conditions of submission:
> -------------------------
>
> Arch built boot boardname
> -------------------------------------
> MIPS n n
> MIPS64 n n
> MIPS64n32 n n
> ARM n n
> x86 n n
> x86_64 y y intel-xeon-core
> PPC n n
> PPC64 n n
> SPARC64 n n
>
>
> Reviewer Checklist:
> -------------------
> [Submitters: make sure that your review doesn't trigger any checkmarks!]
>
>
> Your checkin has not passed review/gatekeep because (see checked entries):
>
> ___ Your RR template is generally incomplete; it has too many blank entries
> that need proper data filled in.
>
> ___ You've not properly listed things in the proper sections from
> the perspective of the SCM for new, removed, and changed files
>
> ___ You have failed to nominate a proper person for gatekeep or review.
>
> ___ Your patches do not have proper short+long header
>
> ___ You have grammar/spelling in your header that is unacceptable.
>
> ___ You have exceeded a sensible line length in your headers/comments/text.
>
> ___ Your patches have timestamps and/or index lines
>
> ___ You have failed to put in a proper CQID into your commits.
>
> ___ You have incorrectly put internal data like CQID commits into
> customer visible files (things shipped directly as patches etc).
>
> ___ Your "Signed-off-by:" is either missing or invalid
>
> ___ You have not built for enough appropriate architecture families,
> and/or you've chosen an arch family that is guaranteed to succeed.
>
> ___ You've included large amounts of useless and irrelevant diffstat
> information.
>
> ___ You've included binary files in your RR which appear as a large
> number of lines of useless "uuencode" information.
>
> ___ You have changed a host tool and not tested on enough supported hosts.
>
> ___ You have not given any evidence of testing beyond basic build tests.
> Demonstrate some level of runtime or other sanity testing.
>
> ___ You have ^M present in some of your files. These have to be removed.
>
> ___ You have carried forward some ancient/meaningless internal WRS CVS
> tags (i.e. $Id$) in some of your files. These have to be removed.
>
> ___ You have not clearly specified the origin of some/all of your added
> content (i.e. patches from a mailing list, a git tree, done internally?)
>
> ___ You have needlessly changed whitespace or added whitespace crimes
> like trailing spaces, or spaces before tabs.
>
> ___ You have mixed real technical changes with whitespace and other
> cosmetic code cleanup changes. These have to be separate commits.
>
> ___ You need to refactor your submission into logical chunks; there is
> too much content into a single commit.
>
> ___ You have extraneous garbage in your review (merge commits etc)
>
> ___ You have giant attachments which should never have been sent;
> Instead you should place your content in a tree to be pulled.
>
> ___ You have too many commits attached to an e-mail; resend as threaded
> commits, or place in a tree for a pull.
>
> ___ You have resent this content multiple times without a clear indication
> of what has changed between each re-send.
>
> ___ You have dropped patches that were used on the old pkg version
> without clearly justifying why they are no longer needed.
>
> ___ You have failed to adequately and individually address all of the
> comments and change requests that were proposed in the initial review.
>
> ___ You have added a new package, but not indicated that the package
> addition matches the Makefile template specified by the Userspace group
>
>
> -----------
> Original of this form hosted at:
> http://git.wrs.com/cgi-bin/cgit.cgi/bin/tree/etc/review.txt
>
More information about the linux-yocto
mailing list