* Re: [PATCH net V4 2/2] igb: offer a PTP Hardware Clock instead of the timecompare method
From: chetan loke @ 2012-03-26 19:32 UTC (permalink / raw)
To: Keller, Jacob E
Cc: e1000-devel@lists.sourceforge.net, netdev@vger.kernel.org,
Ronciak, John, john.stultz@linaro.org, tglx@linutronix.de
In-Reply-To: <02874ECE860811409154E81DA85FBB580DC04D@ORSMSX105.amr.corp.intel.com>
On Mon, Mar 26, 2012 at 2:56 PM, Keller, Jacob E
<jacob.e.keller@intel.com> wrote:
> I am curious how you see a kernel thread resolving the Tx/Rx issue? or is the
> kernel thread being used by gettime? I don't believe we can wait for the Tx/Rx
tx, rx path and kernel thread will use seq_lock_isave(tmreg_lock).
A new 'u64 cached_ns' will be introduced.
tx and rx path can update 'cached_ns' when they read the NIC counter.
A kernel-thread should be scheduled periodically, will read the NIC
counter and update cached_ns. It will use a _trylock variant. If the
lock fails then its a hint that 'cached_ns' is getting updated
somewhere, so just refresh the timer. Periodic update is needed to
handle idle/bursty link conditions because the Rx/tx path may not run
that often.
gettime uses read_seq_lock and reads 'cached_ns'. I mean we could also
do a atomic_read(?).
> path, because if we take too long the software sees it as a dropped timestamp.
What code-path is this?
> How would we only allow one app? Any app with permissions could call the ioctls.
> I do agree that having too many ioctls is a problem. Even in cases where PTP is
We don't. So this is what I'm thinking. Ideally speaking only 1 app
should be adjusting the host-clock and 1 app per NIC if you adjust
NIC's clock. Ignore the host-clock app. Once you enforce the
rate-limit, driver will return -EBUSY if you exceed it. Too many
EBUSYs will provide a hint on user-side.
Chetan
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* [PATCHv2 1/2] wimax: i2400m - prevent a possible kernel bug due to missing fw_name string
From: Phil Sutter @ 2012-03-26 19:01 UTC (permalink / raw)
To: David Miller; +Cc: netdev, inaky.perez-gonzalez, Ben Hutchings
In-Reply-To: <1332773830.3500.88.camel@deadeye>
This happened on a machine with a custom hotplug script calling nameif,
probably due to slow firmware loading. At the time nameif uses ethtool
to gather interface information, i2400m->fw_name is zero and so a null
pointer dereference occurs from within i2400m_get_drvinfo().
Signed-off-by: Phil Sutter <phil.sutter@viprinet.com>
---
drivers/net/wimax/i2400m/netdev.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wimax/i2400m/netdev.c b/drivers/net/wimax/i2400m/netdev.c
index 63e4b70..1d76ae8 100644
--- a/drivers/net/wimax/i2400m/netdev.c
+++ b/drivers/net/wimax/i2400m/netdev.c
@@ -597,7 +597,8 @@ static void i2400m_get_drvinfo(struct net_device *net_dev,
struct i2400m *i2400m = net_dev_to_i2400m(net_dev);
strncpy(info->driver, KBUILD_MODNAME, sizeof(info->driver) - 1);
- strncpy(info->fw_version, i2400m->fw_name, sizeof(info->fw_version) - 1);
+ strncpy(info->fw_version,
+ i2400m->fw_name ? : "", sizeof(info->fw_version) - 1);
if (net_dev->dev.parent)
strncpy(info->bus_info, dev_name(net_dev->dev.parent),
sizeof(info->bus_info) - 1);
--
1.7.3.4
^ permalink raw reply related
* [PATCHv2 2/2] wimax: i2400m-usb - use a private struct ethtool_ops
From: Phil Sutter @ 2012-03-26 19:01 UTC (permalink / raw)
To: David Miller; +Cc: netdev, inaky.perez-gonzalez, Ben Hutchings
In-Reply-To: <1332788491-21530-1-git-send-email-phil.sutter@viprinet.com>
This way the USB variant of the driver uses usb_make_path in order to
provide bus-info compatible to other USB drivers (like e.g. asix.c).
Signed-off-by: Phil Sutter <phil.sutter@viprinet.com>
---
drivers/net/wimax/i2400m/usb.c | 18 ++++++++++++++++++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wimax/i2400m/usb.c b/drivers/net/wimax/i2400m/usb.c
index 2c1b8b6..29b1e03 100644
--- a/drivers/net/wimax/i2400m/usb.c
+++ b/drivers/net/wimax/i2400m/usb.c
@@ -339,6 +339,23 @@ int i2400mu_bus_reset(struct i2400m *i2400m, enum i2400m_reset_type rt)
return result;
}
+static void i2400mu_get_drvinfo(struct net_device *net_dev,
+ struct ethtool_drvinfo *info)
+{
+ struct i2400m *i2400m = net_dev_to_i2400m(net_dev);
+ struct i2400mu *i2400mu = container_of(i2400m, struct i2400mu, i2400m);
+ struct usb_device *udev = i2400mu->usb_dev;
+
+ strncpy(info->driver, KBUILD_MODNAME, sizeof(info->driver) - 1);
+ strncpy(info->fw_version,
+ i2400m->fw_name ? : "", sizeof(info->fw_version) - 1);
+ usb_make_path(udev, info->bus_info, sizeof(info->bus_info));
+}
+
+static const struct ethtool_ops i2400mu_ethtool_ops = {
+ .get_drvinfo = i2400mu_get_drvinfo,
+ .get_link = ethtool_op_get_link,
+};
static
void i2400mu_netdev_setup(struct net_device *net_dev)
@@ -347,6 +364,7 @@ void i2400mu_netdev_setup(struct net_device *net_dev)
struct i2400mu *i2400mu = container_of(i2400m, struct i2400mu, i2400m);
i2400mu_init(i2400mu);
i2400m_netdev_setup(net_dev);
+ net_dev->ethtool_ops = &i2400mu_ethtool_ops;
}
--
1.7.3.4
^ permalink raw reply related
* RE: [PATCH net V4 2/2] igb: offer a PTP Hardware Clock instead of the timecompare method
From: Keller, Jacob E @ 2012-03-26 18:56 UTC (permalink / raw)
To: chetan loke, Richard Cochran
Cc: netdev@vger.kernel.org, e1000-devel@lists.sourceforge.net,
Kirsher, Jeffrey T, Ronciak, John, john.stultz@linaro.org,
tglx@linutronix.de
In-Reply-To: <CAAsGZS5Kn0nnwE0=0Eoo9a9e4+9w2fQ4nWjbCNsNrL-yfE3BtQ@mail.gmail.com>
> -----Original Message-----
> From: chetan loke [mailto:loke.chetan@gmail.com]
> Sent: Monday, March 26, 2012 10:12 AM
> To: Richard Cochran
> Cc: Keller, Jacob E; netdev@vger.kernel.org; e1000-
> devel@lists.sourceforge.net; Kirsher, Jeffrey T; Ronciak, John;
> john.stultz@linaro.org; tglx@linutronix.de
> Subject: Re: [PATCH net V4 2/2] igb: offer a PTP Hardware Clock instead of the
> timecompare method
>
> You are confusing 'blocking the driver's fast path' with
> performance/optimization etc. We cannot let user-space code jam the system.
> Kernel code should be designed such that
> bugs(intentional/unintentional) in user-space code cannot cause system wide
> adverse affects. Period.
>
I agree. But I also think a test case should be in order here. What actually
happens with a badly designed user app cramming ioctls. (Note that under most
system designs the ioctls require root access unless you change the default
permissions.)
> Does your existing design limit (ab)users from pounding the ioctls?
>
> As I mentioned earlier, it could be possible to take care of gettime and the
> driver's Rx/Tx path by using a mixture of locks/kernel-thread.
> But settime/adjtime still needs to be curbed.
>
I am curious how you see a kernel thread resolving the Tx/Rx issue? or is the
kernel thread being used by gettime? I don't believe we can wait for the Tx/Rx
path, because if we take too long the software sees it as a dropped timestamp.
Also we have a pointer to the skb which is free'd right after the call for
(rx/tx)hwtstamp so we can't just copy that pointer.
> Why isn't ioctl-rate limiting acceptable? Let's say an app that is trying to
> set/adj NIC counter is running on host side then how often would it need to
> read and correct/set/adj? once every msec(so 1000 times a second), once every
> 10 msec(100 times a second) etc?
>
> So, will pounding the ioctl 1000 times, while processing ~820K
> frames(1500 byte payload on 10G link) still cause a problem for the driver is
> what we would need to see. rate can also be a factor of link-speed(?).
>
> And we don't need 100 such apps. Only 1 app should be working in tandem with
> the NIC. If other apps fail then atleast the sysadmin or users would know
> someone else is (ab)using it.
How would we only allow one app? Any app with permissions could call the ioctls.
I do agree that having too many ioctls is a problem. Even in cases where PTP is
only enabled on a "trusted" system. Allowing the kernel to assume the system
is trusted means we introduce security holes. I am not sure of the right solution
or whether we need a different one, though. I am going to try and provide a test case
where someone hammers the ioctls in a loop, and see what happens.
>
>
> > Thanks,
> > Richard
>
> Chetan
^ permalink raw reply
* Re: [PATCH V2 4/7] net/mlx4_en: Set max rate-limit for a TC
From: John Fastabend @ 2012-03-26 18:55 UTC (permalink / raw)
To: Or Gerlitz
Cc: Ben Hutchings, Eric Dumazet, David Miller, Amir Vadai, netdev,
Roland Dreier, Yevgeny Petrilin, Oren Duer, Amir Vadai
In-Reply-To: <CAJZOPZKGJ_nJt92THc+eRGnEXPZG+hX_d2=f56m7gB_Fv8K4Cg@mail.gmail.com>
On 3/26/2012 10:00 AM, Or Gerlitz wrote:
> On Mon, Mar 26, 2012 at 4:46 PM, Ben Hutchings
> <bhutchings@solarflare.com> wrote:
>>> We used sysfs since max bw isn't part of the ETS / DCBX NL support, and we're
>>> open to other suggestions to add generic support for max bw, e.g add call to
>>> the DCBX NL API.
>
>> netlink interfaces are generally easily extensible and it doesn't make
>> sense to me to augment such an interface through sysfs. Perhaps you're
>> concerned that netlink extensions won't be supported in older kernel
>> versions running your OOT driver? That's unfortunate, but let's not
>> standardise an ugly interface based on a temporary problem like that.
>
> As written above, that was done since ratelimit isn't part of ETS, we can
> that through netlink extensions that you mentioned, if this is the preffered
> way to go, David? Eric? Ben - could you provide pointer to these extensions?
>
> Or.
> --
I think I original suggested it didn't belong in DCBNL because it
wasn't part of ETS (802.1Qaz). But it _is_ a traffic selection
algorithm and could fall into the vendor specific part of 802.1Q.
I would suggest either adding it as an option to mqprio to take
a max bandwidth. The advantage here is it would be tied in with
the usual QOS tooling 'tc'.
# tc qdisc add dev eth3 root mqprio help
Usage: ... mqprio [num_tc NUMBER] [map P0 P1 ...]
[queues count1@offset1 count2@offset2 ...] [hw 1|0]
[max_rate rate@tc ...]
Or extending DCBNL being careful not to break backwards
compatibility. I tend to think extending mqprio is cleaner but
a DCBNL extension could likely work as well. Would need a
'DCBNL_IEEE_SET_MAXRATE' and 'DCBNL_IEEE_GET_MAXRATE' for this
I expect.
.John
^ permalink raw reply
* RE: iproute2 does not enumerate vf's properly (ixgbe)
From: Rose, Gregory V @ 2012-03-26 18:53 UTC (permalink / raw)
To: Scott, netdev@vger.kernel.org
In-Reply-To: <6FA463E6-5B10-4D1E-A026-2FD7C7212F29@gmail.com>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
> On Behalf Of Scott
> Sent: Monday, March 26, 2012 11:01 AM
> To: netdev@vger.kernel.org
> Subject: Re: iproute2 does not enumerate vf's properly (ixgbe)
>
>
> On Mar 26, 2012, at 11:56 AM, Rose, Gregory V wrote:
>
> >> -----Original Message-----
> >> From: netdev-owner@vger.kernel.org
> >> [mailto:netdev-owner@vger.kernel.org]
> >> On Behalf Of Scott
> >> Sent: Saturday, March 24, 2012 6:44 AM
> >> To: netdev@vger.kernel.org
> >> Subject: iproute2 does not enumerate vf's properly (ixgbe)
> >>
> >> When loading the module ixgbe with sr-iov enabled (max_vfs),
> >> enumeration of the interfaces' VFs is inconsistent using the iproute2
> utility.
> >>
> >
> > This was a longstanding bug that has since been fixed. About 40 VFs was
> the approximate cut off due to buffer allocation issues in the netlink
> interface. You'll probably need to upgrade your kernel or else backport
> the patches into your current kernel.
>
>
> Thank you for that valuable feedback. Is this the commit that contains
> the patches that you are referring to?
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-
> stable.git;a=commit;h=115c9b81928360d769a76c632bae62d15206a94a
Yes, that was one. You'll also want this commit from Eric Dumazet:
a4b64fbe482c7766f7925f03067fc637716bfa3f
And then the original fix for this was back in June, 2011 in this commit:
c7ac8679bec9397afe8918f788cbcef88c38da54
However, that commit in June introduced a bug that the commit you point to was intended to fix for good. The commit in June broke some applications that only allocated 8K for their buffers.
- Greg
>
> -Scott
>
>
>
> >> Using a freshly compiled git pull:
> >> # ./ip -V
> >> ip utility, iproute2-ss120319
> >>
> >> Steps to reproduce:
> >>
> >> 1. Determine the ethernet interface IDs:
> >> # dmesg |grep ixgbe\ 0000:05:00.[0-9].*detected|head -n 2
> >> [ 8.448031] ixgbe 0000:05:00.0: eth4: detected SFP+: 5
> >> [ 8.816035] ixgbe 0000:05:00.1: eth5: detected SFP+: 6
> >>
> >> 2. Load the module w/40 VFs:
> >> # modprobe ixgbe max_vfs=40
> >>
> >> 3. Sanity checks:
> >> # lsmod |grep ixgbe
> >> ixgbe 206156 0
> >> dca 15179 2 ixgbe,igb
> >>
> >> # modinfo ixgbe|grep version
> >> version: 3.6.7-NAPI
> >> srcversion: 119ADBD2B16B0E40668FB9A
> >> vermagic: 3.0.0-16-server SMP mod_unload modversions
> >> (this is the latest too)
> >>
> >> # lspci |grep 05:1[0-9]|perl -lane 'delete @F[1,2,3,4,10,11];print
> "@F"'
> >> 05:10.0 82599 Ethernet Controller Virtual Function
> >> 05:10.2 82599 Ethernet Controller Virtual Function
> >> 05:10.4 82599 Ethernet Controller Virtual Function
> >> 05:10.6 82599 Ethernet Controller Virtual Function
> >> 05:11.0 82599 Ethernet Controller Virtual Function
> >> (suppressing output of all 40 VFs)
> >>
> >> # lspci |grep 05:1[0-9]|wc -l
> >> 40
> >> (showing that there are actually 40)
> >>
> >> # ls -l /sys/class/net/eth4/device/|grep virt|awk '{print $10"
> >> "$8}'|sort|head -5
> >> ../0000:05:10.0 virtfn0
> >> ../0000:05:10.2 virtfn1
> >> ../0000:05:10.4 virtfn2
> >> ../0000:05:10.6 virtfn3
> >> ../0000:05:11.0 virtfn4
> >> (suppressing output of all 40 VFs)
> >>
> >> 5. Run ip link show:
> >> # ./ip link show|grep -e eth[45] -e vf (null output!)
> >>
> >> 6. Load the module with fewer VFs
> >> # rmmod ixgbe
> >> # modprobe ixgbe max_vfs=5
> >> # lspci |grep 05:1[0-9]|perl -lane 'delete @F[1,2,3,4,10,11];print
> "@F"'
> >> 05:10.0 82599 Ethernet Controller Virtual Function
> >> 05:10.2 82599 Ethernet Controller Virtual Function
> >> 05:10.4 82599 Ethernet Controller Virtual Function
> >> 05:10.6 82599 Ethernet Controller Virtual Function
> >> 05:11.0 82599 Ethernet Controller Virtual Function
> >>
> >> # ls -l /sys/class/net/eth4/device/|grep virt|awk '{print $10"
> >> "$8}'|sort
> >> ../0000:05:10.0 virtfn0
> >> ../0000:05:10.2 virtfn1
> >> ../0000:05:10.4 virtfn2
> >> ../0000:05:10.6 virtfn3
> >> ../0000:05:11.0 virtfn4
> >>
> >> 7. Run ip link show
> >> # ./ip link show|grep -e eth[45] -e vf
> >> 57: eth4: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
> >> DEFAULT qlen 1000
> >> vf 0 MAC 52:a0:59:03:20:a8
> >> vf 1 MAC 82:5f:55:a5:1f:be
> >> vf 2 MAC 0a:ab:86:0c:02:b3
> >> vf 3 MAC 22:a7:28:ce:9c:23
> >> vf 4 MAC 26:ea:6c:1b:ca:57
> >> 58: eth5: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
> >> DEFAULT qlen 1000 (no vfs displayed for eth5!)
> >>
> >> Patrick Kutch over at Intel suggested that there may be a patch to
> >> fix this problem, but I was not able to locate it.
> >> http://communities.intel.com/thread/28411?tstart=0
> >>
> >> There is also Launchpad bug #960497 for this issue.
> >>
> >> Thanks in advance for any suggestions.
> >>
> >> -SP--
> >> 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
>
> --
> 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: Locking bug in 3.0.25, IPv6.
From: Ben Greear @ 2012-03-26 18:41 UTC (permalink / raw)
To: netdev
In-Reply-To: <4F709EAA.6040700@candelatech.com>
On 03/26/2012 09:51 AM, Ben Greear wrote:
> Has anyone seen this in 3.0.25? My kernel has some other patches
> applied, but we did not see this before 3.0.24.
>
> BUG: sleeping function called from invalid context at /home/greearb/git/linux-3.0.dev.y/mm/memory.c:3904
Just FYI: This happens in un-modified kernels...seems to have been introduced
(or made more visible) somewhere between 3.0.19 and 3.0.23.
I'm bisecting it now...
Thanks,
Ben
>
> ================================================
> [ BUG: lock held when returning to user space! ]
> ------------------------------------------------
> ip/6696 is leaving the kernel with locks still held!
> 1 lock held by ip/6696:
> #0: (rcu_read_lock){.+.+..}, at: [<ffffffffa03051c4>] rcu_read_lock+0x0/0x35 [ipv6]
> in_atomic(): 0, irqs_disabled(): 0, pid: 6694, name: ip
> INFO: lockdep is turned off.
> Pid: 6694, comm: ip Tainted: G C 3.0.25+ #1
> Call Trace:
> [<ffffffff8103e479>] __might_sleep+0x111/0x115
> [<ffffffff810c98bf>] might_fault+0x2f/0x9e
> [<ffffffff8138698e>] ? copy_from_user+0x2a/0x2c
> [<ffffffff810c98de>] ? might_fault+0x4e/0x9e
> [<ffffffff8137cc90>] move_addr_to_user+0x21/0x8e
> [<ffffffff8137ce7c>] __sys_recvmsg+0x17f/0x21e
> [<ffffffff810634a8>] ? up_read+0x1e/0x36
> [<ffffffff810fc06e>] ? fcheck_files+0xb7/0xee
> [<ffffffff810fc191>] ? fget_light+0x35/0xac
> [<ffffffff810d0023>] ? remove_vma+0x7a/0x82
> [<ffffffff8137d620>] sys_recvmsg+0x3d/0x5b
> [<ffffffff8144f092>] system_call_fastpath+0x16/0x1b
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: iproute2 does not enumerate vf's properly (ixgbe)
From: Scott @ 2012-03-26 18:01 UTC (permalink / raw)
To: netdev
In-Reply-To: <C5551D9AAB213A418B7FD5E4A6F30A0702FD6FDC@ORSMSX106.amr.corp.intel.com>
On Mar 26, 2012, at 11:56 AM, Rose, Gregory V wrote:
>> -----Original Message-----
>> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
>> On Behalf Of Scott
>> Sent: Saturday, March 24, 2012 6:44 AM
>> To: netdev@vger.kernel.org
>> Subject: iproute2 does not enumerate vf's properly (ixgbe)
>>
>> When loading the module ixgbe with sr-iov enabled (max_vfs), enumeration
>> of the interfaces' VFs is inconsistent using the iproute2 utility.
>>
>
> This was a longstanding bug that has since been fixed. About 40 VFs was the approximate cut off due to buffer allocation issues in the netlink interface. You'll probably need to upgrade your kernel or else backport the patches into your current kernel.
Thank you for that valuable feedback. Is this the commit that contains the patches that you are referring to?
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commit;h=115c9b81928360d769a76c632bae62d15206a94a
-Scott
>> Using a freshly compiled git pull:
>> # ./ip -V
>> ip utility, iproute2-ss120319
>>
>> Steps to reproduce:
>>
>> 1. Determine the ethernet interface IDs:
>> # dmesg |grep ixgbe\ 0000:05:00.[0-9].*detected|head -n 2
>> [ 8.448031] ixgbe 0000:05:00.0: eth4: detected SFP+: 5
>> [ 8.816035] ixgbe 0000:05:00.1: eth5: detected SFP+: 6
>>
>> 2. Load the module w/40 VFs:
>> # modprobe ixgbe max_vfs=40
>>
>> 3. Sanity checks:
>> # lsmod |grep ixgbe
>> ixgbe 206156 0
>> dca 15179 2 ixgbe,igb
>>
>> # modinfo ixgbe|grep version
>> version: 3.6.7-NAPI
>> srcversion: 119ADBD2B16B0E40668FB9A
>> vermagic: 3.0.0-16-server SMP mod_unload modversions
>> (this is the latest too)
>>
>> # lspci |grep 05:1[0-9]|perl -lane 'delete @F[1,2,3,4,10,11];print "@F"'
>> 05:10.0 82599 Ethernet Controller Virtual Function
>> 05:10.2 82599 Ethernet Controller Virtual Function
>> 05:10.4 82599 Ethernet Controller Virtual Function
>> 05:10.6 82599 Ethernet Controller Virtual Function
>> 05:11.0 82599 Ethernet Controller Virtual Function
>> (suppressing output of all 40 VFs)
>>
>> # lspci |grep 05:1[0-9]|wc -l
>> 40
>> (showing that there are actually 40)
>>
>> # ls -l /sys/class/net/eth4/device/|grep virt|awk '{print $10"
>> "$8}'|sort|head -5
>> ../0000:05:10.0 virtfn0
>> ../0000:05:10.2 virtfn1
>> ../0000:05:10.4 virtfn2
>> ../0000:05:10.6 virtfn3
>> ../0000:05:11.0 virtfn4
>> (suppressing output of all 40 VFs)
>>
>> 5. Run ip link show:
>> # ./ip link show|grep -e eth[45] -e vf
>> (null output!)
>>
>> 6. Load the module with fewer VFs
>> # rmmod ixgbe
>> # modprobe ixgbe max_vfs=5
>> # lspci |grep 05:1[0-9]|perl -lane 'delete @F[1,2,3,4,10,11];print "@F"'
>> 05:10.0 82599 Ethernet Controller Virtual Function
>> 05:10.2 82599 Ethernet Controller Virtual Function
>> 05:10.4 82599 Ethernet Controller Virtual Function
>> 05:10.6 82599 Ethernet Controller Virtual Function
>> 05:11.0 82599 Ethernet Controller Virtual Function
>>
>> # ls -l /sys/class/net/eth4/device/|grep virt|awk '{print $10" "$8}'|sort
>> ../0000:05:10.0 virtfn0
>> ../0000:05:10.2 virtfn1
>> ../0000:05:10.4 virtfn2
>> ../0000:05:10.6 virtfn3
>> ../0000:05:11.0 virtfn4
>>
>> 7. Run ip link show
>> # ./ip link show|grep -e eth[45] -e vf
>> 57: eth4: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
>> DEFAULT qlen 1000
>> vf 0 MAC 52:a0:59:03:20:a8
>> vf 1 MAC 82:5f:55:a5:1f:be
>> vf 2 MAC 0a:ab:86:0c:02:b3
>> vf 3 MAC 22:a7:28:ce:9c:23
>> vf 4 MAC 26:ea:6c:1b:ca:57
>> 58: eth5: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
>> DEFAULT qlen 1000 (no vfs displayed for eth5!)
>>
>> Patrick Kutch over at Intel suggested that there may be a patch to fix
>> this problem, but I was not able to locate it.
>> http://communities.intel.com/thread/28411?tstart=0
>>
>> There is also Launchpad bug #960497 for this issue.
>>
>> Thanks in advance for any suggestions.
>>
>> -SP--
>> 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
* (unknown),
From: TUSHAR DONGA @ 2012-03-26 17:55 UTC (permalink / raw)
You have won the sum of £ 750,000.00 in the Swiss National Lottery.For
claims conatct ( swissnational@yahoo.com.hk ) or you can call +44-
703-596-9478.
^ permalink raw reply
* MX2/12
From: Microsoft @ 2012-03-26 17:39 UTC (permalink / raw)
Your email has won £375,000.
^ permalink raw reply
* Re: [PATCH net V4 2/2] igb: offer a PTP Hardware Clock instead of the timecompare method
From: chetan loke @ 2012-03-26 17:11 UTC (permalink / raw)
To: Richard Cochran
Cc: Keller, Jacob E, netdev@vger.kernel.org,
e1000-devel@lists.sourceforge.net, Kirsher, Jeffrey T,
Ronciak, John, john.stultz@linaro.org, tglx@linutronix.de
In-Reply-To: <20120326152730.GA10212@localhost.localdomain>
On Mon, Mar 26, 2012 at 11:27 AM, Richard Cochran
<richardcochran@gmail.com> wrote:
> On Mon, Mar 26, 2012 at 11:07:40AM -0400, chetan loke wrote:
>> On Sat, Mar 24, 2012 at 2:51 AM, Richard Cochran
>> <richardcochran@gmail.com> wrote:
>> > On Fri, Mar 23, 2012 at 03:39:08PM -0400, chetan loke wrote:
>> >>
>> >> So, how is it working today? Because we could have tx and rx
>> >> completions on different CPUs. Is it not possible to have the
>> >> following race today - between timecompare_update->timecompare_offset
>> >> -> timecounter_readdelta of say Rx and timecounter_cyc2time from Tx?
>> >
>> > I works (in the igb) because of the spinlock. You know, that thing
>> > that you are so against using.
>> >
>>
>> I meant, was there a lock before the PHC functionality in igb?
>
> There was no lock, and yes, it was a bug.
Ok, so this needs to be fixed irrespective of the PHC code.
>
>> >> How about rate limiting at the PHC class driver level? And then it
>> >> will work across the board for all the adapters at the device level.
>> >
>> > No, don't go there. Enough bikeshedding already. If you have a serious
Did I ever tell you that your patch is costing us 'N' clock-cycles in
the fast path? We all understand that to gain some features we may
have to sacrifice something. Folks who want time-stamping might have
to take a small performance hit (may be to work around hardware issues
and so on).
You are confusing 'blocking the driver's fast path' with
performance/optimization etc. We cannot let user-space code jam the
system. Kernel code should be designed such that
bugs(intentional/unintentional) in user-space code cannot cause system
wide adverse affects. Period.
Does your existing design limit (ab)users from pounding the ioctls?
As I mentioned earlier, it could be possible to take care of gettime
and the driver's Rx/Tx path by using a mixture of locks/kernel-thread.
But settime/adjtime still needs to be curbed.
Why isn't ioctl-rate limiting acceptable? Let's say an app that is
trying to set/adj NIC counter is running on host side then how often
would it need to read and correct/set/adj? once every msec(so 1000
times a second), once every 10 msec(100 times a second) etc?
So, will pounding the ioctl 1000 times, while processing ~820K
frames(1500 byte payload on 10G link) still cause a problem for the
driver is what we would need to see. rate can also be a factor of
link-speed(?).
And we don't need 100 such apps. Only 1 app should be working in
tandem with the NIC. If other apps fail then atleast the sysadmin or
users would know someone else is (ab)using it.
> Thanks,
> Richard
Chetan
^ permalink raw reply
* Re: [PATCH V2 4/7] net/mlx4_en: Set max rate-limit for a TC
From: Or Gerlitz @ 2012-03-26 17:00 UTC (permalink / raw)
To: Ben Hutchings, Eric Dumazet, David Miller
Cc: Amir Vadai, netdev, Roland Dreier, Yevgeny Petrilin, Oren Duer,
Amir Vadai
In-Reply-To: <1332773163.3500.81.camel@deadeye>
On Mon, Mar 26, 2012 at 4:46 PM, Ben Hutchings
<bhutchings@solarflare.com> wrote:
>> We used sysfs since max bw isn't part of the ETS / DCBX NL support, and we're
>> open to other suggestions to add generic support for max bw, e.g add call to
>> the DCBX NL API.
> netlink interfaces are generally easily extensible and it doesn't make
> sense to me to augment such an interface through sysfs. Perhaps you're
> concerned that netlink extensions won't be supported in older kernel
> versions running your OOT driver? That's unfortunate, but let's not
> standardise an ugly interface based on a temporary problem like that.
As written above, that was done since ratelimit isn't part of ETS, we can
that through netlink extensions that you mentioned, if this is the preffered
way to go, David? Eric? Ben - could you provide pointer to these extensions?
Or.
^ permalink raw reply
* Re: [PATCH v15 00/13] seccomp_filter: syscall filtering using BPF
From: Will Drewry @ 2012-03-26 16:53 UTC (permalink / raw)
To: H. Peter Anvin, akpm
Cc: linux-kernel, linux-arch, linux-doc, kernel-hardening, netdev,
x86, arnd, davem, mingo, oleg, peterz, rdunlap, mcgrathr, tglx,
luto, eparis, serge.hallyn, djm, scarybeasts, indan, pmoore,
corbet, eric.dumazet, markus, coreyb, keescook
In-Reply-To: <4F6F73B9.2000207@zytor.com>
On Sun, Mar 25, 2012 at 2:36 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 03/14/2012 08:11 PM, Will Drewry wrote:
>> Please see prior revisions of this patch series for a high
>> level blurb.
>>
>> This revision makes a number of refinements and tweaks. The biggest
>> change is a slight renumbering of the return codes which will break
>> existing code using this patch series.
>>
>> I believe this patch is in good shape, and I don't see the need for
>> any more API changes at this point. I plan to start using this revision
>> more extensively, and I'd certainly appreciate any testing.
>>
>> Thanks!
>> will
>>
>
> x86 portions:
>
> Reviewed-by: H. Peter Anvin <hpa@zytor.com>
Thanks!
> What is the preferred way to push this upstream? (Presumably for 3.5 at
> this point, but we should get it into -next as soon as possible after
> the merge window.)
A repost when rc1 has been cut is what's been suggested to me.
Additionally, two tweaks have been pointed out off list (documentation
cruft and lack if #ifdef for asm/syscall.h), which I have fixed in my
local and github tree but haven't yet reposted here. I was planning
on just posting v17 when rc1 is cut (unless I've blithely missed it
already) and then trying to pester everyone and anyone who can merge.
:)
Maybe someone more authoritative than me will answer though.
thanks!
will
^ permalink raw reply
* Locking bug in 3.0.25, IPv6.
From: Ben Greear @ 2012-03-26 16:51 UTC (permalink / raw)
To: netdev
Has anyone seen this in 3.0.25? My kernel has some other patches
applied, but we did not see this before 3.0.24.
BUG: sleeping function called from invalid context at /home/greearb/git/linux-3.0.dev.y/mm/memory.c:3904
================================================
[ BUG: lock held when returning to user space! ]
------------------------------------------------
ip/6696 is leaving the kernel with locks still held!
1 lock held by ip/6696:
#0: (rcu_read_lock){.+.+..}, at: [<ffffffffa03051c4>] rcu_read_lock+0x0/0x35 [ipv6]
in_atomic(): 0, irqs_disabled(): 0, pid: 6694, name: ip
INFO: lockdep is turned off.
Pid: 6694, comm: ip Tainted: G C 3.0.25+ #1
Call Trace:
[<ffffffff8103e479>] __might_sleep+0x111/0x115
[<ffffffff810c98bf>] might_fault+0x2f/0x9e
[<ffffffff8138698e>] ? copy_from_user+0x2a/0x2c
[<ffffffff810c98de>] ? might_fault+0x4e/0x9e
[<ffffffff8137cc90>] move_addr_to_user+0x21/0x8e
[<ffffffff8137ce7c>] __sys_recvmsg+0x17f/0x21e
[<ffffffff810634a8>] ? up_read+0x1e/0x36
[<ffffffff810fc06e>] ? fcheck_files+0xb7/0xee
[<ffffffff810fc191>] ? fget_light+0x35/0xac
[<ffffffff810d0023>] ? remove_vma+0x7a/0x82
[<ffffffff8137d620>] sys_recvmsg+0x3d/0x5b
[<ffffffff8144f092>] system_call_fastpath+0x16/0x1b
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: socket option IP_MSFILTER questions and observations
From: David Stevens @ 2012-03-26 16:34 UTC (permalink / raw)
To: Cedric Jehasse; +Cc: netdev, netdev-owner
In-Reply-To: <4F708E08.7040500@softathome.com>
> I'm trying to use source specific multicast by setting the IP_MSFILTER
> socket option. I noticed i need to join the group with IP_ADD_MEMBERSHIP
> before setting the source filter. This is not the behavior i expected
> after reading RFC3678.
RFC3678 doesn't say that an IP_MSFILTER will join a group
automatically. The model is that you join a group once and then
dynamically set the source filters as they change over time.
> A potential issue i'm thinking of with this approach: an IGMP report
> could be sent after joining a group but before the filter is set.
> Is there a way to prevent this?
Adding or changing the source filters triggers a new report
but you can use IP_ADD_SOURCE_MEMBERSHIP which does explicitly join
a group with a source filter. In the kernel, this is done with an
"any" join followed by setting a source filter which actually will result
in 2 reports too, if there are no other processes using that group.
+-DLS
^ permalink raw reply
* Re: [PATCH] net/garp: avoid infinite loop if attribute already exists
From: Ward, David - 0663 - MITLL @ 2012-03-26 16:07 UTC (permalink / raw)
To: jorge@dti2.net; +Cc: netdev@vger.kernel.org
In-Reply-To: <4F708A9A.8040705@dti2.net>
[-- Attachment #1: Type: text/plain, Size: 4958 bytes --]
On 26/03/12 11:26, Jorge Boncompte [DTI2] wrote:
> El 26/03/2012 16:11, Ward, David - 0663 - MITLL escribió:
>> On 26/03/12 07:23, Jorge Boncompte [DTI2] wrote:
>>> El 26/03/2012 0:43, David Ward escribió:
>>>> An infinite loop occurred if garp_attr_create was called with the
>>>> values of an existing attribute. Return -EEXIST instead.
>>> I should have sent this some months ago but others things keep me from
>>> doing it.
>>> Anyway, I think that the right thing to do it's reuse the attribute to not
>>> disturb the switch/network. Also, returning an error it's pointless because
>>> nobody checks vlan_gvrp_request_join() return and you'll end up in a state where
>>> the VLAN device has the GVRP flag but it's not announcing the attribute.
>> I think what you are saying is that if we try to create an attribute that
>> already exists, we should leave the old attribute alone. I agree with that, and
>> the patch I sent does that. I also think the fact that the attribute existed
>> would likely indicate a bug in the GARP application, in which we are not
>> withdrawing an existing attribute when we should. Your patch warns on this
>> condition.
> The attribute it's still on the tree because the leave path it's called
> asynchronously from a timer. As far as I could see there's no other code path
> that can put an attribute on the tree twice and that's why I put the WARN_ON().
Oh right... so in that case, garp_attr_create should change the state
of the attribute from LA back to VA. I think it should only trigger a
warning if the current state of the attribute was not LA?
I'll update my patch and resend.
>
>> Our patches are mostly the same. One thing I notice with your patch is that for
>> new attributes, it now traverses the RB tree twice. And it doesn't free the
>> memory for a new attribute if it wasn't inserted into the RB tree. So, what if
>> instead I modified my patch to add "WARN_ON(err)" to either garp_request_join or
>> vlan_gvrp_request_join? This would also warn us on -ENOMEM.
>>
>> David
>>
>>> Please take a look at the conversation I had with Patrick in the patch
>>> commit log.
>>>
>>> If you agree, I'm fine with you redoing your patch or David using mine if he
>>> thinks it's ok.
>>>
>>> Regards,
>>> Jorge
>>>
>>>> Signed-off-by: David Ward<david.ward@ll.mit.edu>
>>>> ---
>>>> net/802/garp.c | 18 +++++++++++++-----
>>>> 1 files changed, 13 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/net/802/garp.c b/net/802/garp.c
>>>> index 8e21b6d..bb5015e 100644
>>>> --- a/net/802/garp.c
>>>> +++ b/net/802/garp.c
>>>> @@ -167,7 +167,7 @@ static struct garp_attr *garp_attr_lookup(const struct
>>>> garp_applicant *app,
>>>> return NULL;
>>>> }
>>>>
>>>> -static void garp_attr_insert(struct garp_applicant *app, struct garp_attr *new)
>>>> +static int garp_attr_insert(struct garp_applicant *app, struct garp_attr *new)
>>>> {
>>>> struct rb_node *parent = NULL, **p =&app->gid.rb_node;
>>>> struct garp_attr *attr;
>>>> @@ -181,24 +181,32 @@ static void garp_attr_insert(struct garp_applicant
>>>> *app, struct garp_attr *new)
>>>> p =&parent->rb_left;
>>>> else if (d> 0)
>>>> p =&parent->rb_right;
>>>> + else
>>>> + return -EEXIST;
>>>> }
>>>> rb_link_node(&new->node, parent, p);
>>>> rb_insert_color(&new->node,&app->gid);
>>>> + return 0;
>>>> }
>>>>
>>>> static struct garp_attr *garp_attr_create(struct garp_applicant *app,
>>>> const void *data, u8 len, u8 type)
>>>> {
>>>> struct garp_attr *attr;
>>>> + int err;
>>>>
>>>> attr = kmalloc(sizeof(*attr) + len, GFP_ATOMIC);
>>>> if (!attr)
>>>> - return attr;
>>>> + return PTR_ERR(-ENOMEM);
>>>> attr->state = GARP_APPLICANT_VO;
>>>> attr->type = type;
>>>> attr->dlen = len;
>>>> memcpy(attr->data, data, len);
>>>> - garp_attr_insert(app, attr);
>>>> + err = garp_attr_insert(app, attr);
>>>> + if (err< 0) {
>>>> + kfree(attr);
>>>> + return PTR_ERR(err);
>>>> + }
>>>> return attr;
>>>> }
>>>>
>>>> @@ -353,9 +361,9 @@ int garp_request_join(const struct net_device *dev,
>>>>
>>>> spin_lock_bh(&app->lock);
>>>> attr = garp_attr_create(app, data, len, type);
>>>> - if (!attr) {
>>>> + if (IS_ERR(attr)) {
>>>> spin_unlock_bh(&app->lock);
>>>> - return -ENOMEM;
>>>> + return ERR_PTR(attr);
>>>> }
>>>> garp_attr_event(app, attr, GARP_EVENT_REQ_JOIN);
>>>> spin_unlock_bh(&app->lock);
>
--
David Ward, Associate Staff
Wideband Tactical Networking Group
MIT Lincoln Laboratory
Office: 781-981-4266
Mobile: 781-999-1925
Fax: 781-981-4583
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4558 bytes --]
^ permalink raw reply
* RE: iproute2 does not enumerate vf's properly (ixgbe)
From: Rose, Gregory V @ 2012-03-26 15:56 UTC (permalink / raw)
To: Scott, netdev@vger.kernel.org
In-Reply-To: <89EBE686-6625-428C-8CCB-6A8E8B8162A8@gmail.com>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
> On Behalf Of Scott
> Sent: Saturday, March 24, 2012 6:44 AM
> To: netdev@vger.kernel.org
> Subject: iproute2 does not enumerate vf's properly (ixgbe)
>
> When loading the module ixgbe with sr-iov enabled (max_vfs), enumeration
> of the interfaces' VFs is inconsistent using the iproute2 utility.
>
> Server Information:HP Product Name: ProLiant DL165 G7 Ethernet Card
> Information: Intel 82599EB 10-Gigabit SFI/SFP+
> uname: Linux 3.0.0-16-server x86_64 GNU/Linux OS Release: Ubuntu 11.10
This was a longstanding bug that has since been fixed. About 40 VFs was the approximate cut off due to buffer allocation issues in the netlink interface. You'll probably need to upgrade your kernel or else backport the patches into your current kernel.
- Greg
>
>
> Using a freshly compiled git pull:
> # ./ip -V
> ip utility, iproute2-ss120319
>
> Steps to reproduce:
>
> 1. Determine the ethernet interface IDs:
> # dmesg |grep ixgbe\ 0000:05:00.[0-9].*detected|head -n 2
> [ 8.448031] ixgbe 0000:05:00.0: eth4: detected SFP+: 5
> [ 8.816035] ixgbe 0000:05:00.1: eth5: detected SFP+: 6
>
> 2. Load the module w/40 VFs:
> # modprobe ixgbe max_vfs=40
>
> 3. Sanity checks:
> # lsmod |grep ixgbe
> ixgbe 206156 0
> dca 15179 2 ixgbe,igb
>
> # modinfo ixgbe|grep version
> version: 3.6.7-NAPI
> srcversion: 119ADBD2B16B0E40668FB9A
> vermagic: 3.0.0-16-server SMP mod_unload modversions
> (this is the latest too)
>
> # lspci |grep 05:1[0-9]|perl -lane 'delete @F[1,2,3,4,10,11];print "@F"'
> 05:10.0 82599 Ethernet Controller Virtual Function
> 05:10.2 82599 Ethernet Controller Virtual Function
> 05:10.4 82599 Ethernet Controller Virtual Function
> 05:10.6 82599 Ethernet Controller Virtual Function
> 05:11.0 82599 Ethernet Controller Virtual Function
> (suppressing output of all 40 VFs)
>
> # lspci |grep 05:1[0-9]|wc -l
> 40
> (showing that there are actually 40)
>
> # ls -l /sys/class/net/eth4/device/|grep virt|awk '{print $10"
> "$8}'|sort|head -5
> ../0000:05:10.0 virtfn0
> ../0000:05:10.2 virtfn1
> ../0000:05:10.4 virtfn2
> ../0000:05:10.6 virtfn3
> ../0000:05:11.0 virtfn4
> (suppressing output of all 40 VFs)
>
> 5. Run ip link show:
> # ./ip link show|grep -e eth[45] -e vf
> (null output!)
>
> 6. Load the module with fewer VFs
> # rmmod ixgbe
> # modprobe ixgbe max_vfs=5
> # lspci |grep 05:1[0-9]|perl -lane 'delete @F[1,2,3,4,10,11];print "@F"'
> 05:10.0 82599 Ethernet Controller Virtual Function
> 05:10.2 82599 Ethernet Controller Virtual Function
> 05:10.4 82599 Ethernet Controller Virtual Function
> 05:10.6 82599 Ethernet Controller Virtual Function
> 05:11.0 82599 Ethernet Controller Virtual Function
>
> # ls -l /sys/class/net/eth4/device/|grep virt|awk '{print $10" "$8}'|sort
> ../0000:05:10.0 virtfn0
> ../0000:05:10.2 virtfn1
> ../0000:05:10.4 virtfn2
> ../0000:05:10.6 virtfn3
> ../0000:05:11.0 virtfn4
>
> 7. Run ip link show
> # ./ip link show|grep -e eth[45] -e vf
> 57: eth4: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
> DEFAULT qlen 1000
> vf 0 MAC 52:a0:59:03:20:a8
> vf 1 MAC 82:5f:55:a5:1f:be
> vf 2 MAC 0a:ab:86:0c:02:b3
> vf 3 MAC 22:a7:28:ce:9c:23
> vf 4 MAC 26:ea:6c:1b:ca:57
> 58: eth5: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
> DEFAULT qlen 1000 (no vfs displayed for eth5!)
>
> Patrick Kutch over at Intel suggested that there may be a patch to fix
> this problem, but I was not able to locate it.
> http://communities.intel.com/thread/28411?tstart=0
>
> There is also Launchpad bug #960497 for this issue.
>
> Thanks in advance for any suggestions.
>
> -SP--
> 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/vlan: withdraw VLAN ID attribute from GVRP on VLAN device stop
From: Ward, David - 0663 - MITLL @ 2012-03-26 15:50 UTC (permalink / raw)
To: jorge@dti2.net; +Cc: netdev@vger.kernel.org
In-Reply-To: <4F7087CA.5010804@dti2.net>
[-- Attachment #1: Type: text/plain, Size: 4157 bytes --]
On 26/03/12 11:14, Jorge Boncompte [DTI2] wrote:
> El 26/03/2012 15:38, Ward, David - 0663 - MITLL escribió:
>> On 26/03/12 07:29, Jorge Boncompte [DTI2] wrote:
>>> El 26/03/2012 0:43, David Ward escribió:
>>>> When a VLAN device is stopped which has VLAN_FLAG_GVRP set, the VLAN
>>>> ID attribute that was previously declared by GVRP must be withdrawn.
>>>>
>>> Hmm, maybe I am missing something but I think it only makes sense to withdrawn
>>> the attribute when you delete the interface, and vlan_dev_stop() it's called if
>>> you just put the interface down. It's better for the network convergence to not
>>> signal the switches just for this. IMHO.
>> If I bring a VLAN interface down, then I stop participating in the
>> VLAN. If my NIC still receives traffic for the VLAN, I drop it. So to
>> remove unnecessary load on the (potentially shared) network link and
>> remove unnecessary local processing by the kernel of packets I know I am
>> going to drop, I should tell the switch that I am no longer interested
>> in receiving the VLAN traffic. Which is the whole point of GVRP. Right?
> In the non-GVRP case, as far as i can see, you still receive the traffic for
> that VLAN and the kernel drops it.
But this is why GVRP is advantageous. I don't have to have a static
configuration on the switch for the VLANs I am participating in, and so
I only receive VLAN traffic when the VLAN interface is active and I
would actually process it.
> Maybe is that I think that a downed interface
> it's more a transient state, and administratively choosen one. If you don't want
> to participate in that VLAN, you always can disable GVRP on it or delete the
> interface.
>
>> In any case, we currently register the attribute when the interface is
>> brought up, not when it is created.
> And that makes sense to me, if you have never uped the interface you have never
> participated in that VLAN.
If I create an interface that is initially down, then bring it up, and
finally bring it back down, I think it should return to the state it was
in initially. So in my opinion, either the GVRP attribute should exist
while the interface is down, or it shouldn't.
For comparison, bringing a physical NIC interface down causes the other
end of a point-to-point Ethernet link to sense "no carrier", which could
trigger a topology change on the switch. So to me, it's semantically
the same that bringing a VLAN interface down could trigger a topology
change on the switch.
If your concern is about the effect on the network switching topology of
brief periods in which you bring the VLAN interface down (in order to
move it to another namespace), keep in mind that the default LeaveTimer
is 600 ms so the switch wouldn't propagate any topology changes unless
you don't bring the interface back up by then. Or you could consider
changing this timer on your switch.
David
>> However we do it, the attribute
>> declaration/withdrawal should be symmetric.
>>
>>>> Signed-off-by: David Ward<david.ward@ll.mit.edu>
>>>> ---
>>>> net/8021q/vlan_dev.c | 3 +++
>>>> 1 files changed, 3 insertions(+), 0 deletions(-)
>>>>
>>>> diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
>>>> index 9988d4a..df86dd0 100644
>>>> --- a/net/8021q/vlan_dev.c
>>>> +++ b/net/8021q/vlan_dev.c
>>>> @@ -319,6 +319,9 @@ static int vlan_dev_stop(struct net_device *dev)
>>>> struct vlan_dev_priv *vlan = vlan_dev_priv(dev);
>>>> struct net_device *real_dev = vlan->real_dev;
>>>>
>>>> + if (vlan->flags& VLAN_FLAG_GVRP)
>>>> + vlan_gvrp_request_leave(dev);
>>>> +
>>>> dev_mc_unsync(real_dev, dev);
>>>> dev_uc_unsync(real_dev, dev);
>>>> if (dev->flags& IFF_ALLMULTI)--
>> 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
>>
>>
>
--
David Ward, Associate Staff
Wideband Tactical Networking Group
MIT Lincoln Laboratory
Office: 781-981-4266
Mobile: 781-999-1925
Fax: 781-981-4583
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4558 bytes --]
^ permalink raw reply
* socket option IP_MSFILTER questions and observations
From: Cedric Jehasse @ 2012-03-26 15:40 UTC (permalink / raw)
To: netdev
Hi,
I'm trying to use source specific multicast by setting the IP_MSFILTER
socket option. I noticed i need to join the group with IP_ADD_MEMBERSHIP
before setting the source filter. This is not the behavior i expected
after reading RFC3678.
A potential issue i'm thinking of with this approach: an IGMP report
could be sent after joining a group but before the filter is set.
Is there a way to prevent this?
Thanks,
Cedric
This message and any attachments herein are confidential, intended solely for the addressees and are SoftAtHome's ownership. Any unauthorized use or dissemination is prohibited. If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
^ permalink raw reply
* Re: [PATCH] netdev: fix compile issues for !CONFIG_PCI in 3c59x
From: Paul Gortmaker @ 2012-03-26 15:38 UTC (permalink / raw)
To: Sergei Shtylyov, James Bottomley, Randy Dunlap
Cc: Paul Gortmaker, klassert, netdev, linux-mips
In-Reply-To: <4F70834E.3000308@mvista.com>
On 12-03-26 10:55 AM, Sergei Shtylyov wrote:
> Hello.
>
> On 03/26/2012 05:38 PM, Paul Gortmaker wrote:
>
>>> I hate to add in more #ifdef CONFIG_PCI but there are already
>>> quite a few in this driver, and it seems like it hasn't been
>>> built with CONFIG_PCI set to off in quite some time.
>
>> Actually, please scrap this patch. The uglyness of more ifdefs
>> made me look at it again. It should be do-able in a cleaner way
>> with stubs, and it appears this may even be similar to an old fail
>> from the past:
>
>> http://lkml.indiana.edu/hypermail/linux/kernel/1107.3/00109.html
>
> Also, see this patch:
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=0da0ead90122578ef6e4afba9ba4bcd3455fd8e8
>
> The driver patch this was done for is still in the -mm tree after all these
> years.:-)
>
>> I'll dig into it some more and follow up.
>
> I thought I addressed all issues with compilation of this driver with
> CONFIG_PCI=n. Apparently not, and some seem to have accumulated over time...
I got sidetracked working on other things, but I did manage to
learn this so far - It turns out that Randy fixed it and then
James un-fixed it in this commit:
commit 97a29d59fc222b36bac3ee3a8ae994f65bf7ffdf
Author: James Bottomley <James.Bottomley@HansenPartnership.com>
Date: Mon Jan 30 10:40:47 2012 -0600
[PARISC] fix compile break caused by iomap: make IOPORT/PCI mapping functions conditional
Reverting the above and mips builds 3c59x just fine. Note that MIPS
allmodconfig does not have either CONFIG_GENERIC_IOMAP or the other
CONFIG_GENERIC_PCI_IOMAP options.
Paul.
--
>
>> Thanks,
>> Paul.
>
> WBR, Sergei
^ permalink raw reply
* Re: [PATCH net V4 2/2] igb: offer a PTP Hardware Clock instead of the timecompare method
From: Richard Cochran @ 2012-03-26 15:27 UTC (permalink / raw)
To: chetan loke
Cc: Keller, Jacob E, netdev@vger.kernel.org,
e1000-devel@lists.sourceforge.net, Kirsher, Jeffrey T,
Ronciak, John, john.stultz@linaro.org, tglx@linutronix.de
In-Reply-To: <CAAsGZS556o4iXtsWBzpiXxmv4isoZzw_h+RNv5eBMTGOsK905w@mail.gmail.com>
On Mon, Mar 26, 2012 at 11:07:40AM -0400, chetan loke wrote:
> On Sat, Mar 24, 2012 at 2:51 AM, Richard Cochran
> <richardcochran@gmail.com> wrote:
> > On Fri, Mar 23, 2012 at 03:39:08PM -0400, chetan loke wrote:
> >>
> >> So, how is it working today? Because we could have tx and rx
> >> completions on different CPUs. Is it not possible to have the
> >> following race today - between timecompare_update->timecompare_offset
> >> -> timecounter_readdelta of say Rx and timecounter_cyc2time from Tx?
> >
> > I works (in the igb) because of the spinlock. You know, that thing
> > that you are so against using.
> >
>
> I meant, was there a lock before the PHC functionality in igb?
There was no lock, and yes, it was a bug.
> >> How about rate limiting at the PHC class driver level? And then it
> >> will work across the board for all the adapters at the device level.
> >
> > No, don't go there. Enough bikeshedding already. If you have a serious
>
> can a user without root privileges use get/adj/set time ioctls for the
> PHC functionality?
Depends on how you set the character device node permissions.
Thanks,
Richard
^ permalink raw reply
* [PATCH] iwlwifi: Add pr_fmt
From: Joe Perches @ 2012-03-26 15:27 UTC (permalink / raw)
To: Wey-Yi Guy, Intel Linux Wireless
Cc: John W. Linville, linux-wireless, netdev, linux-kernel
Prefix dmesg output with "iwlwifi: " by
adding #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/wireless/iwlwifi/iwl-agn.c | 3 +++
drivers/net/wireless/iwlwifi/iwl-pci.c | 3 +++
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn.c b/drivers/net/wireless/iwlwifi/iwl-agn.c
index f1226db..e09ffe0 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn.c
@@ -26,6 +26,9 @@
* Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497
*
*****************************************************************************/
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/init.h>
diff --git a/drivers/net/wireless/iwlwifi/iwl-pci.c b/drivers/net/wireless/iwlwifi/iwl-pci.c
index c5e339e..f3e56b0 100644
--- a/drivers/net/wireless/iwlwifi/iwl-pci.c
+++ b/drivers/net/wireless/iwlwifi/iwl-pci.c
@@ -60,6 +60,9 @@
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*
*****************************************************************************/
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include <linux/module.h>
#include <linux/pci.h>
#include <linux/pci-aspm.h>
--
1.7.8.111.gad25c.dirty
^ permalink raw reply related
* Re: [PATCH] net/garp: avoid infinite loop if attribute already exists
From: Jorge Boncompte [DTI2] @ 2012-03-26 15:26 UTC (permalink / raw)
To: david.ward; +Cc: netdev@vger.kernel.org
In-Reply-To: <4F707917.4020003@ll.mit.edu>
El 26/03/2012 16:11, Ward, David - 0663 - MITLL escribió:
> On 26/03/12 07:23, Jorge Boncompte [DTI2] wrote:
>> El 26/03/2012 0:43, David Ward escribió:
>>> An infinite loop occurred if garp_attr_create was called with the
>>> values of an existing attribute. Return -EEXIST instead.
>> I should have sent this some months ago but others things keep me from
>> doing it.
>> Anyway, I think that the right thing to do it's reuse the attribute to not
>> disturb the switch/network. Also, returning an error it's pointless because
>> nobody checks vlan_gvrp_request_join() return and you'll end up in a state where
>> the VLAN device has the GVRP flag but it's not announcing the attribute.
>
> I think what you are saying is that if we try to create an attribute that
> already exists, we should leave the old attribute alone. I agree with that, and
> the patch I sent does that. I also think the fact that the attribute existed
> would likely indicate a bug in the GARP application, in which we are not
> withdrawing an existing attribute when we should. Your patch warns on this
> condition.
The attribute it's still on the tree because the leave path it's called
asynchronously from a timer. As far as I could see there's no other code path
that can put an attribute on the tree twice and that's why I put the WARN_ON().
> Our patches are mostly the same. One thing I notice with your patch is that for
> new attributes, it now traverses the RB tree twice. And it doesn't free the
> memory for a new attribute if it wasn't inserted into the RB tree. So, what if
> instead I modified my patch to add "WARN_ON(err)" to either garp_request_join or
> vlan_gvrp_request_join? This would also warn us on -ENOMEM.
>
> David
>
>>
>> Please take a look at the conversation I had with Patrick in the patch
>> commit log.
>>
>> If you agree, I'm fine with you redoing your patch or David using mine if he
>> thinks it's ok.
>>
>> Regards,
>> Jorge
>>
>>> Signed-off-by: David Ward<david.ward@ll.mit.edu>
>>> ---
>>> net/802/garp.c | 18 +++++++++++++-----
>>> 1 files changed, 13 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/net/802/garp.c b/net/802/garp.c
>>> index 8e21b6d..bb5015e 100644
>>> --- a/net/802/garp.c
>>> +++ b/net/802/garp.c
>>> @@ -167,7 +167,7 @@ static struct garp_attr *garp_attr_lookup(const struct
>>> garp_applicant *app,
>>> return NULL;
>>> }
>>>
>>> -static void garp_attr_insert(struct garp_applicant *app, struct garp_attr *new)
>>> +static int garp_attr_insert(struct garp_applicant *app, struct garp_attr *new)
>>> {
>>> struct rb_node *parent = NULL, **p =&app->gid.rb_node;
>>> struct garp_attr *attr;
>>> @@ -181,24 +181,32 @@ static void garp_attr_insert(struct garp_applicant
>>> *app, struct garp_attr *new)
>>> p =&parent->rb_left;
>>> else if (d> 0)
>>> p =&parent->rb_right;
>>> + else
>>> + return -EEXIST;
>>> }
>>> rb_link_node(&new->node, parent, p);
>>> rb_insert_color(&new->node,&app->gid);
>>> + return 0;
>>> }
>>>
>>> static struct garp_attr *garp_attr_create(struct garp_applicant *app,
>>> const void *data, u8 len, u8 type)
>>> {
>>> struct garp_attr *attr;
>>> + int err;
>>>
>>> attr = kmalloc(sizeof(*attr) + len, GFP_ATOMIC);
>>> if (!attr)
>>> - return attr;
>>> + return PTR_ERR(-ENOMEM);
>>> attr->state = GARP_APPLICANT_VO;
>>> attr->type = type;
>>> attr->dlen = len;
>>> memcpy(attr->data, data, len);
>>> - garp_attr_insert(app, attr);
>>> + err = garp_attr_insert(app, attr);
>>> + if (err< 0) {
>>> + kfree(attr);
>>> + return PTR_ERR(err);
>>> + }
>>> return attr;
>>> }
>>>
>>> @@ -353,9 +361,9 @@ int garp_request_join(const struct net_device *dev,
>>>
>>> spin_lock_bh(&app->lock);
>>> attr = garp_attr_create(app, data, len, type);
>>> - if (!attr) {
>>> + if (IS_ERR(attr)) {
>>> spin_unlock_bh(&app->lock);
>>> - return -ENOMEM;
>>> + return ERR_PTR(attr);
>>> }
>>> garp_attr_event(app, attr, GARP_EVENT_REQ_JOIN);
>>> spin_unlock_bh(&app->lock);
>
^ permalink raw reply
* Re: [PATCH] net/vlan: withdraw VLAN ID attribute from GVRP on VLAN device stop
From: Jorge Boncompte [DTI2] @ 2012-03-26 15:14 UTC (permalink / raw)
To: david.ward; +Cc: netdev@vger.kernel.org
In-Reply-To: <4F707163.2000209@ll.mit.edu>
El 26/03/2012 15:38, Ward, David - 0663 - MITLL escribió:
> On 26/03/12 07:29, Jorge Boncompte [DTI2] wrote:
>> El 26/03/2012 0:43, David Ward escribió:
>>> When a VLAN device is stopped which has VLAN_FLAG_GVRP set, the VLAN
>>> ID attribute that was previously declared by GVRP must be withdrawn.
>>>
>> Hmm, maybe I am missing something but I think it only makes sense to withdrawn
>> the attribute when you delete the interface, and vlan_dev_stop() it's called if
>> you just put the interface down. It's better for the network convergence to not
>> signal the switches just for this. IMHO.
>
> If I bring a VLAN interface down, then I stop participating in the
> VLAN. If my NIC still receives traffic for the VLAN, I drop it. So to
> remove unnecessary load on the (potentially shared) network link and
> remove unnecessary local processing by the kernel of packets I know I am
> going to drop, I should tell the switch that I am no longer interested
> in receiving the VLAN traffic. Which is the whole point of GVRP. Right?
In the non-GVRP case, as far as i can see, you still receive the traffic for
that VLAN and the kernel drops it. Maybe is that I think that a downed interface
it's more a transient state, and administratively choosen one. If you don't want
to participate in that VLAN, you always can disable GVRP on it or delete the
interface.
> In any case, we currently register the attribute when the interface is
> brought up, not when it is created.
And that makes sense to me, if you have never uped the interface you have never
participated in that VLAN.
> However we do it, the attribute
> declaration/withdrawal should be symmetric.
>
>>
>>> Signed-off-by: David Ward<david.ward@ll.mit.edu>
>>> ---
>>> net/8021q/vlan_dev.c | 3 +++
>>> 1 files changed, 3 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
>>> index 9988d4a..df86dd0 100644
>>> --- a/net/8021q/vlan_dev.c
>>> +++ b/net/8021q/vlan_dev.c
>>> @@ -319,6 +319,9 @@ static int vlan_dev_stop(struct net_device *dev)
>>> struct vlan_dev_priv *vlan = vlan_dev_priv(dev);
>>> struct net_device *real_dev = vlan->real_dev;
>>>
>>> + if (vlan->flags& VLAN_FLAG_GVRP)
>>> + vlan_gvrp_request_leave(dev);
>>> +
>>> dev_mc_unsync(real_dev, dev);
>>> dev_uc_unsync(real_dev, dev);
>>> if (dev->flags& IFF_ALLMULTI)--
> 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 V4 2/2] igb: offer a PTP Hardware Clock instead of the timecompare method
From: chetan loke @ 2012-03-26 15:07 UTC (permalink / raw)
To: Richard Cochran
Cc: Keller, Jacob E, netdev@vger.kernel.org,
e1000-devel@lists.sourceforge.net, Kirsher, Jeffrey T,
Ronciak, John, john.stultz@linaro.org, tglx@linutronix.de
In-Reply-To: <20120324065147.GB2201@netboy.at.omicron.at>
On Sat, Mar 24, 2012 at 2:51 AM, Richard Cochran
<richardcochran@gmail.com> wrote:
> On Fri, Mar 23, 2012 at 03:39:08PM -0400, chetan loke wrote:
>>
>> So, how is it working today? Because we could have tx and rx
>> completions on different CPUs. Is it not possible to have the
>> following race today - between timecompare_update->timecompare_offset
>> -> timecounter_readdelta of say Rx and timecounter_cyc2time from Tx?
>
> I works (in the igb) because of the spinlock. You know, that thing
> that you are so against using.
>
I meant, was there a lock before the PHC functionality in igb?
>
>> How about rate limiting at the PHC class driver level? And then it
>> will work across the board for all the adapters at the device level.
>
> No, don't go there. Enough bikeshedding already. If you have a serious
can a user without root privileges use get/adj/set time ioctls for the
PHC functionality?
> Thanks,
> Richard
Chetan
^ 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