From: David Ahern
Date: Tue, 1 Dec 2015 21:42:45 -0800
> On 12/1/15 6:58 PM, Andi Kleen wrote:
- skb_iff is either skb->dev->iff or 0. so it could be replaced with a
single bit flag for the 0 case.
>>>
>>> ... and that one wouldn't work on ingress.
>>
>> Please explain.
>
> skb->dev is
On 12/1/15 6:58 PM, Andi Kleen wrote:
- skb_iff is either skb->dev->iff or 0. so it could be replaced with a
single bit flag for the 0 case.
... and that one wouldn't work on ingress.
Please explain.
skb->dev is dropped fairly early in the Rx path. skb_iif is needed for
example for IP_CMSG
On Wed, Dec 2, 2015 at 4:13 AM, Andi Kleen wrote:
> This would be be great. I've recently ran into some issues with
> the overhead of the Android firewall setup.
Can you elaborate on which issues? If such a discussion would be
off-topic here, you can open a bug at
https://code.google.com/p/androi
> >This would be be great. I've recently ran into some issues with
> >the overhead of the Android firewall setup.
> >
> >So basically you need 4 extra bytes in sk_buff. How about:
> >
> >- shrinking skb->priority to 2 byte
>
> That wouldn't work, see SO_PRIORITY and such (4 bytes) ...
But does an
On 12/01/2015 08:13 PM, Andi Kleen wrote:
Lorenzo Colitti writes:
On Wed, Nov 25, 2015 at 5:32 AM, Matt Bennett
wrote:
I'm emailing this list for feedback on the feasibility of increasing
skb->mark or adding a new field for marking. Perhaps this extension
could be done under a new CONFIG opti
Lorenzo Colitti writes:
> On Wed, Nov 25, 2015 at 5:32 AM, Matt Bennett
> wrote:
>> I'm emailing this list for feedback on the feasibility of increasing
>> skb->mark or adding a new field for marking. Perhaps this extension
>> could be done under a new CONFIG option.
>
> 64-bit marks (both skb->
On 12/01/2015 04:55 PM, David Miller wrote:
> Lots of things are interesting and useful to many people.
>
> Even the most useful feature I would balk at it's implementation
> if it bloated up sk_buff. Period.
>
> You don't understand what the core issue is, which is sk_buff size
> which has an eff
From: Luuk Paulussen
Date: Tue, 1 Dec 2015 00:12:24 +
> On 11/30/2015 05:49 PM, David Miller wrote:
>> From: Luuk Paulussen
>> Date: Mon, 30 Nov 2015 04:10:43 +
>>
>>> On 11/30/2015 02:58 PM, David Miller wrote:
If you guys, really anyone, can find a way to remove some other 32-bit
On 11/30/2015 05:49 PM, David Miller wrote:
> From: Luuk Paulussen
> Date: Mon, 30 Nov 2015 04:10:43 +
>
>> On 11/30/2015 02:58 PM, David Miller wrote:
>>> If you guys, really anyone, can find a way to remove some other 32-bit
>>> item from sk_buff, you can expand skb->mark to 64-bits. But oth
From: Luuk Paulussen
Date: Mon, 30 Nov 2015 04:10:43 +
> On 11/30/2015 02:58 PM, David Miller wrote:
>> If you guys, really anyone, can find a way to remove some other 32-bit
>> item from sk_buff, you can expand skb->mark to 64-bits. But otherwise,
>> I'm going to be strongly against it. sk
On 11/30/2015 02:58 PM, David Miller wrote:
> If you guys, really anyone, can find a way to remove some other 32-bit
> item from sk_buff, you can expand skb->mark to 64-bits. But otherwise,
> I'm going to be strongly against it. sk_buff is already enormous and
> larger than it should be. So I'm
Lorenzo Colitti wrote:
> On Mon, Nov 30, 2015 at 11:08 AM, Florian Westphal wrote:
> > We have ctnetlink which allows direct setting of ctmark/ctlabels.
>
> Can those labels be set early enough in the stack to affect the source
> address chosen for outgoing connections?
No, same restrictions as
On Mon, Nov 30, 2015 at 11:08 AM, Florian Westphal wrote:
>
> > While connlabels provide 128bits of space skb->mark is still only 32
> > bits. Since we are using connection tracking to simply restore skb->mark
> > the use of connlabels by itself doesn't solve the problem I outlined
> > above. skb-
Matt Bennett wrote:
> On Tue, 2015-11-24 at 21:36 +0100, Florian Westphal wrote:
> > Matt Bennett wrote:
> > > I'm emailing this list for feedback on the feasibility of increasing
> > > skb->mark or adding a new field for marking. Perhaps this extension
> > > could be done under a new CONFIG opti
From: Lorenzo Colitti
Date: Sun, 29 Nov 2015 17:37:11 +0900
> On Wed, Nov 25, 2015 at 5:32 AM, Matt Bennett
> wrote:
>> I'm emailing this list for feedback on the feasibility of increasing
>> skb->mark or adding a new field for marking. Perhaps this extension
>> could be done under a new CONFIG
On Wed, Nov 25, 2015 at 5:32 AM, Matt Bennett
wrote:
> I'm emailing this list for feedback on the feasibility of increasing
> skb->mark or adding a new field for marking. Perhaps this extension
> could be done under a new CONFIG option.
64-bit marks (both skb->mark and sk->sk_mark) would be usefu
On 11/25/2015 09:56 AM, Matt Bennett wrote:
> On Tue, 2015-11-24 at 21:36 +0100, Florian Westphal wrote:
>> Matt Bennett wrote:
>>> I'm emailing this list for feedback on the feasibility of increasing
>>> skb->mark or adding a new field for marking. Perhaps this extension
>>> could be done under
On Tue, 2015-11-24 at 21:36 +0100, Florian Westphal wrote:
> Matt Bennett wrote:
> > I'm emailing this list for feedback on the feasibility of increasing
> > skb->mark or adding a new field for marking. Perhaps this extension
> > could be done under a new CONFIG option. Perhaps there are other way
Matt Bennett wrote:
> I'm emailing this list for feedback on the feasibility of increasing
> skb->mark or adding a new field for marking. Perhaps this extension
> could be done under a new CONFIG option. Perhaps there are other ways we
> could achieve the desired behaviour?
Well I pointed you tow
Hello,
Currently we have a number of router features (firewall, QoS, etc)
making use of ip tables and connection tracking. We do this by giving
each feature a certain area of skb->mark (say 8 bits each). This allows
us to simply restore skb->mark (using connection tracking) for packets
in a flow u
20 matches
Mail list logo
