Re: [PATCH net-next v2 0/5] bpf: BPF for lightweight tunnel encapsulation

On 3 November 2016 at 08:52, Hannes Frederic Sowa wrote: > On 02.11.2016 23:54, Thomas Graf wrote: >> Why would I want to accept the overhead if I simply avoid it? Just >> parsing the header and doing the hash lookup will add cost, cost for >> each packet. > > That is

Re: [PATCH net-next v2 0/5] bpf: BPF for lightweight tunnel encapsulation

On 02.11.2016 23:54, Thomas Graf wrote: > On 1 November 2016 at 16:12, Hannes Frederic Sowa > wrote: >> On 01.11.2016 21:59, Thomas Graf wrote: Dumping and verifying which routes get used might actually already be quite complex on its own. Thus my fear. >>>

Re: [PATCH net-next v2 0/5] bpf: BPF for lightweight tunnel encapsulation

On 2 November 2016 at 04:48, Hannes Frederic Sowa wrote: > On Wed, Nov 2, 2016, at 00:07, Tom Herbert wrote: >> On the other hand, I'm not really sure how to implement for this level >> of performance this in LWT+BPF either. It seems like one way to do >> that would be

Re: [PATCH net-next v2 0/5] bpf: BPF for lightweight tunnel encapsulation

On Wed, Nov 2, 2016 at 3:57 PM, Thomas Graf wrote: > On 1 November 2016 at 17:07, Tom Herbert wrote: >> On the other hand, I'm not really sure how to implement for this level >> of performance this in LWT+BPF either. It seems like one way to do >> that would

Re: [PATCH net-next v2 0/5] bpf: BPF for lightweight tunnel encapsulation

On 1 November 2016 at 17:07, Tom Herbert wrote: > On the other hand, I'm not really sure how to implement for this level > of performance this in LWT+BPF either. It seems like one way to do > that would be to create a program each destination and set it each > host. As you

Re: [PATCH net-next v2 0/5] bpf: BPF for lightweight tunnel encapsulation

On 1 November 2016 at 16:12, Hannes Frederic Sowa wrote: > On 01.11.2016 21:59, Thomas Graf wrote: >>> Dumping and verifying which routes get used might actually already be >>> quite complex on its own. Thus my fear. >> >> We even have an API to query which route is

Re: [PATCH net-next v2 0/5] bpf: BPF for lightweight tunnel encapsulation

On Wed, Nov 2, 2016 at 3:48 AM, Hannes Frederic Sowa wrote: > Hi Tom, > > On Wed, Nov 2, 2016, at 00:07, Tom Herbert wrote: >> On Tue, Nov 1, 2016 at 3:12 PM, Hannes Frederic Sowa >> wrote: >> > On 01.11.2016 21:59, Thomas Graf wrote: >> >>

Re: [PATCH net-next v2 0/5] bpf: BPF for lightweight tunnel encapsulation

Hi Tom, On Wed, Nov 2, 2016, at 00:07, Tom Herbert wrote: > On Tue, Nov 1, 2016 at 3:12 PM, Hannes Frederic Sowa > wrote: > > On 01.11.2016 21:59, Thomas Graf wrote: > >> On 1 November 2016 at 13:08, Hannes Frederic Sowa > >> wrote: > >>>

Re: [PATCH net-next v2 0/5] bpf: BPF for lightweight tunnel encapsulation

On Tue, Nov 1, 2016 at 3:12 PM, Hannes Frederic Sowa wrote: > On 01.11.2016 21:59, Thomas Graf wrote: >> On 1 November 2016 at 13:08, Hannes Frederic Sowa >> wrote: >>> On Tue, Nov 1, 2016, at 19:51, Thomas Graf wrote: If I understand

Re: [PATCH net-next v2 0/5] bpf: BPF for lightweight tunnel encapsulation

On 01.11.2016 21:59, Thomas Graf wrote: > On 1 November 2016 at 13:08, Hannes Frederic Sowa > wrote: >> On Tue, Nov 1, 2016, at 19:51, Thomas Graf wrote: >>> If I understand you correctly then a single BPF program would be >>> loaded which then applies to all

Re: [PATCH net-next v2 0/5] bpf: BPF for lightweight tunnel encapsulation

On 1 November 2016 at 13:33, Tom Herbert wrote: > You need to show that is integrity is maintained with these patches. > Part of this can be done, but part of this needs to be established in > testing. > > I've already given specifics for at least one potential source of >

Re: [PATCH net-next v2 0/5] bpf: BPF for lightweight tunnel encapsulation

On 1 November 2016 at 13:08, Hannes Frederic Sowa wrote: > On Tue, Nov 1, 2016, at 19:51, Thomas Graf wrote: >> If I understand you correctly then a single BPF program would be >> loaded which then applies to all dst_output() calls? This has a huge >> drawback, instead

Re: [PATCH net-next v2 0/5] bpf: BPF for lightweight tunnel encapsulation

On Tue, Nov 1, 2016 at 12:59 PM, Thomas Graf wrote: > On 1 November 2016 at 12:27, Tom Herbert wrote: >> On Tue, Nov 1, 2016 at 12:11 PM, Thomas Graf wrote: >>> You can do the same with act_pedit or cls_bpf at dev_queue_xmit() >>> before or

Re: [PATCH net-next v2 0/5] bpf: BPF for lightweight tunnel encapsulation

On Tue, Nov 1, 2016, at 19:51, Thomas Graf wrote: > On 1 November 2016 at 03:54, Hannes Frederic Sowa > wrote: > > I do fear the complexity and debugability introduced by this patch set > > quite a bit. > > What is the complexity concern? This is pretty straight

Re: [PATCH net-next v2 0/5] bpf: BPF for lightweight tunnel encapsulation

On 1 November 2016 at 12:27, Tom Herbert wrote: > On Tue, Nov 1, 2016 at 12:11 PM, Thomas Graf wrote: >> You can do the same with act_pedit or cls_bpf at dev_queue_xmit() >> before or after you go into the encapsulation device. This is a tool >> for root, if

Re: [PATCH net-next v2 0/5] bpf: BPF for lightweight tunnel encapsulation

On Tue, Nov 1, 2016 at 12:11 PM, Thomas Graf wrote: > On 1 November 2016 at 11:51, Tom Herbert wrote: >> On Tue, Nov 1, 2016 at 11:20 AM, Thomas Graf wrote: >>> The headers cannot be extended or reduced so the offsets always remain >>>

Re: [PATCH net-next v2 0/5] bpf: BPF for lightweight tunnel encapsulation

On 1 November 2016 at 11:51, Tom Herbert wrote: > On Tue, Nov 1, 2016 at 11:20 AM, Thomas Graf wrote: >> The headers cannot be extended or reduced so the offsets always remain >> correct. What can happen is that the header contains invalid data. >> > If we

Re: [PATCH net-next v2 0/5] bpf: BPF for lightweight tunnel encapsulation

On 1 November 2016 at 03:54, Hannes Frederic Sowa wrote: > I do fear the complexity and debugability introduced by this patch set > quite a bit. What is the complexity concern? This is pretty straight forward. I agree on debugability. This is being worked on

Re: [PATCH net-next v2 0/5] bpf: BPF for lightweight tunnel encapsulation

On Tue, Nov 1, 2016 at 11:20 AM, Thomas Graf wrote: > On 1 November 2016 at 09:17, Tom Herbert wrote: >> On Mon, Oct 31, 2016 at 5:37 PM, Thomas Graf wrote: >>> {Open question: >>> Tom brought up the question on whether it is safe to modify

Re: [PATCH net-next v2 0/5] bpf: BPF for lightweight tunnel encapsulation

On 1 November 2016 at 09:17, Tom Herbert wrote: > On Mon, Oct 31, 2016 at 5:37 PM, Thomas Graf wrote: >> {Open question: >> Tom brought up the question on whether it is safe to modify the packet >> in artbirary ways before dst_output(). This is the

Re: [PATCH net-next v2 0/5] bpf: BPF for lightweight tunnel encapsulation

On Mon, Oct 31, 2016 at 5:37 PM, Thomas Graf wrote: > {Open question: > Tom brought up the question on whether it is safe to modify the packet > in artbirary ways before dst_output(). This is the equivalent to a raw > socket injecting illegal headers. This v2 currently assumes

Re: [PATCH net-next v2 0/5] bpf: BPF for lightweight tunnel encapsulation

Hi Thomas, On 01.11.2016 01:37, Thomas Graf wrote: > {Open question: > Tom brought up the question on whether it is safe to modify the packet > in artbirary ways before dst_output(). This is the equivalent to a raw > socket injecting illegal headers. This v2 currently assumes that >

[PATCH net-next v2 0/5] bpf: BPF for lightweight tunnel encapsulation

{Open question: Tom brought up the question on whether it is safe to modify the packet in artbirary ways before dst_output(). This is the equivalent to a raw socket injecting illegal headers. This v2 currently assumes that dst_output() is ready to accept invalid header values. This needs to be