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 true, but in case you are out
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.
>>>
>>> We even have an API to que
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 to create a program each des
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 be to create a program each destinatio
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 point out would create a
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 used for a tuple. What
>> else
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:
>> >> On 1 November 2016 at 13:08, Hannes Frederic Sowa
>> >>
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:
> >>> On Tue, Nov 1, 2016, at 19:51, Thomas Graf 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:
>>> On Tue, Nov 1, 2016, at 19:51, Thomas Graf wrote:
If I understand you correctly then a single BPF program would be
loa
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 dst_output() calls? This has a huge
>>
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
> issues in routing issues
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 of multiple small BPF progra
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 after you go into the encapsulation device. This is a t
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 forward. I
> agree on debugability
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 you install a drop all ssh rule then y
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
>>> correct. What can happen is that the header contains invalid
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 can't add/remove headers then doesn't th
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 separately as Alexei
mentioned, to add
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 the packet
>>> in artbirary ways before dst_output().
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 equivalent to a raw
>> socket injecting illeg
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 that
> dst_outpu
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
> dst_output
{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
23 matches
Mail list logo
