* Re: [PATCH tip 0/9] tracing: attach eBPF programs to tracepoints/syscalls/kprobe
From: Namhyung Kim @ 2015-01-22 1:03 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Steven Rostedt, Ingo Molnar, Arnaldo Carvalho de Melo, Jiri Olsa,
David S. Miller, Daniel Borkmann, Hannes Frederic Sowa,
Brendan Gregg, Linux API, Network Development, LKML
In-Reply-To: <CAMEtUuxhjef+9QaFccfSyA3DbVJ3H6qP=eu-uZCkku1rVWViSQ@mail.gmail.com>
Hi Alexei,
On Fri, Jan 16, 2015 at 10:57:15AM -0800, Alexei Starovoitov wrote:
> On Fri, Jan 16, 2015 at 7:02 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
> > One last thing. If the ebpf is used for anything but filtering, it
> > should go into the trigger file. The filtering is only a way to say if
> > the event should be recorded or not. But the trigger could do something
> > else (a printk, a stacktrace, etc).
>
> it does way more than just filtering, but
> invoking program as a trigger is too slow.
> When program is called as soon as tracepoint fires,
> it can fetch other fields, evaluate them, printk some of them,
> optionally dump stack, aggregate into maps.
> We can let it call triggers too, so that user program will
> be able to enable/disable other events.
> I'm not against invoking programs as a trigger, but I don't
> see a use case for it. It's just too slow for production
> analytics that needs to act on huge number of events
> per second.
AFAIK a trigger can be fired before allocating a ring buffer if it
doesn't use the event record (i.e. has filter) or ->post_trigger bit
set (stacktrace). Please see ftrace_trigger_soft_disabled().
This also makes it keeping events in the soft-disabled state.
Thanks,
Namhyung
> We must minimize the overhead between tracepoint
> firing and program executing, so that programs can
> be used on events like packet receive which will be
> in millions per second. Every nsec counts.
> For example:
> - raw dd if=/dev/zero of=/dev/null
> does 760 MB/s (on my debug kernel)
> - echo 1 > events/syscalls/sys_enter_write/enable
> drops it to 400 MB/s
> - echo "echo "count == 123 " > events/syscalls/sys_enter_write/filter
> drops it even further down to 388 MB/s
> This slowdown is too high for this to be used on a live system.
> - tracex4 that computes histogram of sys_write sizes
> and stores log2(count) into a map does 580 MB/s
> This is still not great, but this slowdown is now usable
> and we can work further on minimizing the overhead.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH net-next v14 1/5] openvswitch: Refactor ovs_nla_fill_match().
From: Pravin Shelar @ 2015-01-22 1:16 UTC (permalink / raw)
To: Joe Stringer; +Cc: netdev, LKML, dev@openvswitch.org
In-Reply-To: <1421887372-56414-2-git-send-email-joestringer@nicira.com>
On Wed, Jan 21, 2015 at 4:42 PM, Joe Stringer <joestringer@nicira.com> wrote:
> Refactor the ovs_nla_fill_match() function into separate netlink
> serialization functions ovs_nla_put_{unmasked_key,mask}(). Modify
> ovs_nla_put_flow() to handle attribute nesting and expose the 'is_mask'
> parameter - all callers need to nest the flow, and callers have better
> knowledge about whether it is serializing a mask or not.
>
> Signed-off-by: Joe Stringer <joestringer@nicira.com>
Acked-by: Pravin B Shelar <pshelar@nicira.com>
^ permalink raw reply
* Re: [PATCH net-next v14 2/5] openvswitch: Refactor ovs_flow_tbl_insert().
From: Pravin Shelar @ 2015-01-22 1:16 UTC (permalink / raw)
To: Joe Stringer; +Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org, netdev, LKML
In-Reply-To: <1421887372-56414-3-git-send-email-joestringer-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
On Wed, Jan 21, 2015 at 4:42 PM, Joe Stringer <joestringer@nicira.com> wrote:
> Rework so that ovs_flow_tbl_insert() calls flow_{key,mask}_insert().
> This tidies up a future patch.
>
> Signed-off-by: Joe Stringer <joestringer@nicira.com>
Acked-by: Pravin B Shelar <pshelar@nicira.com>
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* Re: [PATCH net-next v14 3/5] openvswitch: Use sw_flow_key_range for key ranges.
From: Pravin Shelar @ 2015-01-22 1:16 UTC (permalink / raw)
To: Joe Stringer; +Cc: netdev, LKML, dev@openvswitch.org
In-Reply-To: <1421887372-56414-4-git-send-email-joestringer@nicira.com>
On Wed, Jan 21, 2015 at 4:42 PM, Joe Stringer <joestringer@nicira.com> wrote:
> These minor tidyups make a future patch a little tidier.
>
> Signed-off-by: Joe Stringer <joestringer@nicira.com>
Acked-by: Pravin B Shelar <pshelar@nicira.com>
^ permalink raw reply
* Re: [PATCH net-next v14 4/5] genetlink: Add genlmsg_parse() helper function.
From: Pravin Shelar @ 2015-01-22 1:16 UTC (permalink / raw)
To: Joe Stringer; +Cc: netdev, LKML, dev@openvswitch.org
In-Reply-To: <1421887372-56414-5-git-send-email-joestringer@nicira.com>
On Wed, Jan 21, 2015 at 4:42 PM, Joe Stringer <joestringer@nicira.com> wrote:
> The first user will be the next patch.
>
> Signed-off-by: Joe Stringer <joestringer@nicira.com>
Acked-by: Pravin B Shelar <pshelar@nicira.com>
^ permalink raw reply
* Re: [PATCH net-next v14 5/5] openvswitch: Add support for unique flow IDs.
From: Pravin Shelar @ 2015-01-22 1:16 UTC (permalink / raw)
To: Joe Stringer; +Cc: netdev, LKML, dev@openvswitch.org
In-Reply-To: <1421887372-56414-6-git-send-email-joestringer@nicira.com>
On Wed, Jan 21, 2015 at 4:42 PM, Joe Stringer <joestringer@nicira.com> wrote:
> Previously, flows were manipulated by userspace specifying a full,
> unmasked flow key. This adds significant burden onto flow
> serialization/deserialization, particularly when dumping flows.
>
> This patch adds an alternative way to refer to flows using a
> variable-length "unique flow identifier" (UFID). At flow setup time,
> userspace may specify a UFID for a flow, which is stored with the flow
> and inserted into a separate table for lookup, in addition to the
> standard flow table. Flows created using a UFID must be fetched or
> deleted using the UFID.
>
> All flow dump operations may now be made more terse with OVS_UFID_F_*
> flags. For example, the OVS_UFID_F_OMIT_KEY flag allows responses to
> omit the flow key from a datapath operation if the flow has a
> corresponding UFID. This significantly reduces the time spent assembling
> and transacting netlink messages. With all OVS_UFID_F_OMIT_* flags
> enabled, the datapath only returns the UFID and statistics for each flow
> during flow dump, increasing ovs-vswitchd revalidator performance by 40%
> or more.
>
> Signed-off-by: Joe Stringer <joestringer@nicira.com>
Looks good.
Acked-by: Pravin B Shelar <pshelar@nicira.com>
Thanks.
^ permalink raw reply
* Re: [PATCH tip 0/9] tracing: attach eBPF programs to tracepoints/syscalls/kprobe
From: Alexei Starovoitov @ 2015-01-22 1:49 UTC (permalink / raw)
To: Namhyung Kim
Cc: Steven Rostedt, Ingo Molnar, Arnaldo Carvalho de Melo, Jiri Olsa,
David S. Miller, Daniel Borkmann, Hannes Frederic Sowa,
Brendan Gregg, Linux API, Network Development, LKML
On Wed, Jan 21, 2015 at 5:03 PM, Namhyung Kim <namhyung-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>
> AFAIK a trigger can be fired before allocating a ring buffer if it
> doesn't use the event record (i.e. has filter) or ->post_trigger bit
> set (stacktrace). Please see ftrace_trigger_soft_disabled().
yes, but such trigger has no arguments, so I would have to hack
ftrace_trigger_soft_disabled() to pass 'ctx' further down
and through all pointer dereferences and list walking.
Also there is no return value, so I have to add it as well
similar to post-triggers.
that's quite a bit of overhead that I would like to avoid.
Actually now I'm thinking to move condition
if (ftrace_file->flags & TRACE_EVENT_FL_BPF)
before ftrace_trigger_soft_disabled() check.
So programs always run first and if they return non-zero
then all standard processing will follow.
May be return value from the program can influence triggers.
That will nicely replace bpf_dump_stack()...the program
will return ETT_STACKTRACE constant to trigger dump.
> This also makes it keeping events in the soft-disabled state.
I was never able to figure out the use case for soft-disabled state.
Probably historical before static_key was done.
^ permalink raw reply
* Re: [PATCH tip 0/9] tracing: attach eBPF programs to tracepoints/syscalls/kprobe
From: Steven Rostedt @ 2015-01-22 1:56 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Namhyung Kim, Ingo Molnar, Arnaldo Carvalho de Melo, Jiri Olsa,
David S. Miller, Daniel Borkmann, Hannes Frederic Sowa,
Brendan Gregg, Linux API, Network Development, LKML
In-Reply-To: <CAMEtUux8v2LDtLcgpT9hCvJgnrCwT2fkzsSvAPFSuEUx+itxyQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, 21 Jan 2015 17:49:08 -0800
Alexei Starovoitov <ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org> wrote:
> > This also makes it keeping events in the soft-disabled state.
>
> I was never able to figure out the use case for soft-disabled state.
> Probably historical before static_key was done.
No, it's not historical at all. The "soft-disable" is a way to enable
from any context. You can't enable a static key from NMI or interrupt
context, but you can enable a "soft-disable" there.
As you can enable or disable events from any function that the function
tracer may trace, I needed a way to enable them (make the tracepoint
active), but do nothing until something else turns them on.
-- Steve
^ permalink raw reply
* Re: [PATCH tip 0/9] tracing: attach eBPF programs to tracepoints/syscalls/kprobe
From: Alexei Starovoitov @ 2015-01-22 2:13 UTC (permalink / raw)
To: Steven Rostedt
Cc: Namhyung Kim, Ingo Molnar, Arnaldo Carvalho de Melo, Jiri Olsa,
David S. Miller, Daniel Borkmann, Hannes Frederic Sowa,
Brendan Gregg, Linux API, Network Development, LKML
In-Reply-To: <20150121205643.4d8a3516-f9ZlEuEWxVcJvu8Pb33WZ0EMvNT87kid@public.gmane.org>
On Wed, Jan 21, 2015 at 5:56 PM, Steven Rostedt <rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org> wrote:
> On Wed, 21 Jan 2015 17:49:08 -0800
> Alexei Starovoitov <ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org> wrote:
>
>
>> > This also makes it keeping events in the soft-disabled state.
>>
>> I was never able to figure out the use case for soft-disabled state.
>> Probably historical before static_key was done.
>
> No, it's not historical at all. The "soft-disable" is a way to enable
> from any context. You can't enable a static key from NMI or interrupt
> context, but you can enable a "soft-disable" there.
>
> As you can enable or disable events from any function that the function
> tracer may trace, I needed a way to enable them (make the tracepoint
> active), but do nothing until something else turns them on.
Thanks for explanation. Makes sense.
Speaking of nmi... I think I will add a check that if (in_nmi())
just skip running the program, since supporting this use
case is not needed at the moment.
^ permalink raw reply
* Re: [net-next PATCH v3 01/12] net: flow_table: create interface for hw match/action tables
From: Simon Horman @ 2015-01-22 4:37 UTC (permalink / raw)
To: John Fastabend; +Cc: tgraf, sfeldma, netdev, jhs, davem, gerlitz.or, andy, ast
In-Reply-To: <20150120202636.1741.86426.stgit@nitbit.x32>
On Tue, Jan 20, 2015 at 12:26:37PM -0800, John Fastabend wrote:
[snip]
> diff --git a/include/linux/if_flow.h b/include/linux/if_flow.h
> new file mode 100644
> index 0000000..7ce1e1d
> --- /dev/null
> +++ b/include/linux/if_flow.h
> @@ -0,0 +1,188 @@
[snip]
> +#define NFL_JUMP_TABLE_DONE 0
> +enum {
> + NFL_JUMP_ENTRY_UNSPEC,
> + NFL_JUMP_ENTRY,
> + __NFL_JUMP_ENTRY_MAX,
> +};
For consistency it seems that the following could go here:
#define NFL_JUMP_ENTRY_MAX (__NFL_JUMP_ENTRY_MAX - 1)
> +enum {
> + NFL_HEADER_NODE_HDRS_UNSPEC,
> + NFL_HEADER_NODE_HDRS_VALUE,
> + __NFL_HEADER_NODE_HDRS_MAX,
> +};
> +
> +#define NFL_HEADER_NODE_HDRS_MAX (__NFL_HEADER_NODE_HDRS_MAX - 1)
> +
> +enum {
> + NFL_HEADER_NODE_UNSPEC,
> + NFL_HEADER_NODE_NAME,
> + NFL_HEADER_NODE_UID,
> + NFL_HEADER_NODE_HDRS,
> + NFL_HEADER_NODE_JUMP,
> + __NFL_HEADER_NODE_MAX,
> +};
> +
> +#define NFL_HEADER_NODE_MAX (__NFL_HEADER_NODE_MAX - 1)
> +
> +enum {
> + NFL_HEADER_GRAPH_UNSPEC,
> + NFL_HEADER_GRAPH_NODE,
> + __NFL_HEADER_GRAPH_MAX,
> +};
> +
> +#define NFL_HEADER_GRAPH_MAX (__NFL_HEADER_GRAPH_MAX - 1)
[snip]
^ permalink raw reply
* netxen: box stuck in netxen_napi_disable()
From: Mike Galbraith @ 2015-01-22 4:43 UTC (permalink / raw)
To: netdev
Greetings network wizards,
After doing some generic NO_HZ_FULL isolated core perturbation
measurements with a 64 core DL980G7 running 3.19-rc5, everything seeming
just peachy, I came back later to check on the box only to find that I
could no longer ssh into the thing. NO_HZ_FULL doesn't seem to be
involved in any obvious way, but I thought I should mention it.
No idea how repeatable this is, the box has other work to do atm. File
under 'noted', or if you want me to peek at something, holler.
rtnl_mutex was holding up the show, was held by the kworker below, who
was stuck in napi_synchronize() waiting for NAPI_STATE_SCHED to go away,
but whoever was supposed to make that happen, didn't.
crash> ps | grep UN
405 2 2 ffff880273958000 UN 0.0 0 0 [kworker/2:1]
419 2 16 ffff880273bf0000 UN 0.0 0 0 [kworker/16:1]
4259 1 21 ffff88026f3cbaa0 UN 0.0 14636 1908 dhcpcd
6007 1 3 ffff8802736d1d50 UN 0.0 32292 3200 ntpd
6048 1 0 ffff880272521d50 UN 0.0 59568 3460 ypbind
13650 2 2 ffff8802749b0000 UN 0.0 0 0 [kworker/2:2]
crash> bt ffff880273958000
PID: 405 TASK: ffff880273958000 CPU: 2 COMMAND: "kworker/2:1"
#0 [ffff880273957c10] __schedule at ffffffff81588c59
#1 [ffff880273957c80] schedule at ffffffff81589119
#2 [ffff880273957c90] schedule_timeout at ffffffff8158bbe6
#3 [ffff880273957d30] msleep at ffffffff810c5aa7
#4 [ffff880273957d50] netxen_napi_disable at ffffffffa032892a [netxen_nic]
#5 [ffff880273957d80] __netxen_nic_down at ffffffffa032c6fc [netxen_nic]
#6 [ffff880273957dc0] netxen_nic_reset_context at ffffffffa032d56b [netxen_nic]
#7 [ffff880273957de0] netxen_tx_timeout_task at ffffffffa032d63d [netxen_nic]
#8 [ffff880273957e00] process_one_work at ffffffff81077b7a
#9 [ffff880273957e50] worker_thread at ffffffff81078231
#10 [ffff880273957ec0] kthread at ffffffff8107d139
#11 [ffff880273957f50] ret_from_fork at ffffffff8158cf7c
^ permalink raw reply
* Re: netxen: box stuck in netxen_napi_disable()
From: Eric Dumazet @ 2015-01-22 5:57 UTC (permalink / raw)
To: Mike Galbraith; +Cc: netdev
In-Reply-To: <1421901805.5286.37.camel@marge.simpson.net>
On Thu, 2015-01-22 at 05:43 +0100, Mike Galbraith wrote:
> Greetings network wizards,
>
> After doing some generic NO_HZ_FULL isolated core perturbation
> measurements with a 64 core DL980G7 running 3.19-rc5, everything seeming
> just peachy, I came back later to check on the box only to find that I
> could no longer ssh into the thing. NO_HZ_FULL doesn't seem to be
> involved in any obvious way, but I thought I should mention it.
>
> No idea how repeatable this is, the box has other work to do atm. File
> under 'noted', or if you want me to peek at something, holler.
>
> rtnl_mutex was holding up the show, was held by the kworker below, who
> was stuck in napi_synchronize() waiting for NAPI_STATE_SCHED to go away,
> but whoever was supposed to make that happen, didn't.
>
> crash> ps | grep UN
> 405 2 2 ffff880273958000 UN 0.0 0 0 [kworker/2:1]
> 419 2 16 ffff880273bf0000 UN 0.0 0 0 [kworker/16:1]
> 4259 1 21 ffff88026f3cbaa0 UN 0.0 14636 1908 dhcpcd
> 6007 1 3 ffff8802736d1d50 UN 0.0 32292 3200 ntpd
> 6048 1 0 ffff880272521d50 UN 0.0 59568 3460 ypbind
> 13650 2 2 ffff8802749b0000 UN 0.0 0 0 [kworker/2:2]
> crash> bt ffff880273958000
> PID: 405 TASK: ffff880273958000 CPU: 2 COMMAND: "kworker/2:1"
> #0 [ffff880273957c10] __schedule at ffffffff81588c59
> #1 [ffff880273957c80] schedule at ffffffff81589119
> #2 [ffff880273957c90] schedule_timeout at ffffffff8158bbe6
> #3 [ffff880273957d30] msleep at ffffffff810c5aa7
> #4 [ffff880273957d50] netxen_napi_disable at ffffffffa032892a [netxen_nic]
> #5 [ffff880273957d80] __netxen_nic_down at ffffffffa032c6fc [netxen_nic]
> #6 [ffff880273957dc0] netxen_nic_reset_context at ffffffffa032d56b [netxen_nic]
> #7 [ffff880273957de0] netxen_tx_timeout_task at ffffffffa032d63d [netxen_nic]
> #8 [ffff880273957e00] process_one_work at ffffffff81077b7a
> #9 [ffff880273957e50] worker_thread at ffffffff81078231
> #10 [ffff880273957ec0] kthread at ffffffff8107d139
> #11 [ffff880273957f50] ret_from_fork at ffffffff8158cf7c
Hi Mike
This driver doesn't follow the NAPI model correctly.
Please try following fix :
diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c b/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c
index 613037584d08..c531c8ae1be4 100644
--- a/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c
+++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c
@@ -2388,7 +2388,10 @@ static int netxen_nic_poll(struct napi_struct *napi, int budget)
work_done = netxen_process_rcv_ring(sds_ring, budget);
- if ((work_done < budget) && tx_complete) {
+ if (!tx_complete)
+ work_done = budget;
+
+ if (work_done < budget) {
napi_complete(&sds_ring->napi);
if (test_bit(__NX_DEV_UP, &adapter->state))
netxen_nic_enable_int(sds_ring);
^ permalink raw reply related
* Re: netxen: box stuck in netxen_napi_disable()
From: Mike Galbraith @ 2015-01-22 6:15 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1421906274.4832.35.camel@edumazet-glaptop2.roam.corp.google.com>
On Wed, 2015-01-21 at 21:57 -0800, Eric Dumazet wrote:
> This driver doesn't follow the NAPI model correctly.
>
> Please try following fix :
Thanks Eric, I'll plug it in in a bit and poke at it. No news is good
news, as good as news gets for unknown repeatability bugs that is ;-)
> diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c b/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c
> index 613037584d08..c531c8ae1be4 100644
> --- a/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c
> +++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c
> @@ -2388,7 +2388,10 @@ static int netxen_nic_poll(struct napi_struct *napi, int budget)
>
> work_done = netxen_process_rcv_ring(sds_ring, budget);
>
> - if ((work_done < budget) && tx_complete) {
> + if (!tx_complete)
> + work_done = budget;
> +
> + if (work_done < budget) {
> napi_complete(&sds_ring->napi);
> if (test_bit(__NX_DEV_UP, &adapter->state))
> netxen_nic_enable_int(sds_ring);
>
>
^ permalink raw reply
* Re: [PATCH 3/3] netlink: Lock out table resizes while dumping Netlink sockets
From: Herbert Xu @ 2015-01-22 6:35 UTC (permalink / raw)
To: Thomas Graf
Cc: Patrick McHardy, davem, paulmck, ying.xue, netdev,
netfilter-devel, Eric Dumazet
In-Reply-To: <20150121102346.GQ20315@casper.infradead.org>
On Wed, Jan 21, 2015 at 10:23:46AM +0000, Thomas Graf wrote:
>
> The usage will be identical to how __inet_lookup_listener() uses it.
> If at the end of the lookup, we ended up in a different table than
> we started, the lookup is restarted as an entry has moved to another
> table while we were moving over it.
Who uses this stuff apart from ip_dynaddr?
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: netxen: box stuck in netxen_napi_disable()
From: Eric Dumazet @ 2015-01-22 6:52 UTC (permalink / raw)
To: Mike Galbraith; +Cc: netdev
In-Reply-To: <1421907358.5286.42.camel@marge.simpson.net>
On Thu, 2015-01-22 at 07:15 +0100, Mike Galbraith wrote:
> On Wed, 2015-01-21 at 21:57 -0800, Eric Dumazet wrote:
>
> > This driver doesn't follow the NAPI model correctly.
> >
> > Please try following fix :
>
> Thanks Eric, I'll plug it in in a bit and poke at it. No news is good
> news, as good as news gets for unknown repeatability bugs that is ;-)
To trigger the bug, all you had to do was to stress the transmit side.
You could reduce MAX_STATUS_HANDLE from 64 to 4 to trigger it even
faster.
I'll send an official patch tomorrow morning.
Thanks !
^ permalink raw reply
* [PATCH 1/3] stmmac: if force_thresh_dma_mode is set, pass tc to both txmode and rxmode in tx_hard_error_bump_tc interrupt
From: Sonic Zhang @ 2015-01-22 6:55 UTC (permalink / raw)
To: Giuseppe Cavallaro, David S. Miller
Cc: netdev, adi-buildroot-devel, Sonic Zhang
From: Sonic Zhang <sonic.zhang@analog.com>
Dont' pass SF_DMA_MODE to rxmode in this case.
Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 8c6b7c1..5edfc8a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1446,7 +1446,11 @@ static void stmmac_dma_interrupt(struct stmmac_priv *priv)
/* Try to bump up the dma threshold on this failure */
if (unlikely(tc != SF_DMA_MODE) && (tc <= 256)) {
tc += 64;
- priv->hw->dma->dma_mode(priv->ioaddr, tc, SF_DMA_MODE);
+ if (priv->plat->force_thresh_dma_mode)
+ priv->hw->dma->dma_mode(priv->ioaddr, tc, tc);
+ else
+ priv->hw->dma->dma_mode(priv->ioaddr, tc,
+ SF_DMA_MODE);
priv->xstats.threshold = tc;
}
} else if (unlikely(status == tx_hard_error))
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH 3/3] netlink: Lock out table resizes while dumping Netlink sockets
From: Herbert Xu @ 2015-01-22 7:20 UTC (permalink / raw)
To: Thomas Graf
Cc: Patrick McHardy, davem, paulmck, ying.xue, netdev,
netfilter-devel, Eric Dumazet
In-Reply-To: <20150122063501.GA3746@gondor.apana.org.au>
On Thu, Jan 22, 2015 at 05:35:01PM +1100, Herbert Xu wrote:
> On Wed, Jan 21, 2015 at 10:23:46AM +0000, Thomas Graf wrote:
> >
> > The usage will be identical to how __inet_lookup_listener() uses it.
> > If at the end of the lookup, we ended up in a different table than
> > we started, the lookup is restarted as an entry has moved to another
> > table while we were moving over it.
>
> Who uses this stuff apart from ip_dynaddr?
OK it's there for fast socket recycling. Given that and the fact
that everyone seems to be happy with restarting the dump after a
resize, I think we should just go with that.
Anybody who wants a better walk can always implement their own
data structure outside of rhashtable.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH 2/3] stmmac: hardware TX COE doesn't work when force_thresh_dma_mode is set
From: Sonic Zhang @ 2015-01-22 6:55 UTC (permalink / raw)
To: Giuseppe Cavallaro, David S. Miller
Cc: netdev, adi-buildroot-devel, Sonic Zhang
In-Reply-To: <1421909758-31359-1-git-send-email-sonic.adi@gmail.com>
From: Sonic Zhang <sonic.zhang@analog.com>
Clear the TX COE bit when force_thresh_dma_mode is set even hardware
dma capability says support.
Tested on BF609.
Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 5edfc8a..7a7385a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2746,7 +2746,11 @@ static int stmmac_hw_init(struct stmmac_priv *priv)
priv->plat->enh_desc = priv->dma_cap.enh_desc;
priv->plat->pmt = priv->dma_cap.pmt_remote_wake_up;
- priv->plat->tx_coe = priv->dma_cap.tx_coe;
+ /* TXCOE doesn't work in thresh DMA mode */
+ if (priv->plat->force_thresh_dma_mode)
+ priv->plat->tx_coe = 0;
+ else
+ priv->plat->tx_coe = priv->dma_cap.tx_coe;
if (priv->dma_cap.rx_coe_type2)
priv->plat->rx_coe = STMMAC_RX_COE_TYPE2;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 3/3] stmmac: Add an optional device tree property "snps,burst_len"
From: Sonic Zhang @ 2015-01-22 6:55 UTC (permalink / raw)
To: Giuseppe Cavallaro, David S. Miller
Cc: netdev, adi-buildroot-devel, Sonic Zhang
In-Reply-To: <1421909758-31359-1-git-send-email-sonic.adi@gmail.com>
From: Sonic Zhang <sonic.zhang@analog.com>
This property define the AXI bug lenth.
Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
---
Documentation/devicetree/bindings/net/stmmac.txt | 1 +
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 3 +++
2 files changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt
index c41afd9..8ca65ce 100644
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -43,6 +43,7 @@ Optional properties:
available this clock is used for programming the Timestamp Addend Register.
If not passed then the system clock will be used and this is fine on some
platforms.
+- snps,burst_len: The AXI burst lenth value of the AXI BUS MODE register.
Examples:
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 3039de2..a20cf0d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -234,6 +234,9 @@ static int stmmac_probe_config_dt(struct platform_device *pdev,
of_property_read_bool(np, "snps,fixed-burst");
dma_cfg->mixed_burst =
of_property_read_bool(np, "snps,mixed-burst");
+ of_property_read_u32(np, "snps,burst_len", &dma_cfg->burst_len);
+ if (dma_cfg->burst_len < 0 || dma_cfg->burst_len > 256)
+ dma_cfg->burst_len = 0;
}
plat->force_thresh_dma_mode = of_property_read_bool(np, "snps,force_thresh_dma_mode");
if (plat->force_thresh_dma_mode) {
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH 2/3] stmmac: hardware TX COE doesn't work when force_thresh_dma_mode is set
From: Giuseppe CAVALLARO @ 2015-01-22 8:18 UTC (permalink / raw)
To: Sonic Zhang, David S. Miller; +Cc: netdev, adi-buildroot-devel, Sonic Zhang
In-Reply-To: <1421909758-31359-2-git-send-email-sonic.adi@gmail.com>
On 1/22/2015 7:55 AM, Sonic Zhang wrote:
> From: Sonic Zhang <sonic.zhang@analog.com>
>
> Clear the TX COE bit when force_thresh_dma_mode is set even hardware
> dma capability says support.
>
> Tested on BF609.
>
> Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
Acked-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
> ---
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 5edfc8a..7a7385a 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -2746,7 +2746,11 @@ static int stmmac_hw_init(struct stmmac_priv *priv)
> priv->plat->enh_desc = priv->dma_cap.enh_desc;
> priv->plat->pmt = priv->dma_cap.pmt_remote_wake_up;
>
> - priv->plat->tx_coe = priv->dma_cap.tx_coe;
> + /* TXCOE doesn't work in thresh DMA mode */
> + if (priv->plat->force_thresh_dma_mode)
> + priv->plat->tx_coe = 0;
> + else
> + priv->plat->tx_coe = priv->dma_cap.tx_coe;
>
> if (priv->dma_cap.rx_coe_type2)
> priv->plat->rx_coe = STMMAC_RX_COE_TYPE2;
>
^ permalink raw reply
* Re: [net PATCH 1/1] drivers: net: cpsw: discard dual emac default vlan configuration
From: Mugunthan V N @ 2015-01-22 8:20 UTC (permalink / raw)
To: Sergei Shtylyov, netdev; +Cc: davem, stable
In-Reply-To: <54BE6573.1040801@cogentembedded.com>
On Tuesday 20 January 2015 07:55 PM, Sergei Shtylyov wrote:
> Hello.
>
> On 1/20/2015 3:25 PM, Mugunthan V N wrote:
>
>> In Dual EMAC, the default vlans are used to segregate rx packets between
>
> VLANs. And RX.
>
>> the ports, so adding the same default vlan to the switch will affect the
>
> VLAN.
>
>> normal packet transfers. So returning error on addition of dual emac
>
> EMAC.
>
>> default vlans.
>
> VLANs.
>
>> Even if emac 0 default port vlan is added to emac 1, it will lead to
>
> EMAC. And VLAN
>
>> break
>
> Breaking.
>
>> dual EMAC port seperations.
>
> Separations.
>
>> Fixes: d9ba8f9 (driver: net: ethernet: cpsw: dual emac interface
>> implementation)
>
> 12 hex digits, please.
>
>> Cc: <stable@vger.kernel.org> # v3.9+
>> Reported-by: Felipe Balbi <balbi@ti.com>
>> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
>> ---
>> drivers/net/ethernet/ti/cpsw.c | 22 ++++++++++++++++++++++
>> 1 file changed, 22 insertions(+)
>
>> diff --git a/drivers/net/ethernet/ti/cpsw.c
>> b/drivers/net/ethernet/ti/cpsw.c
>> index e068d48..7c32815 100644
>> --- a/drivers/net/ethernet/ti/cpsw.c
>> +++ b/drivers/net/ethernet/ti/cpsw.c
>> @@ -1683,6 +1683,19 @@ static int cpsw_ndo_vlan_rx_add_vid(struct
>> net_device *ndev,
>> if (vid == priv->data.default_vlan)
>> return 0;
>>
>> + if (priv->data.dual_emac) {
>> + /* In dual EMAC, reserved VLAN id should not be used of
>
> s/of/for/, perhaps?
>
>> + * creating vlan interfaces as this can break the dual
>
> s/vlan/VLAN/. Be consistent, please.
>
>> + * EMAC port seperation
>
> Separation.
>
> [...]
Will fix this and resubmit next version.
Regards
Mugunthan V N
^ permalink raw reply
* Re: [PATCH 3/3] stmmac: Add an optional device tree property "snps,burst_len"
From: Giuseppe CAVALLARO @ 2015-01-22 8:20 UTC (permalink / raw)
To: Sonic Zhang, David S. Miller; +Cc: netdev, adi-buildroot-devel, Sonic Zhang
In-Reply-To: <1421909758-31359-3-git-send-email-sonic.adi@gmail.com>
On 1/22/2015 7:55 AM, Sonic Zhang wrote:
> From: Sonic Zhang <sonic.zhang@analog.com>
>
> This property define the AXI bug lenth.
Hello
I can accept this patch for now. So thx :-)
FYI, I will send a set of patches to program the AXI Bus mode
register providing more parameters from DT.
Peppe
>
> Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
> ---
> Documentation/devicetree/bindings/net/stmmac.txt | 1 +
> .../net/ethernet/stmicro/stmmac/stmmac_platform.c | 3 +++
> 2 files changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt
> index c41afd9..8ca65ce 100644
> --- a/Documentation/devicetree/bindings/net/stmmac.txt
> +++ b/Documentation/devicetree/bindings/net/stmmac.txt
> @@ -43,6 +43,7 @@ Optional properties:
> available this clock is used for programming the Timestamp Addend Register.
> If not passed then the system clock will be used and this is fine on some
> platforms.
> +- snps,burst_len: The AXI burst lenth value of the AXI BUS MODE register.
>
> Examples:
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> index 3039de2..a20cf0d 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
> @@ -234,6 +234,9 @@ static int stmmac_probe_config_dt(struct platform_device *pdev,
> of_property_read_bool(np, "snps,fixed-burst");
> dma_cfg->mixed_burst =
> of_property_read_bool(np, "snps,mixed-burst");
> + of_property_read_u32(np, "snps,burst_len", &dma_cfg->burst_len);
> + if (dma_cfg->burst_len < 0 || dma_cfg->burst_len > 256)
> + dma_cfg->burst_len = 0;
> }
> plat->force_thresh_dma_mode = of_property_read_bool(np, "snps,force_thresh_dma_mode");
> if (plat->force_thresh_dma_mode) {
>
^ permalink raw reply
* Re: netxen: box stuck in netxen_napi_disable()
From: Mike Galbraith @ 2015-01-22 8:37 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1421909520.3471.2.camel@edumazet-glaptop2.roam.corp.google.com>
On Wed, 2015-01-21 at 22:52 -0800, Eric Dumazet wrote:
> On Thu, 2015-01-22 at 07:15 +0100, Mike Galbraith wrote:
> > On Wed, 2015-01-21 at 21:57 -0800, Eric Dumazet wrote:
> >
> > > This driver doesn't follow the NAPI model correctly.
> > >
> > > Please try following fix :
> >
> > Thanks Eric, I'll plug it in in a bit and poke at it. No news is good
> > news, as good as news gets for unknown repeatability bugs that is ;-)
>
> To trigger the bug, all you had to do was to stress the transmit side.
Nope, it's easier than that...
> You could reduce MAX_STATUS_HANDLE from 64 to 4 to trigger it even
> faster.
Wow, that made it amazingly easy to verify.
With MAX_STATUS_HANDLE=4, without your patch applied box hangs as soon
as I bring the network up. Add your patch on top, all is peachy. Fresh
boot, or rmmod/modprobe and network restart, doesn't matter, box works
with your patch, is dead without it.
Here's an ornament for the fix if you think it'll look prettier :)
Reported-and-tested-by: Mike Galbraith <umgwanakikbuti@gmail.com>
-Mike
^ permalink raw reply
* Re: [PATCH 2/3] netlink: Mark dumps as inconsistent which have been interrupted by a resize
From: Herbert Xu @ 2015-01-22 8:49 UTC (permalink / raw)
To: Thomas Graf; +Cc: Ying Xue, davem, kaber, paulmck, netdev, netfilter-devel
In-Reply-To: <20150121121748.GD12570@casper.infradead.org>
On Wed, Jan 21, 2015 at 12:17:48PM +0000, Thomas Graf wrote:
>
> Thanks for the review. We also need to avoid hitting 0 when we overflow
> on a seq increment. The netfilter code is doing this correctly but several
> other users are suffering from this as well.
>
> I'll address this in v2 together with the other discussed changes.
Could you hold off for a bit? I've got some changes that touch
this area that I'd like to push out. Basically I'm trying to
eliminate direct access of rhashtable internals from the existing
users.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 2/3] netlink: Mark dumps as inconsistent which have been interrupted by a resize
From: Patrick McHardy @ 2015-01-22 8:56 UTC (permalink / raw)
To: Herbert Xu; +Cc: Thomas Graf, Ying Xue, davem, paulmck, netdev, netfilter-devel
In-Reply-To: <20150122084924.GA4720@gondor.apana.org.au>
On 22.01, Herbert Xu wrote:
> On Wed, Jan 21, 2015 at 12:17:48PM +0000, Thomas Graf wrote:
> >
> > Thanks for the review. We also need to avoid hitting 0 when we overflow
> > on a seq increment. The netfilter code is doing this correctly but several
> > other users are suffering from this as well.
> >
> > I'll address this in v2 together with the other discussed changes.
>
> Could you hold off for a bit? I've got some changes that touch
> this area that I'd like to push out. Basically I'm trying to
> eliminate direct access of rhashtable internals from the existing
> users.
Hope it will still be possible, I need it for GC in timeout support for
nftables sets.
Current patch attached for reference.
commit 91a334436d2f8eaa8261251d7d98cb700138f8b6
Author: Patrick McHardy <kaber@trash.net>
Date: Fri Jan 16 18:12:31 2015 +0000
netfilter: nft_hash: add support for timeouts
Signed-off-by: Patrick McHardy <kaber@trash.net>
diff --git a/net/netfilter/nft_hash.c b/net/netfilter/nft_hash.c
index cba0ad2..e7cf886 100644
--- a/net/netfilter/nft_hash.c
+++ b/net/netfilter/nft_hash.c
@@ -15,6 +15,7 @@
#include <linux/log2.h>
#include <linux/jhash.h>
#include <linux/netlink.h>
+#include <linux/workqueue.h>
#include <linux/rhashtable.h>
#include <linux/netfilter.h>
#include <linux/netfilter/nf_tables.h>
@@ -23,19 +24,47 @@
/* We target a hash table size of 4, element hint is 75% of final size */
#define NFT_HASH_ELEMENT_HINT 3
+struct nft_hash {
+ struct rhashtable ht;
+ struct delayed_work gc_work;
+};
+
struct nft_hash_elem {
struct rhash_head node;
struct nft_set_ext ext;
};
+struct nft_hash_compare_arg {
+ const struct nft_data *key;
+ unsigned int len;
+};
+
+static bool nft_hash_compare(void *ptr, void *arg)
+{
+ const struct nft_hash_elem *he = ptr;
+ struct nft_hash_compare_arg *x = arg;
+
+ if (nft_data_cmp(nft_set_ext_key(&he->ext), x->key, x->len))
+ return false;
+ if (nft_set_ext_exists(&he->ext, NFT_SET_EXT_TIMEOUT) &&
+ time_after_eq(jiffies, *nft_set_ext_timeout(&he->ext)))
+ return false;
+
+ return true;
+}
+
static bool nft_hash_lookup(const struct nft_set *set,
const struct nft_data *key,
const struct nft_set_ext **ext)
{
- struct rhashtable *priv = nft_set_priv(set);
+ struct nft_hash *priv = nft_set_priv(set);
const struct nft_hash_elem *he;
+ struct nft_hash_compare_arg arg = {
+ .key = key,
+ .len = set->klen,
+ };
- he = rhashtable_lookup(priv, key);
+ he = rhashtable_lookup_compare(&priv->ht, key, nft_hash_compare, &arg);
if (he != NULL)
*ext = &he->ext;
@@ -45,10 +74,10 @@ static bool nft_hash_lookup(const struct nft_set *set,
static int nft_hash_insert(const struct nft_set *set,
const struct nft_set_elem *elem)
{
- struct rhashtable *priv = nft_set_priv(set);
+ struct nft_hash *priv = nft_set_priv(set);
struct nft_hash_elem *he = elem->priv;
- rhashtable_insert(priv, &he->node);
+ rhashtable_insert(&priv->ht, &he->node);
return 0;
}
@@ -64,58 +93,43 @@ static void nft_hash_elem_destroy(const struct nft_set *set,
static void nft_hash_remove(const struct nft_set *set,
const struct nft_set_elem *elem)
{
- struct rhashtable *priv = nft_set_priv(set);
+ struct nft_hash *priv = nft_set_priv(set);
+ struct nft_hash_elem *he = elem->cookie;
- rhashtable_remove(priv, elem->cookie);
+ rhashtable_remove(&priv->ht, &he->node);
synchronize_rcu();
kfree(elem->cookie);
}
-struct nft_compare_arg {
- const struct nft_set *set;
- struct nft_set_elem *elem;
-};
-
-static bool nft_hash_compare(void *ptr, void *arg)
-{
- struct nft_hash_elem *he = ptr;
- struct nft_compare_arg *x = arg;
-
- if (!nft_data_cmp(nft_set_ext_key(&he->ext), &x->elem->key,
- x->set->klen)) {
- x->elem->cookie = he;
- x->elem->priv = he;
- return true;
- }
-
- return false;
-}
-
static int nft_hash_get(const struct nft_set *set, struct nft_set_elem *elem)
{
- struct rhashtable *priv = nft_set_priv(set);
- struct nft_compare_arg arg = {
- .set = set,
- .elem = elem,
+ struct nft_hash *priv = nft_set_priv(set);
+ struct nft_hash_elem *he;
+ struct nft_hash_compare_arg arg = {
+ .key = &elem->key,
+ .len = set->klen,
};
- if (rhashtable_lookup_compare(priv, &elem->key,
- &nft_hash_compare, &arg))
+ he = rhashtable_lookup_compare(&priv->ht, &elem->key,
+ nft_hash_compare, &arg);
+ if (he != NULL) {
+ elem->cookie = he;
+ elem->priv = he;
return 0;
-
+ }
return -ENOENT;
}
static void nft_hash_walk(const struct nft_ctx *ctx, const struct nft_set *set,
struct nft_set_iter *iter)
{
- struct rhashtable *priv = nft_set_priv(set);
+ struct nft_hash *priv = nft_set_priv(set);
const struct bucket_table *tbl;
struct nft_hash_elem *he;
struct nft_set_elem elem;
unsigned int i;
- tbl = rht_dereference_rcu(priv->tbl, priv);
+ tbl = rht_dereference_rcu(priv->ht.tbl, &priv->ht);
for (i = 0; i < tbl->size; i++) {
struct rhash_head *pos;
@@ -134,16 +148,48 @@ cont:
}
}
+static void nft_hash_gc(struct work_struct *work)
+{
+ const struct nft_set *set;
+ const struct bucket_table *tbl;
+ struct rhash_head *pos, *next;
+ struct nft_hash_elem *he;
+ struct nft_hash *priv;
+ unsigned long timeout;
+ unsigned int i;
+
+ priv = container_of(work, struct nft_hash, gc_work.work);
+ set = (void *)priv - offsetof(struct nft_set, data);
+
+ mutex_lock(&priv->ht.mutex);
+ tbl = rht_dereference(priv->ht.tbl, &priv->ht);
+ for (i = 0; i < tbl->size; i++) {
+ rht_for_each_entry_safe(he, pos, next, tbl, i, node) {
+ if (!nft_set_ext_exists(&he->ext, NFT_SET_EXT_TIMEOUT))
+ continue;
+ timeout = *nft_set_ext_timeout(&he->ext);
+ if (time_before(jiffies, timeout))
+ continue;
+
+ rhashtable_remove(&priv->ht, &he->node);
+ nft_hash_elem_destroy(set, he);
+ }
+ }
+ mutex_unlock(&priv->ht.mutex);
+
+ queue_delayed_work(system_power_efficient_wq, &priv->gc_work, HZ);
+}
+
static unsigned int nft_hash_privsize(const struct nlattr * const nla[])
{
- return sizeof(struct rhashtable);
+ return sizeof(struct nft_hash);
}
static int nft_hash_init(const struct nft_set *set,
const struct nft_set_desc *desc,
const struct nlattr * const tb[])
{
- struct rhashtable *priv = nft_set_priv(set);
+ struct nft_hash *priv = nft_set_priv(set);
struct rhashtable_params params = {
.nelem_hint = desc->size ? : NFT_HASH_ELEMENT_HINT,
.head_offset = offsetof(struct nft_hash_elem, node),
@@ -153,30 +199,42 @@ static int nft_hash_init(const struct nft_set *set,
.grow_decision = rht_grow_above_75,
.shrink_decision = rht_shrink_below_30,
};
+ int err;
- return rhashtable_init(priv, ¶ms);
+ err = rhashtable_init(&priv->ht, ¶ms);
+ if (err < 0)
+ return err;
+
+ INIT_DEFERRABLE_WORK(&priv->gc_work, nft_hash_gc);
+ if (set->flags & NFT_SET_TIMEOUT)
+ queue_delayed_work(system_power_efficient_wq,
+ &priv->gc_work, HZ);
+
+ return 0;
}
static void nft_hash_destroy(const struct nft_set *set)
{
- struct rhashtable *priv = nft_set_priv(set);
+ struct nft_hash *priv = nft_set_priv(set);
const struct bucket_table *tbl;
struct nft_hash_elem *he;
struct rhash_head *pos, *next;
unsigned int i;
+ cancel_delayed_work_sync(&priv->gc_work);
+
/* Stop an eventual async resizing */
- priv->being_destroyed = true;
- mutex_lock(&priv->mutex);
+ priv->ht.being_destroyed = true;
+ mutex_lock(&priv->ht.mutex);
- tbl = rht_dereference(priv->tbl, priv);
+ tbl = rht_dereference(priv->ht.tbl, &priv->ht);
for (i = 0; i < tbl->size; i++) {
rht_for_each_entry_safe(he, pos, next, tbl, i, node)
nft_hash_elem_destroy(set, he);
}
- mutex_unlock(&priv->mutex);
+ mutex_unlock(&priv->ht.mutex);
- rhashtable_destroy(priv);
+ rhashtable_destroy(&priv->ht);
}
static bool nft_hash_estimate(const struct nft_set_desc *desc, u32 features,
@@ -187,9 +245,11 @@ static bool nft_hash_estimate(const struct nft_set_desc *desc, u32 features,
esize = sizeof(struct nft_hash_elem);
if (features & NFT_SET_MAP)
esize += sizeof(struct nft_data);
+ if (features & NFT_SET_TIMEOUT)
+ esize += sizeof(unsigned long);
if (desc->size) {
- est->size = sizeof(struct rhashtable) +
+ est->size = sizeof(struct nft_hash) +
roundup_pow_of_two(desc->size * 4 / 3) *
sizeof(struct nft_hash_elem *) +
desc->size * esize;
@@ -218,7 +278,7 @@ static struct nft_set_ops nft_hash_ops __read_mostly = {
.remove = nft_hash_remove,
.lookup = nft_hash_lookup,
.walk = nft_hash_walk,
- .features = NFT_SET_MAP,
+ .features = NFT_SET_MAP | NFT_SET_TIMEOUT,
.owner = THIS_MODULE,
};
@@ -238,3 +298,4 @@ module_exit(nft_hash_module_exit);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Patrick McHardy <kaber@trash.net>");
MODULE_ALIAS_NFT_SET();
+
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox