* INVESTMENT ASSISTANCE
From: Thabopeter @ 2012-12-21 8:24 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 67 bytes --]
Good Day Kindly Open The Attachment File
[-- Attachment #2: INVESTMENT ASSISTANCE.doc --]
[-- Type: application/msword, Size: 48640 bytes --]
^ permalink raw reply
* INVESTMENT ASSISTANCE
From: Thabopeter @ 2012-12-21 8:25 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 67 bytes --]
Good Day Kindly Open The Attachment File
[-- Attachment #2: INVESTMENT ASSISTANCE.doc --]
[-- Type: application/msword, Size: 48640 bytes --]
^ permalink raw reply
* Re: [PATCH 4/4] net/smsc911x: Provide common clock functionality
From: Lee Jones @ 2012-12-21 9:13 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Steve Glendinning, Robert Marklund, linus.walleij, arnd, netdev,
Linus Walleij, linux-kernel, linux-arm-kernel
In-Reply-To: <20121220205113.GD14363@n2100.arm.linux.org.uk>
On Thu, 20 Dec 2012, Russell King - ARM Linux wrote:
> On Thu, Dec 20, 2012 at 08:35:14PM +0000, Lee Jones wrote:
> > On Thu, 20 Dec 2012, Russell King - ARM Linux wrote:
> >
> > > On Thu, Dec 20, 2012 at 08:12:08PM +0100, Linus Walleij wrote:
> > > > On Wed, Dec 19, 2012 at 6:19 PM, Lee Jones <lee.jones@linaro.org> wrote:
> > > >
> > > > > Some platforms provide clocks which require enabling before the
> > > > > SMSC911x chip will power on. This patch uses the new common clk
> > > > > framework to do just that. If no clock is provided, it will just
> > > > > be ignored and the driver will continue to assume that no clock
> > > > > is required for the chip to run successfully.
> > > > >
> > > > > Cc: Steve Glendinning <steve.glendinning@shawell.net>
> > > > > Cc: netdev@vger.kernel.org
> > > > > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > > >
> > > > Seems to me like it'll do the trick.
> > > > Acked-by: Linus Walleij <linus.walleij@linaro.org>
> > >
> > > This looks fairly dangerous. What about those platforms which use this
> > > driver, but don't provide a clock for it?
> > >
> > > It looks like this will result in those platforms losing their ethernet
> > > support. There's at least a bunch of the ARM evaluation boards which
> > > make use of this driver...
> >
> > Right, but nothing should regress. If no clock is provided the driver
> > moves on during the request and will refuse to prepare, enable and
> > disable there after.
> >
> > Unless I've made a mistake somewhere? If so, I'd be happy to fixup.
>
> No, but... don't use NULL for that. Use IS_ERR(pdata->clk) instead.
I'm a bit confused. I do use IS_ERR, then if there was a problem
pdata->clk is set to NULL, then we test for NULL thereafter:
> /* Request clock */
> pdata->clk = clk_get(&pdev->dev, NULL);
> if (IS_ERR(pdata->clk)) {
> netdev_warn(ndev, "couldn't get clock %d\n", PTR_ERR(pdata->clk));
> pdata->clk = NULL;
> }
Are you saying remove "pdata->clk = NULL;" and test for IS_ERR
every time?
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 4/4] net/smsc911x: Provide common clock functionality
From: Russell King - ARM Linux @ 2012-12-21 9:24 UTC (permalink / raw)
To: Lee Jones
Cc: Linus Walleij, Steve Glendinning, Robert Marklund, linus.walleij,
arnd, netdev, linux-kernel, linux-arm-kernel
In-Reply-To: <20121221091306.GO2691@gmail.com>
On Fri, Dec 21, 2012 at 09:13:06AM +0000, Lee Jones wrote:
> Are you saying remove "pdata->clk = NULL;" and test for IS_ERR
> every time?
Exactly.
^ permalink raw reply
* Re: PMTU discovery is broken on kernel 3.7.1 for UDP sockets
From: Steffen Klassert @ 2012-12-21 10:22 UTC (permalink / raw)
To: Yurij M. Plotnikov; +Cc: Ben Hutchings, netdev, Alexandra N. Kossovsky
In-Reply-To: <20121220123535.GN18940@secunet.com>
On Thu, Dec 20, 2012 at 01:35:35PM +0100, Steffen Klassert wrote:
> On Thu, Dec 20, 2012 at 03:22:13PM +0400, Yurij M. Plotnikov wrote:
> > On 12/20/12 11:34, Steffen Klassert wrote:
> > >
> > >diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
> > >index 3c9d208..1049ce0 100644
> > >--- a/net/ipv4/ip_sockglue.c
> > >+++ b/net/ipv4/ip_sockglue.c
> > >@@ -1198,7 +1198,7 @@ static int do_ip_getsockopt(struct sock *sk, int level, int optname,
> > > {
> > > struct dst_entry *dst;
> > > val = 0;
> > >- dst = sk_dst_get(sk);
> > >+ dst = sk_dst_check(sk, 0);
> > > if (dst) {
> > > val = dst_mtu(dst);
> > > dst_release(dst);
> > With this patch kernel 3.7.1 works perfect. All described problems
> > are fixed.
>
> Thanks for testing!
>
> I'm not sure if we can't use this as a fix. I think with this patch it
> could happen that we return -ENOTCONN instead of a pmtu value on a
> connected socket. Perhaps it is better to update the cached dst_entry in
> ipv4_sk_update_pmtu() when we receive the -EMSGSIZE. I'll do some
> investigation.
>
It turned out that updating the cached dst_entry in ipv4_sk_update_pmtu()
is not trivial. We need to implement proper socket locking and we need
socket release calback functions for all protocols that use
ipv4_sk_update_pmtu(), similar to tcp.
Today is my last office day for this year, so we probably have to defer
a solution to the next year.
Thanks.
^ permalink raw reply
* Re: [PATCH] xen/netfront: improve truesize tracking
From: Sander Eikelenboom @ 2012-12-21 11:21 UTC (permalink / raw)
To: Eric Dumazet
Cc: Ian Campbell, netdev@vger.kernel.org, Konrad Rzeszutek Wilk,
annie li, xen-devel@lists.xensource.com
In-Reply-To: <1356017968.21834.2859.camel@edumazet-glaptop>
Thursday, December 20, 2012, 4:39:28 PM, you wrote:
> On Thu, 2012-12-20 at 13:51 +0100, Sander Eikelenboom wrote:
>> Eric:
>> From the warn_on_once, delta should be smaller than len, but probably they should be as close together as possible.
>> When you say "accurate estimation", what would be a acceptable difference between DELTA and LEN ?
> I would use the most exact value, which is :
> skb->truesize += nr_frags * PAGE_SIZE;
> Then, if we can spot later a regression in some stacks, adapt the
> limiting parameters. I did a lot of work in GRO and TCP stack to reduce
> the memory, and further changes are possible.
> We really want to account memory, because we want to control how memory
> is used on our machines and don't let some users use more than the
> amount that was allowed to them.
Hi Eric and Ian,
I have ran some perfnet tests (although i'm not an expert, so i'm not sure i have done the right tests).
I you have better tests, please do say so ..
"current" is with netfront as is (skb->truesize += skb->data_len - RX_COPY_THRESHOLD;)
"patched" is with IanC's latest patch (skb->truesize += PAGE_SIZE * skb_shinfo(skb)->nr_frags;)
Tested between domU and dom0 (bridged) on a system with only one guest. The results don't seem to differ very much.
+ netperf -H 192.168.1.1 -t TCP_STREAM -fK -i10,5 -l 60 -I95,5 -P1 -v2
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. KBytes/sec
current 87380 16384 16384 60.00 954438.38
patched 87380 16384 16384 60.00 975236.19
+ netperf -H 192.168.1.1 -t TCP_STREAM -fK -i10,5 -l 60 -I95,5 -P1 -v2 -- -s 50
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. KBytes/sec
current 87380 2048 2048 60.00 17614.79
patched 87380 2048 2048 60.00 17207.46
+ netperf -H 192.168.1.1 -t TCP_STREAM -fK -i10,5 -l 60 -I95,5 -P1 -v2 -- -s 50 -M 1432 -m 1432
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. KBytes/sec
current 87380 2048 1432 60.00 35.28
patched 87380 2048 1432 60.00 35.28
+ netperf -H 192.168.1.1 -t TCP_STREAM -fK -i10,5 -l 60 -I95,5 -P1 -v2 -- -s 9000
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. KBytes/sec
current 87380 18000 18000 60.00 157762.45
patched 87380 18000 18000 60.00 158606.02
+ netperf -H 192.168.1.1 -t TCP_STREAM -fK -i10,5 -l 60 -I95,5 -P1 -v2 -- -s 9000 -M 1432 -m 1432
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. KBytes/sec
current 87380 18000 1432 60.00 78567.39
patched 87380 18000 1432 60.00 78329.98
+ netperf -H 192.168.1.1 -t UDP_STREAM -fK -i10,5 -l 60 -I95,5 -P1 -v2
Socket Message Elapsed Messages
Size Size Time Okay Errors Throughput
bytes bytes secs # # KBytes/sec
current 212992 65507 60.00 248771 0 265238.24
current 212992 60.00 214267 228450.01
patched 212992 65507 60.00 251188 0 267814.90
patched 212992 60.00 235101 250662.67
+ netperf -H 192.168.1.1 -t UDP_STREAM -fK -i10,5 -l 60 -I95,5 -P1 -v2 -- -s 50
Socket Message Elapsed Messages
Size Size Time Okay Errors Throughput
bytes bytes secs # # KBytes/sec
current 2048 2048 60.00 1329653 0 44321.73
current 212992 60.00 1329650 44321.62
patched 2048 2048 60.00 1363257 0 45441.68
patched 212992 60.00 1363253 45441.57
+ netperf -H 192.168.1.1 -t UDP_STREAM -fK -i10,5 -l 60 -I95,5 -P1 -v2 -- -s 50 -M 1432 -m 1432
Socket Message Elapsed Messages
Size Size Time Okay Errors Throughput
bytes bytes secs # # KBytes/sec
current 2048 1432 60.00 1516249 0 35339.61
current 212992 60.00 1516247 35339.56
patched 2048 1432 60.00 1483705 0 34581.11
patched 212992 60.00 1483701 34581.01
+ netperf -H 192.168.1.1 -t UDP_STREAM -fK -i10,5 -l 60 -I95,5 -P1 -v2 -- -s 9000
Socket Message Elapsed Messages
Size Size Time Okay Errors Throughput
bytes bytes secs # # KBytes/sec
current 18000 18000 60.00 540410 26 158322.98
current 212992 60.00 540349 158305.24
patched 18000 18000 60.00 555449 32 162728.98
patched 212992 60.00 555392 162712.28
+ netperf -H 192.168.1.1 -t UDP_STREAM -fK -i10,5 -l 60 -I95,5 -P1 -v2 -- -s 9000 -M 1432 -m 1432
Socket Message Elapsed Messages
Size Size Time Okay Errors Throughput
bytes bytes secs # # KBytes/sec
current 18000 1432 60.00 5144189 0 119896.95
current 212992 60.00 5138354 119760.96
patched 18000 1432 60.00 5104540 0 118972.85
patched 212992 60.00 5099802 118862.44
^ permalink raw reply
* Re: bonding driver - how to recognize the active slave
From: Jiri Pirko @ 2012-12-21 11:34 UTC (permalink / raw)
To: Or Gerlitz; +Cc: Eric Dumazet, Erez Shitrit, netdev@vger.kernel.org
In-Reply-To: <CAJZOPZLOj2QCWN75hAsQnmB=YiSGRhdhzf4ODhAD-QoU+Y0ZGg@mail.gmail.com>
Thu, Dec 20, 2012 at 11:21:00PM CET, or.gerlitz@gmail.com wrote:
>On Thu, Dec 20, 2012 at 11:19 PM, Eric Dumazet <erdnetdev@gmail.com> wrote:
>> cat /sys/class/net/bond0/bonding/active_slave
>
>sure, I think Erez would like to know that from within a network
>device kernel code, e.g maybe register to netdev kernel events and on
>the event of bonding fail-over identify the active slave for
>active-backup mode, etc.
I wonder why device should care of such thing? Would it behave
differently?
>
>Or.
>--
>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
* [PATCH 4/4 v2] net/smsc911x: Provide common clock functionality
From: Lee Jones @ 2012-12-21 11:41 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Linus Walleij, Steve Glendinning, Robert Marklund, linus.walleij,
arnd, netdev, linux-kernel, linux-arm-kernel
In-Reply-To: <20121221092421.GG14363@n2100.arm.linux.org.uk>
Some platforms provide clocks which require enabling before the
SMSC911x chip will power on. This patch uses the new common clk
framework to do just that. If no clock is provided, it will just
be ignored and the driver will continue to assume that no clock
is required for the chip to run successfully.
Cc: Steve Glendinning <steve.glendinning@shawell.net>
Cc: netdev@vger.kernel.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/net/ethernet/smsc/smsc911x.c | 29 ++++++++++++++++++++++++++++-
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/smsc/smsc911x.c b/drivers/net/ethernet/smsc/smsc911x.c
index e112877..afa4d62 100644
--- a/drivers/net/ethernet/smsc/smsc911x.c
+++ b/drivers/net/ethernet/smsc/smsc911x.c
@@ -33,6 +33,7 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include <linux/crc32.h>
+#include <linux/clk.h>
#include <linux/delay.h>
#include <linux/errno.h>
#include <linux/etherdevice.h>
@@ -144,6 +145,9 @@ struct smsc911x_data {
/* regulators */
struct regulator_bulk_data supplies[SMSC911X_NUM_SUPPLIES];
+
+ /* clock */
+ struct clk *clk;
};
/* Easy access to information */
@@ -369,7 +373,7 @@ out:
}
/*
- * enable resources, currently just regulators.
+ * enable regulator and clock resources.
*/
static int smsc911x_enable_resources(struct platform_device *pdev)
{
@@ -382,6 +386,13 @@ static int smsc911x_enable_resources(struct platform_device *pdev)
if (ret)
netdev_err(ndev, "failed to enable regulators %d\n",
ret);
+
+ if (IS_ERR(pdata->clk)) {
+ ret = clk_prepare_enable(pdata->clk);
+ if (ret < 0)
+ netdev_err(ndev, "failed to enable clock %d\n", ret);
+ }
+
return ret;
}
@@ -396,6 +407,10 @@ static int smsc911x_disable_resources(struct platform_device *pdev)
ret = regulator_bulk_disable(ARRAY_SIZE(pdata->supplies),
pdata->supplies);
+
+ if (IS_ERR(pdata->clk))
+ clk_disable_unprepare(pdata->clk);
+
return ret;
}
@@ -421,6 +436,12 @@ static int smsc911x_request_resources(struct platform_device *pdev)
if (ret)
netdev_err(ndev, "couldn't get regulators %d\n",
ret);
+
+ /* Request clock */
+ pdata->clk = clk_get(&pdev->dev, NULL);
+ if (IS_ERR(pdata->clk))
+ netdev_warn(ndev, "couldn't get clock %li\n", PTR_ERR(pdata->clk));
+
return ret;
}
@@ -436,6 +457,12 @@ static void smsc911x_free_resources(struct platform_device *pdev)
/* Free regulators */
regulator_bulk_free(ARRAY_SIZE(pdata->supplies),
pdata->supplies);
+
+ /* Free clock */
+ if (IS_ERR(pdata->clk)) {
+ clk_put(pdata->clk);
+ pdata->clk = NULL;
+ }
}
/* waits for MAC not busy, with timeout. Only called by smsc911x_mac_read
--
1.7.9.5
^ permalink raw reply related
* [RFC] Route lost when src address is removed.
From: Hemmo Nieminen @ 2012-12-21 12:09 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 881 bytes --]
Hi,
A route is lost to a subnet, even if it still has addresses
in that subnet.
In normal situations, it seems, a route's source address is the
same as the subnet's primary address and if it gets removed, the
route's source address is updated to be the new primary address.
If, however, the route's source address has been changed to some
other IP address than the primary address, the route is lost
when the source address is removed. This leaves us with IP
addresses in a subnet but no route to that subnet.
I encountered this and was not able to figure out whether this
behaviour is intentional or not? I would sort of expect the
route the be updated to have e.g. the primary address as the new
source address but perhaps not in all cases... What do you
think?
Attached below an example run that should also include all the
information needed to reproduce this.
--
Hemmo
[-- Attachment #2: route.log --]
[-- Type: text/plain, Size: 2209 bytes --]
[root@fcku ~]# ip a s eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:23:54:20:73:3e brd ff:ff:ff:ff:ff:ff
inet 192.168.1.105/24 brd 192.168.1.255 scope global eth0
inet6 fe80::223:54ff:fe20:733e/64 scope link
valid_lft forever preferred_lft forever
[root@fcku ~]# ip a a 1.1.1.1/24 dev eth0
[root@fcku ~]# ip a a 1.1.1.2/24 dev eth0
[root@fcku ~]# ip a a 1.1.1.3/24 dev eth0
[root@fcku ~]# ip a s eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:23:54:20:73:3e brd ff:ff:ff:ff:ff:ff
inet 192.168.1.105/24 brd 192.168.1.255 scope global eth0
inet 1.1.1.1/24 scope global eth0
inet 1.1.1.2/24 scope global secondary eth0
inet 1.1.1.3/24 scope global secondary eth0
inet6 fe80::223:54ff:fe20:733e/64 scope link
valid_lft forever preferred_lft forever
[root@fcku ~]# ip r s
default via 192.168.1.1 dev eth0 metric 202
1.1.1.0/24 dev eth0 proto kernel scope link src 1.1.1.1
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.105 metric 202
[root@fcku ~]# ip r replace 1.1.1.0/24 dev eth0 proto kernel scope link src 1.1.1.2
[root@fcku ~]# ip r s
default via 192.168.1.1 dev eth0 metric 202
1.1.1.0/24 dev eth0 proto kernel scope link src 1.1.1.2
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.105 metric 202
[root@fcku ~]# ip a d 1.1.1.2/24 dev eth0
[root@fcku ~]# ip a s eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:23:54:20:73:3e brd ff:ff:ff:ff:ff:ff
inet 192.168.1.105/24 brd 192.168.1.255 scope global eth0
inet 1.1.1.1/24 scope global eth0
inet 1.1.1.3/24 scope global secondary eth0
inet6 fe80::223:54ff:fe20:733e/64 scope link
valid_lft forever preferred_lft forever
[root@fcku ~]# ip r s
default via 192.168.1.1 dev eth0 metric 202
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.105 metric 202
[root@fcku ~]# uname -a
Linux fcku 3.6.10-1-ARCH #1 SMP PREEMPT Tue Dec 11 09:40:17 CET 2012 x86_64 GNU/Linux
[root@fcku ~]# ip -V
ip utility, iproute2-ss121001
[root@fcku ~]#
^ permalink raw reply
* perm_addr get
From: Jiri Pirko @ 2012-12-21 13:01 UTC (permalink / raw)
To: netdev; +Cc: bhutchings
Hi all.
>From what I understand dev->perm_addr is set only in case the hw has
permanent hw address somewhere written (for example EPROM).
So when I query device which does not have perm_addr set I get:
testt1:~$ ethtool -P team0
Permanent address: 00:00:00:00:00:00
Is this the correct behaviour? Wouldn't it be more correct if
ethtool_get_perm_addr() fails with -ENOENT for something like that?
Thanks.
Jiri
^ permalink raw reply
* Re: [PATCH] pkt_sched: act_xt support new Xtables interface
From: Jamal Hadi Salim @ 2012-12-21 13:03 UTC (permalink / raw)
To: Yury Stankevich
Cc: Hasan Chowdhury, Stephen Hemminger, Jan Engelhardt,
netdev@vger.kernel.org, pablo, netfilter-devel
In-Reply-To: <50D327CD.3050904@gmail.com>
On 12-12-20 09:59 AM, Yury Stankevich wrote:
> interesting,
>
> #tc -s filter show dev usb0 parent ffff:
Given you are adding this on ingress - the settings you have will
happen before pre-routing hook.
If you did things at egress - the setting will take effect after
post-routing. So take a closer look at those details they look
like your source of issues..
cheers,
jamal
^ permalink raw reply
* Re: perm_addr get
From: Ben Hutchings @ 2012-12-21 13:09 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev
In-Reply-To: <20121221130127.GB2040@minipsycho.orion>
On Fri, 2012-12-21 at 14:01 +0100, Jiri Pirko wrote:
> Hi all.
>
> From what I understand dev->perm_addr is set only in case the hw has
> permanent hw address somewhere written (for example EPROM).
>
> So when I query device which does not have perm_addr set I get:
>
> testt1:~$ ethtool -P team0
> Permanent address: 00:00:00:00:00:00
>
> Is this the correct behaviour? Wouldn't it be more correct if
> ethtool_get_perm_addr() fails with -ENOENT for something like that?
I don't think we should change the implementation now, as someone might
depend on it. It's trivial to distinguish this not-a-permanent-address
case. However the ethtool command output could be improved.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] pkt_sched: act_xt support new Xtables interface
From: Yury Stankevich @ 2012-12-21 13:13 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Hasan Chowdhury, Stephen Hemminger, Jan Engelhardt,
netdev@vger.kernel.org, pablo, netfilter-devel
In-Reply-To: <50D45E25.7050703@mojatatu.com>
21.12.2012 17:03, Jamal Hadi Salim пишет:
> On 12-12-20 09:59 AM, Yury Stankevich wrote:
>> interesting,
>>
>> #tc -s filter show dev usb0 parent ffff:
>
>
> Given you are adding this on ingress - the settings you have will
> happen before pre-routing hook.
> If you did things at egress - the setting will take effect after
> post-routing. So take a closer look at those details they look
> like your source of issues..
sure,
i use it ingress,
so, i need to use tc xt action
to get mark on the packet, before filter on ifb will run.
prerouting rule, in turn, used to test if mark was actually restored.
in practice:
1. prerouting rule - is not fired. so, no packets with mark was seen.
2. filter on ifb - do not pass traffic to flow configured.
looks like `CONNMARK --restore` is not really called.
--
Linux registered user #402966 // pub 1024D/E99AF373 <pgp.mit.edu>
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" 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: perm_addr get
From: Jiri Pirko @ 2012-12-21 13:25 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev
In-Reply-To: <1356095395.7055.34.camel@deadeye.wl.decadent.org.uk>
Fri, Dec 21, 2012 at 02:09:55PM CET, bhutchings@solarflare.com wrote:
>On Fri, 2012-12-21 at 14:01 +0100, Jiri Pirko wrote:
>> Hi all.
>>
>> From what I understand dev->perm_addr is set only in case the hw has
>> permanent hw address somewhere written (for example EPROM).
>>
>> So when I query device which does not have perm_addr set I get:
>>
>> testt1:~$ ethtool -P team0
>> Permanent address: 00:00:00:00:00:00
>>
>> Is this the correct behaviour? Wouldn't it be more correct if
>> ethtool_get_perm_addr() fails with -ENOENT for something like that?
>
>I don't think we should change the implementation now, as someone might
>depend on it. It's trivial to distinguish this not-a-permanent-address
>case. However the ethtool command output could be improved.
Well, not change it even if it is not correct? And by "trivial to distinguish"
you mean 00:00:00:00:00:00 ~ device has no permanent address?
But in some cases (like vxge, mac80211) it's possible to see 00:00:00:00:00:00
by ethtool -P even though the device has permanent address (set later on, after
register_netdev call).
I think that ethtool_get_perm_addr should return:
-ENOENT if dev has no perm addr
-EAGAIN if dev perm addr hasn't been obtained yet
0 (and addr) in other cases
And how exactly should be the ethtool output improved?
Thanks
Jiri
>
>Ben.
>
>--
>Ben Hutchings, Staff Engineer, Solarflare
>Not speaking for my employer; that's the marketing department's job.
>They asked us to note that Solarflare product names are trademarked.
>
^ permalink raw reply
* Re: [PATCH] pkt_sched: act_xt support new Xtables interface
From: Jamal Hadi Salim @ 2012-12-21 13:50 UTC (permalink / raw)
To: Yury Stankevich
Cc: Hasan Chowdhury, Stephen Hemminger, Jan Engelhardt,
netdev@vger.kernel.org, pablo, netfilter-devel
In-Reply-To: <50D46060.2070308@gmail.com>
On 12-12-21 08:13 AM, Yury Stankevich wrote:
> sure,
> i use it ingress,
> so, i need to use tc xt action
> to get mark on the packet, before filter on ifb will run.
Ok. So does ifb see it?
> prerouting rule, in turn, used to test if mark was actually restored.
No experience with connmark, but - in order to restore something has
to store it, correct?
> in practice:
> 1. prerouting rule - is not fired. so, no packets with mark was seen.
> 2. filter on ifb - do not pass traffic to flow configured.
> looks like `CONNMARK --restore` is not really called.
>
My suspicion is that it is not set to begin with...
cheers,
jamal
^ permalink raw reply
* Re: [PATCH] pkt_sched: act_xt support new Xtables interface
From: Yury Stankevich @ 2012-12-21 14:14 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Hasan Chowdhury, Stephen Hemminger, Jan Engelhardt,
netdev@vger.kernel.org, pablo, netfilter-devel
In-Reply-To: <50D46928.9070809@mojatatu.com>
well.
let me describe whole picture i want to achieve
1. use htb/sfq on ingress.
i got a traffic, and use few u32 filters to direct it to 3 flows,
priority, interactive, and bulk.
as http normally pass to interactive flow, i want to move long donwloads
to the bulk one.
how i trying to find these downloads:
iptables -t mangle -A POSTROUTING -p tcp --dport 80 -m connmark --mark 0
-m connbytes --connbytes 204800: --connbytes-dir both --connbytes-mode
bytes -j CONNMARK --set-mark 0xa
so, http connection where more than 200K downloaded, must got a
connection mark.
since ingress traffic hits qos before netfilter,
i use xt action, to copy connection mark, to a packet.
(action xt -j CONNMARK --restore-mark )
from this moment, i expect packet must have a restored mark
after this, i can use high priority tc filter .. handle 0xa fw flowid 1:102
to direct packet with mark 0xa to 1:102 flow (bulk).
now about a problem.
1. i run http download, once i get 200K - i can see that rule in
POSTROUTING is triggered and connection mark is installed (iptables -L
-n -v mangle -- can show number of packets matched by rule)
2. i see to tc stats for my flows, and i see, that packets still going
to interactive flow, not bulk as i expect.
3. from tc -s filter show dev usb0 parent ffff:
filter protocol ip pref 49152 u32
filter protocol ip pref 49152 u32 fh 800: ht divisor 1
filter protocol ip pref 49152 u32 fh 800::800 order 2048 key ht 800 bkt
0 terminal flowid ??? (rule hit 707 success 707)
match 00000000/00000000 at 0 (success 707 )
action order 1: tablename: mangle hook: NF_IP_PRE_ROUTING
target CONNMARK restore
index 5 ref 1 bind 1 installed 394 sec used 11 sec
Action statistics:
Sent 783783 bytes 707 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
action order 2: mirred (Egress Redirect to device ifb0) stolen
index 5 ref 1 bind 1 installed 394 sec used 11 sec
Action statistics:
Sent 783783 bytes 707 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
i can see that packets must reach xt action.
4. lets try to check packets mark with iptables,
if mark restored by xt action - i must be able to match it in prerouting
rule.
iptables -t mangle -A PREROUTING -m mark --mark 0xa -j NFLOG --nflog-group 1
but this rule not macthesd - so, no mark is restored by xt action.
maybe im completely wrong here, and such mode can't work for some reason ?
21.12.2012 17:50, Jamal Hadi Salim пишет:
> On 12-12-21 08:13 AM, Yury Stankevich wrote:
>
>> sure,
>> i use it ingress,
>> so, i need to use tc xt action
>> to get mark on the packet, before filter on ifb will run.
>
> Ok. So does ifb see it?
>
>> prerouting rule, in turn, used to test if mark was actually restored.
>
> No experience with connmark, but - in order to restore something has
> to store it, correct?
>
>> in practice:
>> 1. prerouting rule - is not fired. so, no packets with mark was seen.
>> 2. filter on ifb - do not pass traffic to flow configured.
>> looks like `CONNMARK --restore` is not really called.
>>
>
> My suspicion is that it is not set to begin with...
>
> cheers,
> jamal
>
--
Linux registered user #402966 // pub 1024D/E99AF373 <pgp.mit.edu>
^ permalink raw reply
* Re: [PATCH] pkt_sched: act_xt support new Xtables interface
From: Jan Engelhardt @ 2012-12-21 14:35 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Yury Stankevich, Hasan Chowdhury, Stephen Hemminger,
netdev@vger.kernel.org, pablo, netfilter-devel
In-Reply-To: <50D46928.9070809@mojatatu.com>
On Friday 2012-12-21 14:50, Jamal Hadi Salim wrote:
> On 12-12-21 08:13 AM, Yury Stankevich wrote:
>> i use it ingress,
>> so, i need to use tc xt action
>> to get mark on the packet, before filter on ifb will run.
>> prerouting rule, in turn, used to test if mark was actually restored.
>
> No experience with connmark, but - in order to restore something has
> to store it, correct?
The bigger problem here, if I see __netif_receive_skb right, is that
when ingress rules run, skb->nfct is still unset, thereby the
CONNMARK action is a no-op.
^ permalink raw reply
* Re: perm_addr get
From: Ben Hutchings @ 2012-12-21 14:40 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev
In-Reply-To: <20121221132500.GC2040@minipsycho.orion>
On Fri, 2012-12-21 at 14:25 +0100, Jiri Pirko wrote:
> Fri, Dec 21, 2012 at 02:09:55PM CET, bhutchings@solarflare.com wrote:
> >On Fri, 2012-12-21 at 14:01 +0100, Jiri Pirko wrote:
> >> Hi all.
> >>
> >> From what I understand dev->perm_addr is set only in case the hw has
> >> permanent hw address somewhere written (for example EPROM).
> >>
> >> So when I query device which does not have perm_addr set I get:
> >>
> >> testt1:~$ ethtool -P team0
> >> Permanent address: 00:00:00:00:00:00
> >>
> >> Is this the correct behaviour? Wouldn't it be more correct if
> >> ethtool_get_perm_addr() fails with -ENOENT for something like that?
> >
> >I don't think we should change the implementation now, as someone might
> >depend on it. It's trivial to distinguish this not-a-permanent-address
> >case. However the ethtool command output could be improved.
>
> Well, not change it even if it is not correct? And by "trivial to distinguish"
> you mean 00:00:00:00:00:00 ~ device has no permanent address?
> But in some cases (like vxge, mac80211) it's possible to see 00:00:00:00:00:00
> by ethtool -P even though the device has permanent address (set later on, after
> register_netdev call).
Oh well, those are just driver bugs that should be fixed.
> I think that ethtool_get_perm_addr should return:
> -ENOENT if dev has no perm addr
> -EAGAIN if dev perm addr hasn't been obtained yet
> 0 (and addr) in other cases
>
> And how exactly should be the ethtool output improved?
Print something like 'No permanent address assigned' when the address is
all-zeroes.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] pkt_sched: act_xt support new Xtables interface
From: Eric Dumazet @ 2012-12-21 15:45 UTC (permalink / raw)
To: Jan Engelhardt
Cc: Jamal Hadi Salim, Yury Stankevich, Hasan Chowdhury,
Stephen Hemminger, netdev@vger.kernel.org, pablo, netfilter-devel
In-Reply-To: <alpine.LNX.2.01.1212211533360.957@nerf07.vanv.qr>
On Fri, 2012-12-21 at 15:35 +0100, Jan Engelhardt wrote:
>
> The bigger problem here, if I see __netif_receive_skb right, is that
> when ingress rules run, skb->nfct is still unset, thereby the
> CONNMARK action is a no-op.
Right, ingress is performed before IP/netfilter stack.
This reminds me this might be the reason we have
skb_reset_transport_header(skb);
in __netif_receive_skb(), while its not very logical.
(Yes, sorry for being off topic, but I am referring to
http://www.spinics.net/lists/netdev/msg214662.html )
^ permalink raw reply
* Re: TUN problems (regression?)
From: Paul Moore @ 2012-12-21 16:27 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Jason Wang, netdev
In-Reply-To: <1356046697.21834.3606.camel@edumazet-glaptop>
On Thursday, December 20, 2012 03:38:17 PM Eric Dumazet wrote:
> On Thu, 2012-12-20 at 18:16 -0500, Paul Moore wrote:
> > [CC'ing netdev in case this is a known problem I just missed ...]
> >
> > Hi Jason,
> >
> > I started doing some more testing with the multiqueue TUN changes and I
> > ran
> > into a problem when running tunctl: running it once w/o arguments works as
> > expected, but running it a second time results in failure and a
> > kmem_cache_sanity_check() failure. The problem appears to be very
> > repeatable on my test VM and happens independent of the LSM/SELinux fixup
> > patches.
> >
> > Have you seen this before?
>
> Obviously code in tun_flow_init() is wrong...
>
> static int tun_flow_init(struct tun_struct *tun)
> {
> int i;
>
> tun->flow_cache = kmem_cache_create("tun_flow_cache",
> sizeof(struct tun_flow_entry),
> 0, 0, NULL);
> if (!tun->flow_cache)
> return -ENOMEM;
> ...
> }
>
>
> I have no idea why we would need a kmem_cache per tun_struct,
> and why we even need a kmem_cache.
>
>
> I would try following patch :
>
> drivers/net/tun.c | 24 +++---------------------
> 1 file changed, 3 insertions(+), 21 deletions(-)
Thanks, that solved my problem. Also, in case you were still curious, I was
using SLUB.
--
paul moore
security and virtualization @ redhat
^ permalink raw reply
* IPv6 over Firewire
From: Stephan Gatzka @ 2012-12-21 17:03 UTC (permalink / raw)
To: netdev, linux1394-devel
Hi!
I'm currently implementing IPv6 over firewire.
To make the address mapping to the firewire link layer RFC3146 mandates
to use neighbor discovery with a certain format of the source/target
link-layer address option.
While it is not too complicated to build that up, I'm wondering how I
can reserve enough memory in the corresponding skb.
One possibility is to introduce some option padding in
ndisc_addr_option_pad() but I think that's somehow weird.
The second option I see is to set needed_tailroom in struct netdevice
for firewire net devices. That's the way I would go for.
Because I'm not really familiar with the whole network infrastructure in
Linux, a confirmation for the way to go would be nice.
Regards,
Stephan
^ permalink raw reply
* [PATCH] tuntap: dont use a private kmem_cache
From: Eric Dumazet @ 2012-12-21 17:17 UTC (permalink / raw)
To: Paul Moore, David Miller; +Cc: Jason Wang, netdev, Stephen Hemminger
In-Reply-To: <2090364.S7KStA6R4d@sifl>
From: Eric Dumazet <edumazet@google.com>
Commit 96442e42429 (tuntap: choose the txq based on rxq)
added a per tun_struct kmem_cache.
As soon as several tun_struct are used, we get an error
because two caches cannot have same name.
Use the default kmalloc()/kfree_rcu(), as it reduce code
size and doesn't have performance impact here.
Reported-by: Paul Moore <pmoore@redhat.com>
Tested-by: Paul Moore <pmoore@redhat.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Stephen Hemminger <shemminger@vyatta.com>
Acked-by: Jason Wang <jasowang@redhat.com>
---
drivers/net/tun.c | 24 +++---------------------
1 file changed, 3 insertions(+), 21 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 504f7f1..fbd106e 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -180,7 +180,6 @@ struct tun_struct {
int debug;
#endif
spinlock_t lock;
- struct kmem_cache *flow_cache;
struct hlist_head flows[TUN_NUM_FLOW_ENTRIES];
struct timer_list flow_gc_timer;
unsigned long ageing_time;
@@ -209,8 +208,8 @@ static struct tun_flow_entry *tun_flow_create(struct tun_struct *tun,
struct hlist_head *head,
u32 rxhash, u16 queue_index)
{
- struct tun_flow_entry *e = kmem_cache_alloc(tun->flow_cache,
- GFP_ATOMIC);
+ struct tun_flow_entry *e = kmalloc(sizeof(*e), GFP_ATOMIC);
+
if (e) {
tun_debug(KERN_INFO, tun, "create flow: hash %u index %u\n",
rxhash, queue_index);
@@ -223,19 +222,12 @@ static struct tun_flow_entry *tun_flow_create(struct tun_struct *tun,
return e;
}
-static void tun_flow_free(struct rcu_head *head)
-{
- struct tun_flow_entry *e
- = container_of(head, struct tun_flow_entry, rcu);
- kmem_cache_free(e->tun->flow_cache, e);
-}
-
static void tun_flow_delete(struct tun_struct *tun, struct tun_flow_entry *e)
{
tun_debug(KERN_INFO, tun, "delete flow: hash %u index %u\n",
e->rxhash, e->queue_index);
hlist_del_rcu(&e->hash_link);
- call_rcu(&e->rcu, tun_flow_free);
+ kfree_rcu(e, rcu);
}
static void tun_flow_flush(struct tun_struct *tun)
@@ -833,12 +825,6 @@ static int tun_flow_init(struct tun_struct *tun)
{
int i;
- tun->flow_cache = kmem_cache_create("tun_flow_cache",
- sizeof(struct tun_flow_entry), 0, 0,
- NULL);
- if (!tun->flow_cache)
- return -ENOMEM;
-
for (i = 0; i < TUN_NUM_FLOW_ENTRIES; i++)
INIT_HLIST_HEAD(&tun->flows[i]);
@@ -854,10 +840,6 @@ static void tun_flow_uninit(struct tun_struct *tun)
{
del_timer_sync(&tun->flow_gc_timer);
tun_flow_flush(tun);
-
- /* Wait for completion of call_rcu()'s */
- rcu_barrier();
- kmem_cache_destroy(tun->flow_cache);
}
/* Initialize net device. */
^ permalink raw reply related
* [PATCH] ipv4: arp: fix a lockdep splat in arp_solicit()
From: Eric Dumazet @ 2012-12-21 17:32 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Yan Burman, Stephen Hemminger
From: Eric Dumazet <edumazet@google.com>
Yan Burman reported following lockdep warning :
=============================================
[ INFO: possible recursive locking detected ]
3.7.0+ #24 Not tainted
---------------------------------------------
swapper/1/0 is trying to acquire lock:
(&n->lock){++--..}, at: [<ffffffff8139f56e>] __neigh_event_send
+0x2e/0x2f0
but task is already holding lock:
(&n->lock){++--..}, at: [<ffffffff813f63f4>] arp_solicit+0x1d4/0x280
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&n->lock);
lock(&n->lock);
*** DEADLOCK ***
May be due to missing lock nesting notation
4 locks held by swapper/1/0:
#0: (((&n->timer))){+.-...}, at: [<ffffffff8104b350>]
call_timer_fn+0x0/0x1c0
#1: (&n->lock){++--..}, at: [<ffffffff813f63f4>] arp_solicit
+0x1d4/0x280
#2: (rcu_read_lock_bh){.+....}, at: [<ffffffff81395400>]
dev_queue_xmit+0x0/0x5d0
#3: (rcu_read_lock_bh){.+....}, at: [<ffffffff813cb41e>]
ip_finish_output+0x13e/0x640
stack backtrace:
Pid: 0, comm: swapper/1 Not tainted 3.7.0+ #24
Call Trace:
<IRQ> [<ffffffff8108c7ac>] validate_chain+0xdcc/0x11f0
[<ffffffff8108d570>] ? __lock_acquire+0x440/0xc30
[<ffffffff81120565>] ? kmem_cache_free+0xe5/0x1c0
[<ffffffff8108d570>] __lock_acquire+0x440/0xc30
[<ffffffff813c3570>] ? inet_getpeer+0x40/0x600
[<ffffffff8108d570>] ? __lock_acquire+0x440/0xc30
[<ffffffff8139f56e>] ? __neigh_event_send+0x2e/0x2f0
[<ffffffff8108ddf5>] lock_acquire+0x95/0x140
[<ffffffff8139f56e>] ? __neigh_event_send+0x2e/0x2f0
[<ffffffff8108d570>] ? __lock_acquire+0x440/0xc30
[<ffffffff81448d4b>] _raw_write_lock_bh+0x3b/0x50
[<ffffffff8139f56e>] ? __neigh_event_send+0x2e/0x2f0
[<ffffffff8139f56e>] __neigh_event_send+0x2e/0x2f0
[<ffffffff8139f99b>] neigh_resolve_output+0x16b/0x270
[<ffffffff813cb62d>] ip_finish_output+0x34d/0x640
[<ffffffff813cb41e>] ? ip_finish_output+0x13e/0x640
[<ffffffffa046f146>] ? vxlan_xmit+0x556/0xbec [vxlan]
[<ffffffff813cb9a0>] ip_output+0x80/0xf0
[<ffffffff813ca368>] ip_local_out+0x28/0x80
[<ffffffffa046f25a>] vxlan_xmit+0x66a/0xbec [vxlan]
[<ffffffffa046f146>] ? vxlan_xmit+0x556/0xbec [vxlan]
[<ffffffff81394a50>] ? skb_gso_segment+0x2b0/0x2b0
[<ffffffff81449355>] ? _raw_spin_unlock_irqrestore+0x65/0x80
[<ffffffff81394c57>] ? dev_queue_xmit_nit+0x207/0x270
[<ffffffff813950c8>] dev_hard_start_xmit+0x298/0x5d0
[<ffffffff813956f3>] dev_queue_xmit+0x2f3/0x5d0
[<ffffffff81395400>] ? dev_hard_start_xmit+0x5d0/0x5d0
[<ffffffff813f5788>] arp_xmit+0x58/0x60
[<ffffffff813f59db>] arp_send+0x3b/0x40
[<ffffffff813f6424>] arp_solicit+0x204/0x280
[<ffffffff813a1a70>] ? neigh_add+0x310/0x310
[<ffffffff8139f515>] neigh_probe+0x45/0x70
[<ffffffff813a1c10>] neigh_timer_handler+0x1a0/0x2a0
[<ffffffff8104b3cf>] call_timer_fn+0x7f/0x1c0
[<ffffffff8104b350>] ? detach_if_pending+0x120/0x120
[<ffffffff8104b748>] run_timer_softirq+0x238/0x2b0
[<ffffffff813a1a70>] ? neigh_add+0x310/0x310
[<ffffffff81043e51>] __do_softirq+0x101/0x280
[<ffffffff814518cc>] call_softirq+0x1c/0x30
[<ffffffff81003b65>] do_softirq+0x85/0xc0
[<ffffffff81043a7e>] irq_exit+0x9e/0xc0
[<ffffffff810264f8>] smp_apic_timer_interrupt+0x68/0xa0
[<ffffffff8145122f>] apic_timer_interrupt+0x6f/0x80
<EOI> [<ffffffff8100a054>] ? mwait_idle+0xa4/0x1c0
[<ffffffff8100a04b>] ? mwait_idle+0x9b/0x1c0
[<ffffffff8100a6a9>] cpu_idle+0x89/0xe0
[<ffffffff81441127>] start_secondary+0x1b2/0x1b6
Bug is from arp_solicit(), releasing the neigh lock after arp_send()
In case of vxlan, we eventually need to write lock a neigh lock later.
Its a false positive, but we can get rid of it without lockdep
annotations.
We can instead use neigh_ha_snapshot() helper.
Reported-by: Yan Burman <yanb@mellanox.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Stephen Hemminger <shemminger@vyatta.com>
---
net/ipv4/arp.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index ce6fbdf..1169ed4 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -321,7 +321,7 @@ static void arp_error_report(struct neighbour *neigh, struct sk_buff *skb)
static void arp_solicit(struct neighbour *neigh, struct sk_buff *skb)
{
__be32 saddr = 0;
- u8 *dst_ha = NULL;
+ u8 dst_ha[MAX_ADDR_LEN];
struct net_device *dev = neigh->dev;
__be32 target = *(__be32 *)neigh->primary_key;
int probes = atomic_read(&neigh->probes);
@@ -363,9 +363,9 @@ static void arp_solicit(struct neighbour *neigh, struct sk_buff *skb)
if (probes < 0) {
if (!(neigh->nud_state & NUD_VALID))
pr_debug("trying to ucast probe in NUD_INVALID\n");
- dst_ha = neigh->ha;
- read_lock_bh(&neigh->lock);
+ neigh_ha_snapshot(dst_ha, neigh, dev);
} else {
+ memset(dst_ha, 0, dev->addr_len);
probes -= neigh->parms->app_probes;
if (probes < 0) {
#ifdef CONFIG_ARPD
@@ -377,8 +377,6 @@ static void arp_solicit(struct neighbour *neigh, struct sk_buff *skb)
arp_send(ARPOP_REQUEST, ETH_P_ARP, target, dev, saddr,
dst_ha, dev->dev_addr, NULL);
- if (dst_ha)
- read_unlock_bh(&neigh->lock);
}
static int arp_ignore(struct in_device *in_dev, __be32 sip, __be32 tip)
^ permalink raw reply related
* Re: IPv6 over Firewire
From: YOSHIFUJI Hideaki @ 2012-12-21 17:53 UTC (permalink / raw)
To: stephan.gatzka; +Cc: netdev, linux1394-devel, YOSHIFUJI Hideaki
In-Reply-To: <50D49659.1000101@gmail.com>
(2012年12月22日 02:03), Stephan Gatzka wrote:
> To make the address mapping to the firewire link layer RFC3146 mandates to use neighbor discovery with a certain format of the source/target link-layer address option.
>
> While it is not too complicated to build that up, I'm wondering how I can reserve enough memory in the corresponding skb.
>
> One possibility is to introduce some option padding in ndisc_addr_option_pad() but I think that's somehow weird.
>
> The second option I see is to set needed_tailroom in struct netdevice for firewire net devices. That's the way I would go for.
>
> Because I'm not really familiar with the whole network infrastructure in Linux, a confirmation for the way to go would be nice.
If you are talking about how to build NS/NA/RS/Redirect messages, you
can just use ndisc_opt_addr_space() and ndisc_fill_addr_option() here.
--yoshfuji
^ permalink raw reply
* [PATCH 0/2] Re-submit RDS patches
From: Mike Marciniszyn @ 2012-12-21 18:01 UTC (permalink / raw)
To: venkat.x.venkatsubra-QHcLZuEGTsvQT0dZR+AlfA
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, roland-DgEjT+Ai2ygdnm+yROfE0A,
rds-devel-N0ozoZBvEnrZJqsBc5GL+g, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
netdev-u79uwXL29TY76Z2rM5mHXA
These fixes were originally submitted in
https://oss.oracle.com/pipermail/rds-devel/2012-April/thread.html.
The first patch fixes a DOA issue with RDS on qib and should
be a stable patch as well.
The second suppresses a warning message that is misleading when
a version has been correctly determined.
These two patches were originally acked by the upstream maintainer
and never merged.
---
Mike Marciniszyn (2):
IB/rds: Correct ib_api use with gs_dma_address/sg_dma_len
IB/rds: suppress incompatible protocol when version is known
net/rds/ib_cm.c | 11 +++++------
net/rds/ib_recv.c | 9 ++++++---
2 files changed, 11 insertions(+), 9 deletions(-)
--
Thanks!
Mike Marciniszyn
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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
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