d, it doesn't have to be done again.
4. save/restore can be done with a mark so that separate marking can be
done for the two directions of the flow.
Reviewed-by: Matt Bennett
Reviewed-by: Kyeong Yoo
Signed-off-by: Luuk Paulussen
---
include/net/netfilter/nf_conntrack.h |
Sorry for the resend. I forgot to include relevant netfilter maintainers
in CC list
Changes from v1 are to add dependency on NF_CONNTRACK to Kconfig to resolve
the build issue and some style fixups from checkpatch.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body
t driver in the staging dir.
On 12/17/2015 09:59 AM, Luuk Paulussen wrote:
> The ethernet driver tx queue is stopped when the queue length exceeds
> what is allowed. It should only be started again when the queue length
> is back within bounds.
>
> The logic here was just reenabling
d, it doesn't have to be done again.
4. save/restore can be done with a mark so that separate marking can be
done for the two directions of the flow.
Reviewed-by: Matt Bennett
Reviewed-by: Kyeong Yoo
Signed-off-by: Luuk Paulussen
---
include/net/netfilter/nf_conntrack.h |
The ethernet driver tx queue is stopped when the queue length exceeds
what is allowed. It should only be started again when the queue length
is back within bounds.
The logic here was just reenabling the queue when any buffers had been
freed. the queue was stopped whenever the length exceeded 100
ed Telesis Labs NZ
+ * by Luuk Paulussen
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later ver
I recently posted this patch to the netfilter-devel and lartc mailing lists.
The
feedback I have had so far has mostly been questions around how we would use
this, and some
suggestions that don't solve the issues. I haven't had any negative feedback.
The key use case is to mark first packet i
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
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
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
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
11 matches
Mail list logo
