On Fri, Jun 21, 2019 at 06:50 PM CEST, Joe Stringer wrote:
> On Fri, Jun 21, 2019 at 1:44 AM Jakub Sitnicki wrote:
>>
>> On Fri, Jun 21, 2019, 00:20 Joe Stringer wrote:
>>>
>>> On Wed, Jun 19, 2019 at 2:14 AM Jakub Sitnicki wrote:
>>> >
>>> > Hey Florian,
>>> >
>>> > Thanks for taking a look at
[Reposting with correct format this time. Sorry.]
On Fri, Jun 21, 2019 at 12:20 AM CEST, Joe Stringer wrote:
> On Wed, Jun 19, 2019 at 2:14 AM Jakub Sitnicki wrote:
>>
>> Hey Florian,
>>
>> Thanks for taking a look at it.
>>
>> On Tue, Jun 18, 2019 at 03:52 PM CEST, Florian Westphal wrote:
>> > J
Hi,
On Fri, 2019-06-21 at 18:41 +0200, Florian Westphal wrote:
> Eric Dumazet wrote:
> > > AFAICS so far this would be enough:
> > >
> > > 1. remove the BUG_ON() in skb_orphan, letting it clear skb->sk instead
> > > 2. in nf_queue_entry_get_refs(), if skb->sk and no destructor:
> > >call nf_
On Fri, Jun 21, 2019 at 1:44 AM Jakub Sitnicki wrote:
>
> On Fri, Jun 21, 2019, 00:20 Joe Stringer wrote:
>>
>> On Wed, Jun 19, 2019 at 2:14 AM Jakub Sitnicki wrote:
>> >
>> > Hey Florian,
>> >
>> > Thanks for taking a look at it.
>> >
>> > On Tue, Jun 18, 2019 at 03:52 PM CEST, Florian Westphal
Eric Dumazet wrote:
> > AFAICS so far this would be enough:
> >
> > 1. remove the BUG_ON() in skb_orphan, letting it clear skb->sk instead
> > 2. in nf_queue_entry_get_refs(), if skb->sk and no destructor:
> >call nf_tproxy_assign_sock() so a reference gets taken.
> > 3. change skb_steal_sock
On 6/21/19 5:51 AM, Florian Westphal wrote:
> Jakub Sitnicki wrote:
>>> So, at least for this part I don't see a technical reason why this
>>> has to grab a reference for listener socket.
>>
>> That's helpful, thanks! We rely on TPROXY, so I would like to help with
>> that. Let me see if I can
Jakub Sitnicki wrote:
> > So, at least for this part I don't see a technical reason why this
> > has to grab a reference for listener socket.
>
> That's helpful, thanks! We rely on TPROXY, so I would like to help with
> that. Let me see if I can get time to work on it.
AFAICS so far this would b
On Wed, Jun 19, 2019 at 2:14 AM Jakub Sitnicki wrote:
>
> Hey Florian,
>
> Thanks for taking a look at it.
>
> On Tue, Jun 18, 2019 at 03:52 PM CEST, Florian Westphal wrote:
> > Jakub Sitnicki wrote:
> >> - XDP programs using bpf_sk_lookup helpers, like load balancers, can't
> >>find the lis
Jakub Sitnicki wrote:
> > Sorry for the question, but where is the problem?
> > (i.e., is it with TPROXY or bpf side)?
>
> The way I see it is that the problem is that we have mappings for
> steering traffic into sockets split between two places: (1) the socket
> lookup tables, and (2) the TPROXY
Hey Florian,
Thanks for taking a look at it.
On Tue, Jun 18, 2019 at 03:52 PM CEST, Florian Westphal wrote:
> Jakub Sitnicki wrote:
>> - XDP programs using bpf_sk_lookup helpers, like load balancers, can't
>>find the listening socket to check for SYN cookies with TPROXY redirect.
>
> Sorry
Jakub Sitnicki wrote:
> - XDP programs using bpf_sk_lookup helpers, like load balancers, can't
>find the listening socket to check for SYN cookies with TPROXY redirect.
Sorry for the question, but where is the problem?
(i.e., is it with TPROXY or bpf side)?
> - TPROXY takes a reference to
We have been exploring an idea of making listening socket
lookup (inet_lookup) programmable with BPF.
Why? At last Netdev Marek talked [1] about two limitations of bind() API
we're hitting when running services on our edge servers:
1) sharing a port between two services
Services are accepting
12 matches
Mail list logo
