On Sun, Nov 12, 2017 at 12:56 PM, Harald Welte <lafo...@gnumonks.org> wrote: > Hi Tom, > > sorry for the delayed response. But I remain committed in pushing > the non-controversial part of your GTP patches forward. > > On Sat, Oct 28, 2017 at 06:47:59PM +0200, Harald Welte wrote: >> Thanks. As indicated, I'm planning some testing later this weekend on >> the non-IPv6 patches, and am happy to add my Acked-by and/or re-submit >> those to Dave after that. > > After some more delays and returning from netdev 2.2, I've finally put > together a testing setup and successfully (manually) tested with the > following patches: > > 01/13 vxlan: Move gro_cells_init to ndo_init > 02/13 iptunnel: Add common functions to get a tunnel route > 04/13 gtp: Call common functions to get tunnel routes and add dst_cache > 05/13 iptunnel: Generalize tunnel update pmtu > 06/13 gtp: Change to use gro_cells > 07/13 gtp: Use goto for exceptions in gtp_udp_encap_recv funcs > 08/13 gtp: udp recv clean up > 09/13 gtp: Call function to update path mtu > 10/13 gtp: Eliminate pktinfo and add port configuration > The IPv6 related code in patches 4-10 needs to be taken out. It can be restored once there is support for IPv6.
> I hereby acknowledge those patches. How should we proceed? Should I > > a) do nothing, you will add Acked-By and re-submit? > > b) send an individual Acked-By in a reply to each related patch here on > netdev and you will re-submit those patches? > > c) simply create a rebased set from those patches and > re-submit them to the list for net-next myself, with the Acked-by? > Feel free to do c). I can Ack and test once the patches are ready. Tom > d) be preposterous and provide a gtp git tree for DaveM to pull from? > > As discussed before, I will not merge/ack IPv6 will until we have an > implementation that is interoperable. I have a TODO list of other > bugfixes and improvements for Kernel GTP, but I'm hopeful that IPv6 can > still be addressed before the end of 2017. > > Regards, > Harald > -- > - Harald Welte <lafo...@gnumonks.org> http://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6)
