Re: [PATCH net-next 09/14] gtp: Allow configuring GTP interface as standalone

> I'm not sure where a "vendor" is involved with the GTP patches so far. I > think we have to draw a distinction between what you expect from > professional, corporate "vendors" with a commercial interest in mind > (such as supporting their hardware) and what you can expect from people > doing

Re: [PATCH net-next 09/14] gtp: Allow configuring GTP interface as standalone

Hi Tom, On Sun, Sep 24, 2017 at 08:55:49AM -0700, Tom Herbert wrote: > Do you believe that these patches are not at all on the right track, > that they can't be built upon to get to a standards-compliant > implementation, and that we are going to have to throw all of this and > start from scratch

Re: [PATCH net-next 09/14] gtp: Allow configuring GTP interface as standalone

> It's not about "not liking". I'm very happy about contributions, > including (of course) yours. It's about making sure that code we merge > into the kernel GTP driver will actually be usable to create a > standards-compliant GTP application or not. > Harald, Do you believe that these patches

Re: [PATCH net-next 09/14] gtp: Allow configuring GTP interface as standalone

Hi Tom, On Thu, Sep 21, 2017 at 09:43:02AM -0700, Tom Herbert wrote: > Please see the cover letter for the original GTP kernel patches dated > May 10, 2016. My first question on those was "Is there a timeline for > adding IPv6 support?". To which Pablo replied that there was a > preliminary patch

Re: [PATCH net-next 09/14] gtp: Allow configuring GTP interface as standalone

On Thu, Sep 21, 2017 at 8:12 AM, Harald Welte wrote: > Hi Tom, > > On Wed, Sep 20, 2017 at 05:55:01PM -0700, Tom Herbert wrote: >> You have the point of view of someone who has a lot of experience >> dealing with this protocol. Try to imagine if you were some random >>

Re: [PATCH net-next 09/14] gtp: Allow configuring GTP interface as standalone

Hi Tom, On Wed, Sep 20, 2017 at 05:55:01PM -0700, Tom Herbert wrote: > You have the point of view of someone who has a lot of experience > dealing with this protocol. Try to imagine if you were some random > kernel network programmer with no experience in the area. If they > happen to find a

Re: [PATCH net-next 09/14] gtp: Allow configuring GTP interface as standalone

On Wed, Sep 20, 2017 at 5:13 PM, Harald Welte wrote: > Hi Tom, > > On Wed, Sep 20, 2017 at 09:24:07AM -0700, Tom Herbert wrote: >> On Wed, Sep 20, 2017 at 9:07 AM, Andreas Schultz wrote: >> > GTP isn't special, I just don't like to have testing only

Re: [PATCH net-next 09/14] gtp: Allow configuring GTP interface as standalone

Hi Tom, On Wed, Sep 20, 2017 at 09:24:07AM -0700, Tom Herbert wrote: > On Wed, Sep 20, 2017 at 9:07 AM, Andreas Schultz wrote: > > GTP isn't special, I just don't like to have testing only features in there > > when the same goal can be reached without having to add extra

Re: [PATCH net-next 09/14] gtp: Allow configuring GTP interface as standalone

On Wed, Sep 20, 2017 at 9:07 AM, Andreas Schultz wrote: > > > On 20/09/17 17:57, Tom Herbert wrote: >> >> On Wed, Sep 20, 2017 at 8:27 AM, Andreas Schultz >> wrote: >>> >>> On 19/09/17 02:38, Tom Herbert wrote: Add new configuration of GTP

Re: [PATCH net-next 09/14] gtp: Allow configuring GTP interface as standalone

On 20/09/17 17:57, Tom Herbert wrote: On Wed, Sep 20, 2017 at 8:27 AM, Andreas Schultz wrote: On 19/09/17 02:38, Tom Herbert wrote: Add new configuration of GTP interfaces that allow specifying a port to listen on (as opposed to having to get sockets from a userspace

Re: [PATCH net-next 09/14] gtp: Allow configuring GTP interface as standalone

On Wed, Sep 20, 2017 at 8:27 AM, Andreas Schultz wrote: > On 19/09/17 02:38, Tom Herbert wrote: >> >> Add new configuration of GTP interfaces that allow specifying a port to >> listen on (as opposed to having to get sockets from a userspace control >> plane). This allows GTP

Re: [PATCH net-next 09/14] gtp: Allow configuring GTP interface as standalone

On 19/09/17 02:38, Tom Herbert wrote: Add new configuration of GTP interfaces that allow specifying a port to listen on (as opposed to having to get sockets from a userspace control plane). This allows GTP interfaces to be configured and the data path tested without requiring a GTP-C daemon.