* Off Topic: Request for Old Hardware
From: tedheadster @ 2014-09-23 18:56 UTC (permalink / raw)
To: netdev
If you have an ancient dual-processor 80486 system, please email me
off-list. Yes, a few of these did indeed exist.
- Matt
^ permalink raw reply
* Re: [PATCHv6 net-next 1/3] sunvnet: upgrade to VIO protocol version 1.6
From: David Miller @ 2014-09-23 18:44 UTC (permalink / raw)
To: david.stevens; +Cc: Raghuram.Kothakota, netdev
In-Reply-To: <5421A497.9060903@oracle.com>
From: David L Stevens <david.stevens@oracle.com>
Date: Tue, 23 Sep 2014 12:49:27 -0400
> Actually, that's exactly what I've been working on for the last few
> days. I hope to post this soon. Currently, I allow for misaligned
> packets by reallocating the skbs with the proper alignment, skip and
> length restrictions, so the code can handle either, but still copies
> most of the time. Once I have all the kinks worked out there, I was
> planning to possibly make *all* skb allocations on LDOMs and/or SPARC64 fit
> those requirements, since they are compatible with the existing alignments
> and would allow using the HV copy in any case.
You should be able to avoid the copy on TX almost all of the time.
If you do a skb_push(skb, VNET_PACKET_SKIP) (and initialize with some
garbage bytes) it ought to be aligned.
If not, we could tool around with the hard_header_ops to make
things come out the way we need it to.
^ permalink raw reply
* Re: [PATCH v4 3/9] Documentation: bindings: net: add the Marvell PXA168 Ethernet controller
From: Arnd Bergmann @ 2014-09-23 18:18 UTC (permalink / raw)
To: Sebastian Hesselbarth
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
zmxu-eYqpPyKDWXRBDgjK7y7TUQ, devicetree-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Antoine Tenart,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
jszhang-eYqpPyKDWXRBDgjK7y7TUQ
In-Reply-To: <5421AE7C.30504-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Tuesday 23 September 2014 19:31:40 Sebastian Hesselbarth wrote:
> It has been a while I looked it up in the pxa168 datasheet, but IIRC
> there is only one port per controller. FWIW, there actually is also
> just one port per controller for Orion SoCs. The multiple ports per
> controller comes from the PPC system controllers, i.e. mv643xx hence
> the name. We just made the binding look like it is more ports available
> to make it backwards compatible.. although I doubt anyone is still using
> mv643xx anywhere.
Ok, I see.
> > If there is only one port and we just have to know which one that is,
> > I don't think we need the child nodes, but if one can have multiple
> > ports operate independently then the driver will need a rework
> > to actually be usable with that configuration.
>
> I doubt pxa168 needs port nodes at all, i.e. we have the phy-handle
> directly as property of the controller node.
Ah, good.
> The HEC PHY node itself will be a sub-node of some future CEC node,
> while the (internal) MII PHY node can stay as a sub-node of the
> controller, e.g.
>
> (one final example to make sure we agree on the same)
>
> eth0: ethernet@f7b90000 {
> compatible = "marvell,pxa168-eth";
> reg = <...>;
> #address-cells = <1>;
> #size-cells = <0>;
> phy-handle = <ðphy0>;
>
> ethphy0: ethernet-phy@0 {
> reg = <0>;
> };
> };
>
> cec0: cec@f7f00baa {
> compatible = "marvell,berlin-cec";
> reg = <...>;
> #address-cells = <1>;
> #size-cells = <0>;
>
> hecphy0: hdmi-ethernet-phy@0 {
> reg = <0>;
> };
> };
>
> With berlin2cd-google-chromecast.dts overwriting
>
> ð0 { phy-handle = <&hecphy0>; };
Ok, now I also understood how the cec fits into this. Yes, I think this
looks very good.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: BCM4313 & brcmsmac & 3.12: only semi-working?
From: Michael Tokarev @ 2014-09-23 18:10 UTC (permalink / raw)
To: Arend van Spriel; +Cc: Seth Forshee, brcm80211-dev-list, linux-wireless, netdev
In-Reply-To: <5421AF5C.6000106@broadcom.com>
23.09.2014 21:35, Arend van Spriel wrote:
> On 09/23/14 18:02, Michael Tokarev wrote:
>> Oh. Indeed. While I enabled it, I recompiled only drivers/net/wireless,
>> but not net/. Rebuilt, another trace is here --
>>
>> http://www.corpit.ru/mjt/tmp/brcmsmac-4313-trace-201409233.dat.gz
>>
>> Thanks,
>
> Just to confirm. With this trace you also get a stall during wget?
Yes. Initially it started d/loading but some time later the d/load speed
reduced to 0. It is possible to wait further, and after some more time
it will receive some more bytes/kilobytes/packets and stall again. Overall
progress is nearing zero.
Thanks,
/mjt
^ permalink raw reply
* Re: [PATCH net] tcp: Fix TLP implementation in case receive window limits send
From: Yuchung Cheng @ 2014-09-23 17:54 UTC (permalink / raw)
To: Itzcak Pechtalt; +Cc: netdev@vger.kernel.org, Nandita Dukkipati, Neal Cardwell
In-Reply-To: <CAK6E8=eRUq1K5XRt9Ofzn7YWnfc7qP9ndrrF2hm0VXsPXYAeEQ@mail.gmail.com>
On Tue, Sep 23, 2014 at 10:52 AM, Yuchung Cheng <ycheng@google.com> wrote:
> On Tue, Sep 23, 2014 at 9:28 AM, Itzcak Pechtalt
> <itzcak@flashnetworks.com> wrote:
>> From: Itzcak Pechtalt <itzcak@flashnetworks.com>
>>
>> TCP Tail loss probe (TLP) algorithm implementation has some problem.
>> According to paper (draft-dukkipati-tcpm-tcp-loss-probe-0 ):
>> In case recive window of receiver limits send of new packet in probe time than
>> a retransmit of last packet send should be done.
>>
>> Actually, return code from tcp_write_xmit is not checked and only RTO is
>> scheduled,
>> So, it will take more time for reovery in this case than without TLP.
>>
>> Signed-off-by: Itzcak Pechtalt <itzcak@flashnetworks.com>
>> ---
>> net/ipv4/tcp_output.c | 2 +-
>> 1 file changed, 1 insertions(+), 1 deletions(-)
>>
>> diff -up a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
>> --- a/net/ipv4/tcp_output.c 2014-09-23 18:35:37.113771694 +0300
>> +++ b/net/ipv4/tcp_output.c 2014-09-23 18:39:58.207726420 +0300
>> @@ -2100,7 +2100,8 @@ void tcp_send_loss_probe(struct sock *sk
>>
>> if (tcp_send_head(sk) != NULL) {
>> err = tcp_write_xmit(sk, mss, TCP_NAGLE_OFF, 2, GFP_ATOMIC);
>> - goto rearm_timer;
> Doesn't tcp_write_xmit() return true if tcp_snd_wnd_test() fails? not
> sure I understand the fix.
Oops I read an old version of the code. Nevermind...
>
>> + if (!err)
>> + goto rearm_timer;
>> }
>>
>> /* At most one outstanding TLP retransmission. */
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net] tcp: Fix TLP implementation in case receive window limits send
From: Yuchung Cheng @ 2014-09-23 17:52 UTC (permalink / raw)
To: Itzcak Pechtalt; +Cc: netdev@vger.kernel.org, Nandita Dukkipati, Neal Cardwell
In-Reply-To: <6cbd68ba1ef44c5ca4b21bd3f65846af@AM3PR06MB388.eurprd06.prod.outlook.com>
On Tue, Sep 23, 2014 at 9:28 AM, Itzcak Pechtalt
<itzcak@flashnetworks.com> wrote:
> From: Itzcak Pechtalt <itzcak@flashnetworks.com>
>
> TCP Tail loss probe (TLP) algorithm implementation has some problem.
> According to paper (draft-dukkipati-tcpm-tcp-loss-probe-0 ):
> In case recive window of receiver limits send of new packet in probe time than
> a retransmit of last packet send should be done.
>
> Actually, return code from tcp_write_xmit is not checked and only RTO is
> scheduled,
> So, it will take more time for reovery in this case than without TLP.
>
> Signed-off-by: Itzcak Pechtalt <itzcak@flashnetworks.com>
> ---
> net/ipv4/tcp_output.c | 2 +-
> 1 file changed, 1 insertions(+), 1 deletions(-)
>
> diff -up a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> --- a/net/ipv4/tcp_output.c 2014-09-23 18:35:37.113771694 +0300
> +++ b/net/ipv4/tcp_output.c 2014-09-23 18:39:58.207726420 +0300
> @@ -2100,7 +2100,8 @@ void tcp_send_loss_probe(struct sock *sk
>
> if (tcp_send_head(sk) != NULL) {
> err = tcp_write_xmit(sk, mss, TCP_NAGLE_OFF, 2, GFP_ATOMIC);
> - goto rearm_timer;
Doesn't tcp_write_xmit() return true if tcp_snd_wnd_test() fails? not
sure I understand the fix.
> + if (!err)
> + goto rearm_timer;
> }
>
> /* At most one outstanding TLP retransmission. */
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] net/netfilter/x_tables.c: use __seq_open_private()
From: Ben Hutchings @ 2014-09-23 17:46 UTC (permalink / raw)
To: Rob Jones
Cc: davem, coreteam, netdev, linux-kernel, linux-kernel, netfilter,
netfilter-devel
In-Reply-To: <1411491955-9131-1-git-send-email-rob.jones@codethink.co.uk>
On Tue, 2014-09-23 at 18:05 +0100, Rob Jones wrote:
> Reduce boilerplate code by using __seq_open_private() instead of seq_open()
> in xt_match_open() and xt_target_open().
>
> Signed-off-by: Rob Jones <rob.jones@codethink.co.uk>
> ---
>
> This patch uses an existing variant of seq_open() to reduce the kernel code
> size.
>
> The only significant variation from the pre-existing code is the fact that
> __seq_open_private() calls kzalloc() rather than kmalloc(), which could
> conceivably have an impact on timing.
>
> This version 2 incorporates a minor initialisation simplification (resulting
> from kzalloc() being used) requested by netfilter-devel@vger.kernel.org
[...]
> --- a/net/netfilter/x_tables.c
> +++ b/net/netfilter/x_tables.c
> @@ -1080,7 +1080,6 @@ static void *xt_mttg_seq_start(struct seq_file *seq, loff_t *pos,
> struct nf_mttg_trav *trav = seq->private;
> unsigned int j;
>
> - trav->class = MTTG_TRAV_INIT;
> for (j = 0; j < *pos; ++j)
> if (xt_mttg_seq_next(seq, NULL, NULL, is_target) == NULL)
> return NULL;
[...]
I'm fairly sure this simplification is wrong, as xt_mttg_seq_start() is
potentially called multiple times on the same file handle.
Ben.
^ permalink raw reply
* Re: BCM4313 & brcmsmac & 3.12: only semi-working?
From: Arend van Spriel @ 2014-09-23 17:35 UTC (permalink / raw)
To: Michael Tokarev; +Cc: Seth Forshee, brcm80211-dev-list, linux-wireless, netdev
In-Reply-To: <54219984.2080601@msgid.tls.msk.ru>
On 09/23/14 18:02, Michael Tokarev wrote:
> 23.09.2014 18:31, Seth Forshee пишет:
>> On Tue, Sep 23, 2014 at 06:28:54PM +0400, Michael Tokarev wrote:
>>> 23.09.2014 18:25, Michael Tokarev wrote:
>>>> 23.09.2014 17:50, Arend van Spriel wrote:
>>>>> On 09/23/14 15:44, Seth Forshee wrote:
>>> []
>>>>>> It's been quite some time since I used them, but I think brcmsmac_tx is
>>>>>> quite noisy so you may only want to enable that if you already suspect a
>>>>>> tx problem. I always find it useful to enable the mac80211 and
>>>>>> mac80211_msg events too when debugging wireless, and I often enable
>>>>>> cfg80211 events as well (none of these are especially verbose).
>>>
>>> mac80211_msg does not exist, it looks like. fwiw.
>>
>> Did you check your kernel's config? You need to have
>> CONFIG_MAC80211_MESSAGE_TRACING enabled.
>
> Oh. Indeed. While I enabled it, I recompiled only drivers/net/wireless,
> but not net/. Rebuilt, another trace is here --
>
> http://www.corpit.ru/mjt/tmp/brcmsmac-4313-trace-201409233.dat.gz
>
> Thanks,
Just to confirm. With this trace you also get a stall during wget?
Regards,
Arend
> /mjt
>
^ permalink raw reply
* Re: [PATCH v4 3/9] Documentation: bindings: net: add the Marvell PXA168 Ethernet controller
From: Sebastian Hesselbarth @ 2014-09-23 17:31 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
zmxu-eYqpPyKDWXRBDgjK7y7TUQ, devicetree-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Antoine Tenart,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
jszhang-eYqpPyKDWXRBDgjK7y7TUQ
In-Reply-To: <5150779.ibmzDh88cj@wuerfel>
On 09/23/2014 07:02 PM, Arnd Bergmann wrote:
> On Tuesday 23 September 2014 18:40:46 Sebastian Hesselbarth wrote:
>> On 09/23/2014 06:29 PM, Arnd Bergmann wrote:
>>> On Tuesday 23 September 2014 17:45:52 Sebastian Hesselbarth wrote:
>>>> For reference, this is what we have for MVEBU SoCs with multiple ports
>>>> per controller:
>>>>
>>>> eth: ethernet-ctrl@72000 {
>>>> compatible = "marvell,orion-eth";
>> ...
>>>> reg = <0x72000 0x4000>;
>> ...
>>>>
>>>> ethernet-port@0 {
>>>> compatible = "marvell,orion-eth-port";
>> ...
>>>> phy-handle = <ðphy>;
>>>> };
>>>> };
>>>>
>>>> mdio: mdio-bus@72004 {
>>>> compatible = "marvell,orion-mdio";
>> ...
>>>> reg = <0x72004 0x84>;
>> ..
>>>> ethphy: ethernet-phy {
>>>> /* set phy address in board file */
>>>> };
>>>> };
>>
>>> But in this example, you have the same registers and the same
>>> clocks in two nodes, which are even used by the same device driver
>>> at the moment. It's not a big issue, but my feeling is that Antoine's
>>> approach was actually better because it more closely reflects
>>> the way that the hardware is built.
>>
>> I was not referring to the separate mdio bus node, but putting the
>> ethernet-phy node as a child of ethernet-ctrl.
>
> Ah, got it (I think). Yes, that makes sense.
> The part I don't understand yet is how one uses multiple ports. pxa168_eth.c
> seems to be written with the assumption that only one port is ever used at
> a time, while mv643xx_eth.c can actually use multiple ports simultaneously.
>
> Do you think that is that a hardware limitation of pxa168_eth or a feature
> that nobody so far has needed from the driver?
It has been a while I looked it up in the pxa168 datasheet, but IIRC
there is only one port per controller. FWIW, there actually is also
just one port per controller for Orion SoCs. The multiple ports per
controller comes from the PPC system controllers, i.e. mv643xx hence
the name. We just made the binding look like it is more ports available
to make it backwards compatible.. although I doubt anyone is still using
mv643xx anywhere.
> If there is only one port and we just have to know which one that is,
> I don't think we need the child nodes, but if one can have multiple
> ports operate independently then the driver will need a rework
> to actually be usable with that configuration.
I doubt pxa168 needs port nodes at all, i.e. we have the phy-handle
directly as property of the controller node.
The HEC PHY node itself will be a sub-node of some future CEC node,
while the (internal) MII PHY node can stay as a sub-node of the
controller, e.g.
(one final example to make sure we agree on the same)
eth0: ethernet@f7b90000 {
compatible = "marvell,pxa168-eth";
reg = <...>;
#address-cells = <1>;
#size-cells = <0>;
phy-handle = <ðphy0>;
ethphy0: ethernet-phy@0 {
reg = <0>;
};
};
cec0: cec@f7f00baa {
compatible = "marvell,berlin-cec";
reg = <...>;
#address-cells = <1>;
#size-cells = <0>;
hecphy0: hdmi-ethernet-phy@0 {
reg = <0>;
};
};
With berlin2cd-google-chromecast.dts overwriting
ð0 { phy-handle = <&hecphy0>; };
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2] net/netfilter/x_tables.c: use __seq_open_private()
From: Rob Jones @ 2014-09-23 17:05 UTC (permalink / raw)
To: davem
Cc: netfilter, coreteam, netfilter-devel, netdev, linux-kernel,
linux-kernel, rob.jones
Reduce boilerplate code by using __seq_open_private() instead of seq_open()
in xt_match_open() and xt_target_open().
Signed-off-by: Rob Jones <rob.jones@codethink.co.uk>
---
This patch uses an existing variant of seq_open() to reduce the kernel code
size.
The only significant variation from the pre-existing code is the fact that
__seq_open_private() calls kzalloc() rather than kmalloc(), which could
conceivably have an impact on timing.
This version 2 incorporates a minor initialisation simplification (resulting
from kzalloc() being used) requested by netfilter-devel@vger.kernel.org
net/netfilter/x_tables.c | 31 ++++---------------------------
1 file changed, 4 insertions(+), 27 deletions(-)
diff --git a/net/netfilter/x_tables.c b/net/netfilter/x_tables.c
index 227aa11..393f17b 100644
--- a/net/netfilter/x_tables.c
+++ b/net/netfilter/x_tables.c
@@ -1080,7 +1080,6 @@ static void *xt_mttg_seq_start(struct seq_file *seq, loff_t *pos,
struct nf_mttg_trav *trav = seq->private;
unsigned int j;
- trav->class = MTTG_TRAV_INIT;
for (j = 0; j < *pos; ++j)
if (xt_mttg_seq_next(seq, NULL, NULL, is_target) == NULL)
return NULL;
@@ -1137,22 +1136,11 @@ static const struct seq_operations xt_match_seq_ops = {
static int xt_match_open(struct inode *inode, struct file *file)
{
- struct seq_file *seq;
struct nf_mttg_trav *trav;
- int ret;
-
- trav = kmalloc(sizeof(*trav), GFP_KERNEL);
- if (trav == NULL)
+ trav = __seq_open_private(file, &xt_match_seq_ops, sizeof(*trav));
+ if (!trav)
return -ENOMEM;
- ret = seq_open(file, &xt_match_seq_ops);
- if (ret < 0) {
- kfree(trav);
- return ret;
- }
-
- seq = file->private_data;
- seq->private = trav;
trav->nfproto = (unsigned long)PDE_DATA(inode);
return 0;
}
@@ -1201,22 +1189,11 @@ static const struct seq_operations xt_target_seq_ops = {
static int xt_target_open(struct inode *inode, struct file *file)
{
- struct seq_file *seq;
struct nf_mttg_trav *trav;
- int ret;
-
- trav = kmalloc(sizeof(*trav), GFP_KERNEL);
- if (trav == NULL)
+ trav = __seq_open_private(file, &xt_target_seq_ops, sizeof(*trav));
+ if (!trav)
return -ENOMEM;
- ret = seq_open(file, &xt_target_seq_ops);
- if (ret < 0) {
- kfree(trav);
- return ret;
- }
-
- seq = file->private_data;
- seq->private = trav;
trav->nfproto = (unsigned long)PDE_DATA(inode);
return 0;
}
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH v4 3/9] Documentation: bindings: net: add the Marvell PXA168 Ethernet controller
From: Arnd Bergmann @ 2014-09-23 17:02 UTC (permalink / raw)
To: Sebastian Hesselbarth
Cc: linux-arm-kernel, thomas.petazzoni, zmxu, devicetree, netdev,
Antoine Tenart, linux-kernel, alexandre.belloni, jszhang
In-Reply-To: <5421A28E.7060600@gmail.com>
On Tuesday 23 September 2014 18:40:46 Sebastian Hesselbarth wrote:
> On 09/23/2014 06:29 PM, Arnd Bergmann wrote:
> > On Tuesday 23 September 2014 17:45:52 Sebastian Hesselbarth wrote:
> >> For reference, this is what we have for MVEBU SoCs with multiple ports
> >> per controller:
> >>
> >> eth: ethernet-ctrl@72000 {
> >> compatible = "marvell,orion-eth";
> ...
> >> reg = <0x72000 0x4000>;
> ...
> >>
> >> ethernet-port@0 {
> >> compatible = "marvell,orion-eth-port";
> ...
> >> phy-handle = <ðphy>;
> >> };
> >> };
> >>
> >> mdio: mdio-bus@72004 {
> >> compatible = "marvell,orion-mdio";
> ...
> >> reg = <0x72004 0x84>;
> ..
> >> ethphy: ethernet-phy {
> >> /* set phy address in board file */
> >> };
> >> };
>
> > But in this example, you have the same registers and the same
> > clocks in two nodes, which are even used by the same device driver
> > at the moment. It's not a big issue, but my feeling is that Antoine's
> > approach was actually better because it more closely reflects
> > the way that the hardware is built.
>
> I was not referring to the separate mdio bus node, but putting the
> ethernet-phy node as a child of ethernet-ctrl.
Ah, got it (I think). Yes, that makes sense.
The part I don't understand yet is how one uses multiple ports. pxa168_eth.c
seems to be written with the assumption that only one port is ever used at
a time, while mv643xx_eth.c can actually use multiple ports simultaneously.
Do you think that is that a hardware limitation of pxa168_eth or a feature
that nobody so far has needed from the driver?
If there is only one port and we just have to know which one that is,
I don't think we need the child nodes, but if one can have multiple
ports operate independently then the driver will need a rework
to actually be usable with that configuration.
Arnd
^ permalink raw reply
* Re: ip6_udp_tunnel fails to load
From: Tom Herbert @ 2014-09-23 16:55 UTC (permalink / raw)
To: Eyal perry
Cc: Eric Dumazet, Andy Zhou, Linux Netdev List, Or Gerlitz,
Amir Vadai
In-Reply-To: <5421A0E1.2050309@dev.mellanox.co.il>
On Tue, Sep 23, 2014 at 9:33 AM, Eyal perry <eyalpe@dev.mellanox.co.il> wrote:
> On 9/23/2014 6:39 PM, Eric Dumazet wrote:
>> On Tue, 2014-09-23 at 18:21 +0300, Eyal perry wrote:
>>> Hello Andy,
>>>
>>> Lately I've start to observe a phenomena where the mlx4_en driver
>>> couldn't load on my system as a result of an 'Unknown symbol in module'.
>>>
>>> [ 1277.458715] ip6_udp_tunnel: Unknown symbol ip6_local_out (err 0)
>>> [ 1277.486810] ip6_udp_tunnel: Unknown symbol __put_net (err 0)
>>>
>>> Apparently, the mlx4_en driver is depend on the vxlan driver, which
>>> depends on the ip6_udp_tunnel module which fails to load.
>>>
>>> 1. I've bisected this issue down to the following commit:
>>> fd38441 udp_tunnel: Seperate ipv6 functions into its own file.
>>>
>>> 2. on a different host with a different .config, the module is loads
>>> cleanly.
>>>
>>> 3. my sources are based on net-next commit
>>> 6d967f8 udp_tunnel: Only build ip6_udp_tunnel.c when IPV6 is selected
>>>
>>> I'll send you both of the .config files in a private message.
>>>
>>> This issue is making any driver which is depend on vxlan/ip6_udp_tunnel
>>> unusable, please take a look and fix
>>
>> Have you tried this patch ?
>>
>> https://patchwork.ozlabs.org/patch/392275/
>>
>> Thanks
>
Try https://patchwork.ozlabs.org/patch/392109/
Tom
> Hello Eric,
>
> Now I've tried but it still fails - the vxlan is still depends on the
> ip6_udp_tunnel and it still fails to load because of the missing symbols
> mentioned above.
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] net: bcmgenet: Fix compile warning
From: Florian Fainelli @ 2014-09-23 16:54 UTC (permalink / raw)
To: Tobias Klauser; +Cc: David S. Miller, Geert Uytterhoeven, netdev
In-Reply-To: <1411478381-9059-1-git-send-email-tklauser@distanz.ch>
2014-09-23 6:19 GMT-07:00 Tobias Klauser <tklauser@distanz.ch>:
> bcmgenet_wol_resume() is only used in bcmgenet_resume(), which is only
> defined when CONFIG_PM_SLEEP is enabled. This leads to the following
> compile warning when building with !CONFIG_PM_SLEEP:
>
> drivers/net/ethernet/broadcom/genet/bcmgenet.c:1967:12: warning: ‘bcmgenet_wol_resume’ defined but not used [-Wunused-function]
>
> Since bcmgenet_resume() is the only user of bcmgenet_wol_resume(), fix
> this by directly inlining the function there.
>
> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> drivers/net/ethernet/broadcom/genet/bcmgenet.c | 23 +++++++----------------
> 1 file changed, 7 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> index 313c400..e852d20 100644
> --- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> +++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> @@ -1964,19 +1964,6 @@ static void bcmgenet_set_hw_addr(struct bcmgenet_priv *priv,
> bcmgenet_umac_writel(priv, (addr[4] << 8) | addr[5], UMAC_MAC1);
> }
>
> -static int bcmgenet_wol_resume(struct bcmgenet_priv *priv)
> -{
> - /* From WOL-enabled suspend, switch to regular clock */
> - if (priv->wolopts)
> - clk_disable_unprepare(priv->clk_wol);
> -
> - phy_init_hw(priv->phydev);
> - /* Speed settings must be restored */
> - bcmgenet_mii_config(priv->dev);
> -
> - return 0;
> -}
> -
> /* Returns a reusable dma control register value */
> static u32 bcmgenet_dma_disable(struct bcmgenet_priv *priv)
> {
> @@ -2681,9 +2668,13 @@ static int bcmgenet_resume(struct device *d)
> if (ret)
> goto out_clk_disable;
>
> - ret = bcmgenet_wol_resume(priv);
> - if (ret)
> - goto out_clk_disable;
> + /* From WOL-enabled suspend, switch to regular clock */
> + if (priv->wolopts)
> + clk_disable_unprepare(priv->clk_wol);
> +
> + phy_init_hw(priv->phydev);
> + /* Speed settings must be restored */
> + bcmgenet_mii_config(priv->dev);
>
> /* disable ethernet MAC while updating its registers */
> umac_enable_set(priv, CMD_TX_EN | CMD_RX_EN, false);
> --
> 2.0.1
>
>
--
Florian
^ permalink raw reply
* Re: [PATCHv6 net-next 1/3] sunvnet: upgrade to VIO protocol version 1.6
From: David L Stevens @ 2014-09-23 16:49 UTC (permalink / raw)
To: David Miller; +Cc: Raghuram.Kothakota, netdev
In-Reply-To: <20140923.122420.1216927815526255624.davem@davemloft.net>
On 09/23/2014 12:24 PM, David Miller wrote:
> From: David L Stevens <david.stevens@oracle.com>
> Date: Thu, 18 Sep 2014 09:03:52 -0400
>
>> So, if this is actually too much memory, I was more inclined to reduce the ring
>> size rather than either add complicating code to handle active-ring reallocation
>> that would typically be run once per boot, or another alternative of adding
>> module parameters to specify the buffer size TSO/GSO will need 64K to perform
>> well, regardless of the device MTU.
>
> The only reason we are having this discussion is because of how we
> handle TX packets.
>
> I think we really should directly map the SKBs in vnet_start_xmit()
> instead of having these preallocate TX buffers.
>
> The only thing to accomodate is the VNET_PACKET_SKIP, but that
> shouldn't be hard at all.
>
> And I am rather certain that an LDC map call will be cheaper than
> copying the entire packet.
>
> Then the MTU will have no material impact on per-vnet_port memory
> costs, and bulk sending performance should also increase.
>
Actually, that's exactly what I've been working on for the last few
days. I hope to post this soon. Currently, I allow for misaligned
packets by reallocating the skbs with the proper alignment, skip and
length restrictions, so the code can handle either, but still copies
most of the time. Once I have all the kinks worked out there, I was
planning to possibly make *all* skb allocations on LDOMs and/or SPARC64 fit
those requirements, since they are compatible with the existing alignments
and would allow using the HV copy in any case.
> David I know you've worked hard on this patch set, but I'm going to
> defer on this series for now. There are several implementation level
> issues that are still seemingly up in the air.
Yes, sorry if it wasn't clear in my response to Raghuram, but I
agree to the extent that we shouldn't attach large-buffer allocations to
something scaling at O(n^2), which is why I started on this other patch.
> I'm almost completely sold on your PMTU scheme, however if we do
> direct mapping of SKBs in vnet_start_xmit() then the performance
> characteristics with larger MTUs might be different.
Yes; the good news is that without the fixed-size buffers,
memory use is only for the pending traffic, greatly improving scalability.
The bad news is that the allocs and frees will have a performance cost,
which I'm hoping will be balanced or bettered by removing the copy.
Anyway, I'll repost when I have all this ready.
+-DLS
^ permalink raw reply
* Re: [PATCH net-next] tcp: add coalescing attempt in tcp_ofo_queue()
From: David Miller @ 2014-09-23 16:48 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, ncardwell, ycheng
In-Reply-To: <1411140380.26859.28.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 19 Sep 2014 08:26:20 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> In order to make TCP more resilient in presence of reorders, we need
> to allow coalescing to happen when skbs from out of order queue are
> transferred into receive queue. LRO/GRO can be completely canceled
> in some pathological cases, like per packet load balancing on aggregated
> links.
>
> I had to move tcp_try_coalesce() up in the file above tcp_ofo_queue()
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> ---
>
> Note: I am not sure we really need this part in tcp_try_coalesce(),
> as I doubt we need ack_seq in the skbs stored in receive queues ?
>
> TCP_SKB_CB(to)->ack_seq = TCP_SKB_CB(from)->ack_seq;
Yes, it's used only for incoming ACKs. But better safe than
sorry. :-)
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] icmp: add a global rate limitation
From: David Miller @ 2014-09-23 16:48 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1411137520.26859.13.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 19 Sep 2014 07:38:40 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> Current ICMP rate limiting uses inetpeer cache, which is an RBL tree
> protected by a lock, meaning that hosts can be stuck hard if all cpus
> want to check ICMP limits.
>
> When say a DNS or NTP server process is restarted, inetpeer tree grows
> quick and machine comes to its knees.
>
> iptables can not help because the bottleneck happens before ICMP
> messages are even cooked and sent.
>
> This patch adds a new global limitation, using a token bucket filter,
> controlled by two new sysctl :
>
> icmp_msgs_per_sec - INTEGER
> Limit maximal number of ICMP packets sent per second from this host.
> Only messages whose type matches icmp_ratemask are
> controlled by this limit.
> Default: 1000
>
> icmp_msgs_burst - INTEGER
> icmp_msgs_per_sec controls number of ICMP packets sent per second,
> while icmp_msgs_burst controls the burst size of these packets.
> Default: 50
>
> Note that if we really want to send millions of ICMP messages per
> second, we might extend idea and infra added in commit 04ca6973f7c1a
> ("ip: make IP identifiers less predictable") :
> add a token bucket in the ip_idents hash and no longer rely on inetpeer.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next v2] net: bpf: arm: make hole-faulting more robust
From: David Miller @ 2014-09-23 16:40 UTC (permalink / raw)
To: dborkman
Cc: netdev, linux-arm-kernel, linux, catalin.marinas, will.deacon,
mgherzan, ast
In-Reply-To: <1411131417-23667-1-git-send-email-dborkman@redhat.com>
From: Daniel Borkmann <dborkman@redhat.com>
Date: Fri, 19 Sep 2014 14:56:57 +0200
> Will Deacon pointed out, that the currently used opcode for filling holes,
> that is 0xe7ffffff, seems not robust enough ...
...
> ... which is a bit fragile. The ARM specification defines some *permanently*
> guaranteed undefined instruction (UDF) space, for example for ARM in ARMv7-AR,
> section A5.4 and for Thumb in ARMv7-M, section A5.2.6.
>
> Similarly, ptrace, kprobes, kgdb, bug and uprobes make use of such instruction
> as well to trap. Given mentioned section from the specification, we can find
> such a universe as (where 'x' denotes 'don't care'):
>
> ARM: xxxx 0111 1111 xxxx xxxx xxxx 1111 xxxx
> Thumb: 1101 1110 xxxx xxxx
>
> We therefore should use a more robust opcode that fits both. Russell King
> suggested that we can even reuse a single 32-bit word, that is, 0xe7fddef1
> which will fault if executed in ARM *or* Thumb mode as done in f928d4f2a86f
> ("ARM: poison the vectors page"). That will still hold our requirements:
...
> So on ARM 0xe7fddef1 conforms to the above UDF pattern, and the low 16 bit
> likewise correspond to UDF in Thumb case. The 0xe7fd part is an unconditional
> branch back to the UDF instruction.
>
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Applied, thanks Daniel.
^ permalink raw reply
* Re: [PATCH v4 3/9] Documentation: bindings: net: add the Marvell PXA168 Ethernet controller
From: Sebastian Hesselbarth @ 2014-09-23 16:40 UTC (permalink / raw)
To: Arnd Bergmann, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
zmxu-eYqpPyKDWXRBDgjK7y7TUQ, devicetree-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Antoine Tenart,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
jszhang-eYqpPyKDWXRBDgjK7y7TUQ
In-Reply-To: <9401592.hUYDkriFVO@wuerfel>
On 09/23/2014 06:29 PM, Arnd Bergmann wrote:
> On Tuesday 23 September 2014 17:45:52 Sebastian Hesselbarth wrote:
>> For reference, this is what we have for MVEBU SoCs with multiple ports
>> per controller:
>>
>> eth: ethernet-ctrl@72000 {
>> compatible = "marvell,orion-eth";
...
>> reg = <0x72000 0x4000>;
...
>>
>> ethernet-port@0 {
>> compatible = "marvell,orion-eth-port";
...
>> phy-handle = <ðphy>;
>> };
>> };
>>
>> mdio: mdio-bus@72004 {
>> compatible = "marvell,orion-mdio";
...
>> reg = <0x72004 0x84>;
..
>> ethphy: ethernet-phy {
>> /* set phy address in board file */
>> };
>> };
> But in this example, you have the same registers and the same
> clocks in two nodes, which are even used by the same device driver
> at the moment. It's not a big issue, but my feeling is that Antoine's
> approach was actually better because it more closely reflects
> the way that the hardware is built.
I was not referring to the separate mdio bus node, but putting the
ethernet-phy node as a child of ethernet-ctrl.
Anyway, I can live with the ethernet-phy being a child of the controller
node until we discover where it is hooked up.
For the internal MII PHY the controller node maybe is the only sane
place to put it in. The HEC PHY will reside within the CEC IP node but
that is compatible with Antoine's proposal.
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: ip6_udp_tunnel fails to load
From: Eyal perry @ 2014-09-23 16:33 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Andy Zhou, netdev, Or Gerlitz, Amir Vadai
In-Reply-To: <1411486777.26859.189.camel@edumazet-glaptop2.roam.corp.google.com>
On 9/23/2014 6:39 PM, Eric Dumazet wrote:
> On Tue, 2014-09-23 at 18:21 +0300, Eyal perry wrote:
>> Hello Andy,
>>
>> Lately I've start to observe a phenomena where the mlx4_en driver
>> couldn't load on my system as a result of an 'Unknown symbol in module'.
>>
>> [ 1277.458715] ip6_udp_tunnel: Unknown symbol ip6_local_out (err 0)
>> [ 1277.486810] ip6_udp_tunnel: Unknown symbol __put_net (err 0)
>>
>> Apparently, the mlx4_en driver is depend on the vxlan driver, which
>> depends on the ip6_udp_tunnel module which fails to load.
>>
>> 1. I've bisected this issue down to the following commit:
>> fd38441 udp_tunnel: Seperate ipv6 functions into its own file.
>>
>> 2. on a different host with a different .config, the module is loads
>> cleanly.
>>
>> 3. my sources are based on net-next commit
>> 6d967f8 udp_tunnel: Only build ip6_udp_tunnel.c when IPV6 is selected
>>
>> I'll send you both of the .config files in a private message.
>>
>> This issue is making any driver which is depend on vxlan/ip6_udp_tunnel
>> unusable, please take a look and fix
>
> Have you tried this patch ?
>
> https://patchwork.ozlabs.org/patch/392275/
>
> Thanks
Hello Eric,
Now I've tried but it still fails - the vxlan is still depends on the
ip6_udp_tunnel and it still fails to load because of the missing symbols
mentioned above.
^ permalink raw reply
* Re: [PATCH v4 3/9] Documentation: bindings: net: add the Marvell PXA168 Ethernet controller
From: Arnd Bergmann @ 2014-09-23 16:29 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Sebastian Hesselbarth,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
zmxu-eYqpPyKDWXRBDgjK7y7TUQ, devicetree-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Antoine Tenart,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
jszhang-eYqpPyKDWXRBDgjK7y7TUQ
In-Reply-To: <542195B0.6080706-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Tuesday 23 September 2014 17:45:52 Sebastian Hesselbarth wrote:
> For reference, this is what we have for MVEBU SoCs with multiple ports
> per controller:
>
> eth: ethernet-ctrl@72000 {
> compatible = "marvell,orion-eth";
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <0x72000 0x4000>;
> clocks = <&gate_clk 2>;
> marvell,tx-checksum-limit = <1600>;
> status = "disabled";
>
> ethernet-port@0 {
> compatible = "marvell,orion-eth-port";
> reg = <0>;
> interrupts = <29>;
> /* overwrite MAC address in bootloader */
> local-mac-address = [00 00 00 00 00 00];
> phy-handle = <ðphy>;
> };
> };
>
> mdio: mdio-bus@72004 {
> compatible = "marvell,orion-mdio";
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <0x72004 0x84>;
> interrupts = <30>;
> clocks = <&gate_clk 2>;
> status = "disabled";
> ethphy: ethernet-phy {
> /* set phy address in board file */
> };
> };
>
But in this example, you have the same registers and the same
clocks in two nodes, which are even used by the same device driver
at the moment. It's not a big issue, but my feeling is that Antoine's
approach was actually better because it more closely reflects
the way that the hardware is built.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/5] netfilter: nft_rbtree: no need for spinlock from set destroy path
From: Eric Dumazet @ 2014-09-23 16:29 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: netfilter-devel, davem, netdev
In-Reply-To: <20140923161040.GA3609@salvia>
On Tue, 2014-09-23 at 18:10 +0200, Pablo Neira Ayuso wrote:
> Actually, I could add to nft_data a pointer in the union area, but I'm
> not very confortable with adding it for this specific case. At this
> moment we're releasing this from rcu_callback which is "hiding" the
> deletion time from the netlink interface.
>
> But I'll keep this back in my head if we later on have some pointer
> candidate to be reused in a nice way.
>
> I'll send a patch to make the rb_first()/rb_next() conversion though.
Ah, forget what I said, its actually slower to build a list by 7%, I had
an error in my test.
So the rb_first() thing is the easy and fast way.
Thanks
^ permalink raw reply
* [PATCH net] tcp: Fix TLP implementation in case receive window limits send
From: Itzcak Pechtalt @ 2014-09-23 16:28 UTC (permalink / raw)
To: netdev@vger.kernel.org
From: Itzcak Pechtalt <itzcak@flashnetworks.com>
TCP Tail loss probe (TLP) algorithm implementation has some problem.
According to paper (draft-dukkipati-tcpm-tcp-loss-probe-0 ):
In case recive window of receiver limits send of new packet in probe time than
a retransmit of last packet send should be done.
Actually, return code from tcp_write_xmit is not checked and only RTO is
scheduled,
So, it will take more time for reovery in this case than without TLP.
Signed-off-by: Itzcak Pechtalt <itzcak@flashnetworks.com>
---
net/ipv4/tcp_output.c | 2 +-
1 file changed, 1 insertions(+), 1 deletions(-)
diff -up a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
--- a/net/ipv4/tcp_output.c 2014-09-23 18:35:37.113771694 +0300
+++ b/net/ipv4/tcp_output.c 2014-09-23 18:39:58.207726420 +0300
@@ -2100,7 +2100,8 @@ void tcp_send_loss_probe(struct sock *sk
if (tcp_send_head(sk) != NULL) {
err = tcp_write_xmit(sk, mss, TCP_NAGLE_OFF, 2, GFP_ATOMIC);
- goto rearm_timer;
+ if (!err)
+ goto rearm_timer;
}
/* At most one outstanding TLP retransmission. */
^ permalink raw reply
* Re: LTP recv/recvmsg tests failing on 3.17
From: Willem de Bruijn @ 2014-09-23 16:24 UTC (permalink / raw)
To: Chuck Ebbert; +Cc: Network Development
In-Reply-To: <20140923103933.1b5fb88b@as>
> But I was also wondering why we return EAGAIN here for no data waiting,
> when we return EINVAL for the same case with a different type of data.
> There's no spec and it's not documented, so I guess the answer is "it's
> always been that way."
EAGAIN is the common response. I don't know why TCP urgent
data returns EINVAL. It is unusual enough that the relevant line
in tcp_recv_urg explicitly comments on it:
return -EINVAL; /* Yes this is right ! */
^ permalink raw reply
* Re: [PATCHv6 net-next 1/3] sunvnet: upgrade to VIO protocol version 1.6
From: David Miller @ 2014-09-23 16:24 UTC (permalink / raw)
To: david.stevens; +Cc: Raghuram.Kothakota, netdev
In-Reply-To: <541AD838.50700@oracle.com>
From: David L Stevens <david.stevens@oracle.com>
Date: Thu, 18 Sep 2014 09:03:52 -0400
> So, if this is actually too much memory, I was more inclined to reduce the ring
> size rather than either add complicating code to handle active-ring reallocation
> that would typically be run once per boot, or another alternative of adding
> module parameters to specify the buffer size TSO/GSO will need 64K to perform
> well, regardless of the device MTU.
The only reason we are having this discussion is because of how we
handle TX packets.
I think we really should directly map the SKBs in vnet_start_xmit()
instead of having these preallocate TX buffers.
The only thing to accomodate is the VNET_PACKET_SKIP, but that
shouldn't be hard at all.
And I am rather certain that an LDC map call will be cheaper than
copying the entire packet.
Then the MTU will have no material impact on per-vnet_port memory
costs, and bulk sending performance should also increase.
David I know you've worked hard on this patch set, but I'm going to
defer on this series for now. There are several implementation level
issues that are still seemingly up in the air.
I'm almost completely sold on your PMTU scheme, however if we do
direct mapping of SKBs in vnet_start_xmit() then the performance
characteristics with larger MTUs might be different.
Thanks.
^ permalink raw reply
* Re: [PATCH 2/5] netfilter: nft_rbtree: no need for spinlock from set destroy path
From: Pablo Neira Ayuso @ 2014-09-23 16:10 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netfilter-devel, davem, netdev
In-Reply-To: <1411473245.26859.188.camel@edumazet-glaptop2.roam.corp.google.com>
On Tue, Sep 23, 2014 at 04:54:05AM -0700, Eric Dumazet wrote:
> On Tue, 2014-09-23 at 13:01 +0200, Pablo Neira Ayuso wrote:
>
> > I'll send a follow up patch for nf-next to use rb_first() in that
> > patch. Thanks Eric.
>
> I did a test, and its indeed a bit faster to use rb_first(), by about 5%
>
> Real win is to be able to build a chain using rb_first()/rb_next(),
> (leaving the tree as is), then deleting the items in the chain, and
> simply reset rb_root.
>
> This only needs to reuse one pointer to store the item->next pointer.
>
> This is then about ~50% faster, because we do not constantly rebalance
> tree for every removed item.
Indeed.
struct nft_rbtree_elem {
struct rb_node node;
u16 flags;
struct nft_data key;
struct nft_data data[];
};
Actually, I could add to nft_data a pointer in the union area, but I'm
not very confortable with adding it for this specific case. At this
moment we're releasing this from rcu_callback which is "hiding" the
deletion time from the netlink interface.
But I'll keep this back in my head if we later on have some pointer
candidate to be reused in a nice way.
I'll send a patch to make the rb_first()/rb_next() conversion though.
Thanks for your comments!
^ permalink raw reply
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