Hmm. I noticed that this is going to the wrong mailing list *after* I replied once already.
This needs review, before broadcasting to the yocto list. Sorry for the noise! Cheers, Bruce On 14-08-26 05:56 AM, jianchuan.w...@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 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
-- _______________________________________________ linux-yocto mailing list linux-yo...@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
