mbox series

[RFC,00/16] GTP: flow based

Message ID 20210123195916.2765481-1-jonas@norrbonn.se (mailing list archive)
Headers show
Series GTP: flow based | expand

Message

Jonas Bonn Jan. 23, 2021, 7:59 p.m. UTC
This series begins by reverting the recently added patch adding support
for GTP with lightweight tunnels.  That patch was added without getting
any ACK from the maintainers and has several issues, as discussed on the
mailing list.

In order to try to make this as painless as possible, I have reworked
Pravin's patch into a series that is, hopefully, a bit more reviewable.
That series is rebased onto a series of other changes that constitute
cleanup work necessary for on-going work to IPv6 support into the
driver.  The IPv6 work should be rebaseable onto top of this series
later on.

I did try to do this other way around:  rebasing the IPv6 series on top
of Pravin's patch.  Given that Pravin's patch contained about 200 lines
of superfluous changes that would have had to be reverted in the process
of realigning the patch series, things got ugly pretty quickly.  The end
result would not have been pretty.

So the result of this is that Pravin's patch is now mostly still in
place.  I've reworked some small bits in order to simplify things.  My
expectation is that Pravin will review and test his bits here.  In
particular, the patch adding GTP control headers needs a bit of
explanation.

This is still an RFC only because I'm not quite convinced that I'm done
with this.  I do want to get this onto the list quickly, though, since
this has implications for the next merge window.  So let's see if we can
sort this out to everyone's satisfaction.

/Jonas

Jonas Bonn (13):
  Revert "GTP: add support for flow based tunneling API"
  gtp: set initial MTU
  gtp: include role in link info
  gtp: really check namespaces before xmit
  gtp: drop unnecessary call to skb_dst_drop
  gtp: set device type
  gtp: rework IPv4 functionality
  gtp: set dev features to enable GSO
  gtp: support GRO
  gtp: refactor check_ms back into version specific handlers
  gtp: drop duplicated assignment
  gtp: update rx_length_errors for abnormally short packets
  gtp: set skb protocol after pulling headers

Pravin B Shelar (3):
  gtp: add support for flow based tunneling
  gtp: add ability to send GTP controls headers
  gtp: add netlink support for setting up flow based tunnels

 drivers/net/gtp.c | 609 +++++++++++++++++++++++++++++-----------------
 1 file changed, 380 insertions(+), 229 deletions(-)

Comments

Pravin Shelar Jan. 24, 2021, 5:42 p.m. UTC | #1
On Sat, Jan 23, 2021 at 12:06 PM Jonas Bonn <jonas@norrbonn.se> wrote:
>
> This series begins by reverting the recently added patch adding support
> for GTP with lightweight tunnels.  That patch was added without getting
> any ACK from the maintainers and has several issues, as discussed on the
> mailing list.
>
> In order to try to make this as painless as possible, I have reworked
> Pravin's patch into a series that is, hopefully, a bit more reviewable.
> That series is rebased onto a series of other changes that constitute
> cleanup work necessary for on-going work to IPv6 support into the
> driver.  The IPv6 work should be rebaseable onto top of this series
> later on.
>
> I did try to do this other way around:  rebasing the IPv6 series on top
> of Pravin's patch.  Given that Pravin's patch contained about 200 lines
> of superfluous changes that would have had to be reverted in the process
> of realigning the patch series, things got ugly pretty quickly.  The end
> result would not have been pretty.
>
> So the result of this is that Pravin's patch is now mostly still in
> place.  I've reworked some small bits in order to simplify things.  My
> expectation is that Pravin will review and test his bits here.  In
> particular, the patch adding GTP control headers needs a bit of
> explanation.
>
> This is still an RFC only because I'm not quite convinced that I'm done
> with this.  I do want to get this onto the list quickly, though, since
> this has implications for the next merge window.  So let's see if we can
> sort this out to everyone's satisfaction.
>

I am all for making progress forward. Thanks Jonas for working on this.
I will finish the review next week.