* Re: [PATCH] ehea: Remove sleep at .ndo_get_stats
From: David Miller @ 2011-09-27 4:47 UTC (permalink / raw)
To: eric.dumazet; +Cc: brenohl, netdev
In-Reply-To: <1317068935.2796.12.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 26 Sep 2011 22:28:55 +0200
> Le lundi 26 septembre 2011 à 17:11 -0300, brenohl@br.ibm.com a écrit :
>> Currently ehea ndo_get_stats can sleep in two places, in a hcall
>> and in a GFP_KERNEL alloc, which is not correct.
>> This patch creates a delayed workqueue that grabs the information each 1
>> sec from the hardware, and place it into the device structure, so that,
>> .ndo_get_stats quickly returns the device structure statistics block.
>>
>> Signed-off-by: Breno Leitao <brenohl@br.ibm.com>
>> ---
>
> Seems good, thanks
>
> Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [net-next 4/7] bna: Brocade 1860 HW Enablement
From: David Miller @ 2011-09-27 4:41 UTC (permalink / raw)
To: rmody; +Cc: netdev, adapter_linux_open_src_team, gkaraje
In-Reply-To: <1317071541-9662-5-git-send-email-rmody@brocade.com>
From: Rasesh Mody <rmody@brocade.com>
Date: Mon, 26 Sep 2011 14:12:18 -0700
> include/linux/pci_ids.h | 1 +
Please do not add new PCI device ID entries to linux/pci_ids.h
for use by a single device driver.
That header is only used when the PCI device ID will be used in
multiple drivers (such as network + iSCSI as some of the broadcom
drivers are).
^ permalink raw reply
* linux-next: manual merge of the net tree with the wireless-current tree
From: Stephen Rothwell @ 2011-09-27 2:51 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Johannes Berg, John W. Linville,
Wey-Yi Guy, Emmanuel Grumbach
Hi all,
Today's linux-next merge of the net tree got a conflict in
drivers/net/wireless/iwlwifi/iwl-scan.c between commit 6c80c39d9a69
("iwlagn: fix dangling scan request") from the wireless-current tree and
commits 63013ae30159 ("iwlagn: priv->status moves to iwl_shared") and
6ac2f839b0b2 ("iwlagn: priv->mutex moves to iwl_shared") from the net
tree.
I fixed it up (see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/net/wireless/iwlwifi/iwl-scan.c
index 77e528f,fc5af34..0000000
--- a/drivers/net/wireless/iwlwifi/iwl-scan.c
+++ b/drivers/net/wireless/iwlwifi/iwl-scan.c
@@@ -403,8 -413,19 +413,8 @@@ int iwl_mac_hw_scan(struct ieee80211_h
if (req->n_channels == 0)
return -EINVAL;
- mutex_lock(&priv->mutex);
+ mutex_lock(&priv->shrd->mutex);
- if (test_bit(STATUS_SCANNING, &priv->shrd->status) &&
- priv->scan_type != IWL_SCAN_NORMAL) {
- IWL_DEBUG_SCAN(priv, "Scan already in progress.\n");
- ret = -EAGAIN;
- goto out_unlock;
- }
-
- /* mac80211 will only ask for one band at a time */
- priv->scan_request = req;
- priv->scan_vif = vif;
-
/*
* If an internal scan is in progress, just set
* up the scan_request as per above.
@@@ -432,7 -439,8 +442,7 @@@
IWL_DEBUG_MAC80211(priv, "leave\n");
- mutex_unlock(&priv->mutex);
-out_unlock:
+ mutex_unlock(&priv->shrd->mutex);
return ret;
}
^ permalink raw reply
* Re: [PATCH] staging/octeon: Software should check the checksum of no tcp/udp packets
From: Ralf Baechle @ 2011-09-27 2:01 UTC (permalink / raw)
To: Greg KH; +Cc: David Daney, rongqing.li, netdev, David Miller, linux-mips
In-Reply-To: <20110927005127.GB10447@kroah.com>
On Mon, Sep 26, 2011 at 05:51:27PM -0700, Greg KH wrote:
> > This looks fine to me,
> >
> > Acked-by: David Daney <david.daney@cavium.com>
> >
> > I would let davem, Ralf and Greg KH fight over who gets to merge it.
>
> I'll let Ralf take it, unless he wants me to.
>
> Ralf?
Ok. Yes, that seems the best solution.
Ralf
^ permalink raw reply
* Re: [PATCH v3 4/7] per-cgroup tcp buffers control
From: Glauber Costa @ 2011-09-27 1:53 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: linux-kernel, paul, lizf, ebiederm, davem, gthelen, netdev,
linux-mm, kirill
In-Reply-To: <20110926195906.f1f5831c.kamezawa.hiroyu@jp.fujitsu.com>
On 09/26/2011 07:59 AM, KAMEZAWA Hiroyuki wrote:
> On Sun, 18 Sep 2011 21:56:42 -0300
> Glauber Costa<glommer@parallels.com> wrote:
>
>> With all the infrastructure in place, this patch implements
>> per-cgroup control for tcp memory pressure handling.
>>
>> Signed-off-by: Glauber Costa<glommer@parallels.com>
>> CC: David S. Miller<davem@davemloft.net>
>> CC: Hiroyouki Kamezawa<kamezawa.hiroyu@jp.fujitsu.com>
>> CC: Eric W. Biederman<ebiederm@xmission.com>
>
> a comment below.
>
>> +int tcp_init_cgroup(struct proto *prot, struct cgroup *cgrp,
>> + struct cgroup_subsys *ss)
>> +{
>> + struct mem_cgroup *cg = mem_cgroup_from_cont(cgrp);
>> + unsigned long limit;
>> +
>> + cg->tcp_memory_pressure = 0;
>> + atomic_long_set(&cg->tcp_memory_allocated, 0);
>> + percpu_counter_init(&cg->tcp_sockets_allocated, 0);
>> +
>> + limit = nr_free_buffer_pages() / 8;
>> + limit = max(limit, 128UL);
>> +
>> + cg->tcp_prot_mem[0] = sysctl_tcp_mem[0];
>> + cg->tcp_prot_mem[1] = sysctl_tcp_mem[1];
>> + cg->tcp_prot_mem[2] = sysctl_tcp_mem[2];
>> +
>
> Then, the parameter doesn't inherit parent's one ?
>
> I think sockets_populate should pass 'parent' and
>
>
> I think you should have a function
>
> mem_cgroup_should_inherit_parent_settings(parent)
>
> (This is because you made this feature as a part of memcg.
> please provide expected behavior.)
>
> Thanks,
> -Kame
Kame: Another look into this:
sysctl_tcp_mem is a global value, unless you have different namespaces.
So it is either global anyway, or should come from the namespace, not
the parent.
Now, the goal here is to set the maximum possible value for those
fields. That, indeed, should come from the parent.
That's my understanding...
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [net-next 02/10] ixgbevf: Fix broken trunk vlan
From: Jesse Gross @ 2011-09-27 0:54 UTC (permalink / raw)
To: Rose, Gregory V
Cc: Kirsher, Jeffrey T, davem@davemloft.net, netdev@vger.kernel.org,
gospo@redhat.com, Jiri Pirko
In-Reply-To: <43F901BD926A4E43B106BF17856F0755019C5E5B68@orsmsx508.amr.corp.intel.com>
On Mon, Sep 26, 2011 at 4:24 PM, Rose, Gregory V
<gregory.v.rose@intel.com> wrote:
>> -----Original Message-----
>> From: Jesse Gross [mailto:jesse@nicira.com]
>> Sent: Monday, September 26, 2011 4:09 PM
>> To: Rose, Gregory V
>> Cc: Kirsher, Jeffrey T; davem@davemloft.net; netdev@vger.kernel.org;
>> gospo@redhat.com; Jiri Pirko
>> Subject: Re: [net-next 02/10] ixgbevf: Fix broken trunk vlan
>>
>> On Mon, Sep 26, 2011 at 8:57 AM, Rose, Gregory V
>> <gregory.v.rose@intel.com> wrote:
>> >> -----Original Message-----
>> >> From: Jesse Gross [mailto:jesse@nicira.com]
>> >> Sent: Saturday, September 24, 2011 9:33 AM
>> >> To: Kirsher, Jeffrey T
>> >> Cc: davem@davemloft.net; Rose, Gregory V; netdev@vger.kernel.org;
>> >> gospo@redhat.com; Jiri Pirko
>> >> Subject: Re: [net-next 02/10] ixgbevf: Fix broken trunk vlan
>> >>
>> >> What happens if you run tcpdump without configuring vlan devices?
>> >> Shouldn't you see tagged packets for the vlans that are being trunked
>> >> to you? I think this will strip tags in that case. The apparent
>> >> behavior of vlan filters here is also surprising to me because on one
>> >> hand if they're truly filtering this test shouldn't be needed and on
>> >> the other hand they don't seem to be disabled in promiscuous mode.
>> >
>> > I think you're not quite understanding the action the HW is taking here.
>> In the physical function driver we have put the VF on a VLAN without it
>> knowing that it's on a VLAN. Once that is done by the PF, the VF is not
>> allowed to configure its own VLANs anymore. However, the descriptor still
>> includes a bit for the VLAN tag indicating it was a packet that arrived on
>> a VLAN. The HW is inserting and stripping the VLAN tag though without any
>> awareness of that by the VF driver.
>> >
>> > It's a security measure to allow an administrator to put a VF on a VLAN
>> to provide another level of isolation for the VF.
>> >
>> > Intel VFs don't support promiscuous mode. If you ran tcpdump you
>> wouldn't see the VLAN tags because they've been stripped by the HW. The
>> VF has no choice in this.
>>
>> I understand that VFs are limited in what they can do. What I'm
>> concerned about are differences in how the driver behaves when a vlan
>> device is configured on it vs. not. There are two cases that I think
>> you will see different behavior:
>>
>> * The VF driver has it's own vlan filters. I'm assuming (correct me
>> if I'm wrong) that this will further restrict the vlans that the guest
>> sees from the set that have been configured on the PF driver. If that
>> is correct, then putting the VF interface in promiscuous mode should
>> disable the filters and allow packets from all vlans that the PF
>> allows. This situation is the same as if an upstream physical switch
>> is trunking only a subset of vlans to an end host and the NIC is put
>> in promiscuous mode. However, it doesn't look like the VF driver does
>> anything in response to being in promiscuous mode. This shouldn't
>> require any hardware support because it is just clearing the filter
>> table.
>
> The VF does not have its own VLAN filters. It must request them through the PF via the mailbox messaging feature in the NIC. When the PF puts the VF in trunk VLAN mode via the 'ip link set <dev> vf <n> vlan <vlanid>' command then the PF also flags that VF and will not take VLAN filter requests from it. In effect, the VF is forced to a VLAN and has no choice. So it cannot further restrict what VLANs the guest sees. And the VF can only be on a single trunk VLAN, it does not support multiple trunk VLANs.
>
> And again, the VF doesn’t support promiscuous mode. The VF device HW doesn't have that feature.
>
>> * It looks like the VF driver is receiving not just an indication that
>> a tag was present but the actual tag and although it was already
>> stripped by the NIC it can be passed up to the network stack just as
>> if it was stripped in a non-SR-IOV NIC. After this patch, if you run
>> tcpdump on the VF interface you will see packets with tags if a vlan
>> device is configured but packets without tags if there is no vlan
>> device.
>>
>
> No. In trunk VLAN mode the receive descriptor provided by the HW has a VLAN tag present bit and that is set but unless someone has used vconfig to configure a VLAN and a bit is set for that VLAN in the active_vlans bit table then the packet is sent up the stack without the tag. Upper layers don't have access to the driver's internal descriptor rings and have no idea that the VLAN tag present bit was set in the descriptor. Upper layer SW in the network stack won't be looking for VLAN tags since it never requested any VLANs. And since the VLAN tag was stripped, and the upper layers haven't ever set a VLAN filter, then there is no expectation of a VLAN tag.
>
>> Does the VF know whether it is assigned to a particular vlan or is
>> allowed to send/receive tagged packets (essentially the difference
>> between an access port or a trunk port)?
>
> Yes, it knows if it has requested a VLAN filter via the active_vlans bit table. If no VLANs are set in the active_vlans table then it knows to ignore the VLAN tag present bit set in the descriptor since it must be in trunk VLAN mode.
>
>> Or is that why the presence
>> of vlan device is used as an indication?
>
> Correct, that is the case.
OK, maybe due to hardware limitations what I'm looking for just really
isn't possible. However, what I'm trying to emphasize is that vconfig
is not the only way that vlans can be consumed by the network stack
and active_vlans is just an indication of whether a vlan filter was
set, nothing more (perhaps I should have picked a better name when I
originally designed this stuff). In particular, it is not intended to
determine whether a tag should be stripped off or not because
non-vconfig users don't necessarily know which vlans they care about
(think tcpdump or trunking over a bridge). A major goal of the
existing vlan infrastructure is to avoid having drivers make
assumptions about the consumer of the tag and instead just hand all
information over to the network stack so it can behave in a consistent
manner. That's why I was looking for alternate ways to get this
information without depending on active_vlans as this driver behaves
quite a bit differently from others, include the ixgbe PF driver.
^ permalink raw reply
* Re: [PATCH] staging/octeon: Software should check the checksum of no tcp/udp packets
From: Greg KH @ 2011-09-27 0:51 UTC (permalink / raw)
To: David Daney; +Cc: rongqing.li, netdev, ralf, David Miller, linux-mips
In-Reply-To: <4E80D794.3040701@cavium.com>
On Mon, Sep 26, 2011 at 12:50:44PM -0700, David Daney wrote:
> On 09/25/2011 06:08 PM, rongqing.li@windriver.com wrote:
> >From: Roy.Li<rongqing.li@windriver.com>
> >
> >Icmp packets with wrong checksum are never dropped since
> >skb->ip_summed is set to CHECKSUM_UNNECESSARY.
> >
> >When icmp packets with wrong checksum pass through the octeon
> >net driver, the not_IP, IP_exc, L4_error hardware indicators
> >show no error. so the driver sets CHECKSUM_UNNECESSARY on
> >skb->ip_summed.
> >
> >L4_error only works for TCP/UDP, not for ICMP.
> >
> >Signed-off-by: Roy.Li<rongqing.li@windriver.com>
>
> We found the same problem, but have not yet sent the patch to fix it.
>
> This looks fine to me,
>
> Acked-by: David Daney <david.daney@cavium.com>
>
> I would let davem, Ralf and Greg KH fight over who gets to merge it.
I'll let Ralf take it, unless he wants me to.
Ralf?
^ permalink raw reply
* Re: intel 82599 multi-port performance
From: J.Hwan Kim @ 2011-09-27 0:45 UTC (permalink / raw)
To: Alexander Duyck; +Cc: netdev
In-Reply-To: <4E80A2AB.2040206@intel.com>
On 2011년 09월 27일 01:04, Alexander Duyck wrote:
> On 09/26/2011 08:42 AM, J.Hwan.Kim wrote:
>> On 2011년 09월 26일 23:20, Chris Friesen wrote:
>>> On 09/26/2011 04:26 AM, J.Hwan Kim wrote:
>>>> Hi, everyone
>>>>
>>>> Now, I'm testing a network card including intel 82599.
>>>> In our experiment, with the driver modified with ixgbe and multi-port
>>>> enabled,
>>>
>>> What do you mean by "modified with ixgbe and multi-port enabled"? You
>>> shouldn't need to do anything special to use both ports.
>>>
>>>> rx performance of each port with 10Gbps of 64bytes frame is
>>>> a half than when only 1 port is used.
>>>
>>> Sounds like a cpu limitation. What is your cpu usage? How are your
>>> interrupts routed? Are you using multiple rx queues?
>>>
>>
>> Our server is XEON 2.4GHz with 8 cores.
>> I'm using 4 RSS queues for each port and distributed it's interrupts
>> to different cores respectively.
>> I checked the CPU utilization with TOP, I guess ,it is not cpu
>> imitation problem.
>
> What kind of rates are you seeing on a single port versus multiple
> ports? There are multiple possibilities in terms of what could be
> limiting your performance.
>
I tested the 10G - 64byte frames.
With ixgbe-modified driver, in single port, 92% of packet received in
driver level and in 2 port we received around 42% packets.
> It sounds like you are using a single card, would that be correct?
Yes, I tested a single card with 2 ports.
> If you are running close to line rate on both ports this could be
> causing you to saturate the PCIe x8 link. If you have a second card
> available you may want to try installing that in a secondary Gen2 PCIe
> slot and seeing if you can improve the performance by using 2 PCIe
> slots instead of one.
I tested it also, if it is tested with 2 card, it seems that the
performance of each port is almost same with a single port. (maximum
performance)
^ permalink raw reply
* Re: Bridge stays down until a port is added
From: Stephen Hemminger @ 2011-09-27 0:43 UTC (permalink / raw)
To: Sven-Haegar Koch; +Cc: Nicolas de Pesloüan, Marc Haber, netdev
In-Reply-To: <alpine.DEB.2.02.1109270224220.30860@aurora>
On Tue, 27 Sep 2011 02:28:42 +0200 (CEST)
Sven-Haegar Koch <haegar@sdinet.de> wrote:
> On Tue, 27 Sep 2011, Nicolas de Pesloüan wrote:
>
> > Le 26/09/2011 22:05, Stephen Hemminger a écrit :
> > > On Mon, 26 Sep 2011 22:02:21 +0200
> > > Nicolas de Pesloüan<nicolas.2p.debian@gmail.com> wrote:
> > [...]
> > > > Stephen,
> > > >
> > > > What do you think about a generic per-interface option that would cause
> > > > bind() to accept tentative
> > > > address hold by a particular interface? This of course violate IPv6
> > > > principle, but we are talking
> > > > about interfaces that are unable to do DAD, either permanently or until
> > > > something happens on the
> > > > underlying device.
> > > >
> > > > echo 1> /sys/class/net/br0/allow_bind_on_tentative_address
> > > > echo 1> /sys/class/net/dummy0/allow_bind_on_tentative_address
> > > > echo 1> /sys/class/net/wlan0/allow_bind_on_tentative_address
> > > > and so on...
> > > >
> > > > And we may possibly automatically reset this option to 0 if DAD eventually
> > > > causes the address to be
> > > > considered duplicate.
> > >
> > > The issue is that if DAD rejects a duplicate, the socket is dead and
> > > application is
> > > out of luck.
> >
> > Yes, and this is by design. Setting the option would state "I want to allow
> > early bind(), prior to DAD and I assume the fact that a possible duplicate
> > address will cause the corresponding socket to be dead and so the using
> > application."
>
> How about a setting just completely disabling this
> duplicate-address-detection crap?
>
Already multiple ways to disable it:
1. Set /proc/sys/net/ipv6/XXX/accept_dad to 0
2. Set flag when assigning address with 'ip add add ... nodad'
3. Set IFF_NOARP on the interface (done by drivers)
^ permalink raw reply
* Re: intel 82599 multi-port performance
From: J.Hwan Kim @ 2011-09-27 0:39 UTC (permalink / raw)
To: Rick Jones; +Cc: netdev
In-Reply-To: <4E80C161.1040204@hp.com>
On 2011년 09월 27일 03:16, Rick Jones wrote:
> On 09/26/2011 08:42 AM, J.Hwan.Kim wrote:
>> On 2011년 09월 26일 23:20, Chris Friesen wrote:
>>> On 09/26/2011 04:26 AM, J.Hwan Kim wrote:
>>>> Hi, everyone
>>>>
>>>> Now, I'm testing a network card including intel 82599.
>>>> In our experiment, with the driver modified with ixgbe and multi-port
>>>> enabled,
>>>
>>> What do you mean by "modified with ixgbe and multi-port enabled"? You
>>> shouldn't need to do anything special to use both ports.
>>>
>>>> rx performance of each port with 10Gbps of 64bytes frame is
>>>> a half than when only 1 port is used.
>>>
>>> Sounds like a cpu limitation. What is your cpu usage? How are your
>>> interrupts routed? Are you using multiple rx queues?
>>>
>>
>> Our server is XEON 2.4GHz with 8 cores.
>> I'm using 4 RSS queues for each port and distributed it's interrupts to
>> different cores respectively.
>> I checked the CPU utilization with TOP, I guess ,it is not cpu imitation
>> problem.
>
> 99 times out of 10, by default top will show the average CPU
> utilization across all the "CPUs" of the system. So I will ask the
> pedantic question - Did you check per-CPU utilization or just overall?
>
I checked CPU utilization per CPU with top. I pressed "1" after
executing top so that I can view the per-cpu utilization.
^ permalink raw reply
* Re: Bridge stays down until a port is added
From: Sven-Haegar Koch @ 2011-09-27 0:28 UTC (permalink / raw)
To: Nicolas de Pesloüan; +Cc: Stephen Hemminger, Marc Haber, netdev
In-Reply-To: <4E80F8BD.4010401@gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1994 bytes --]
On Tue, 27 Sep 2011, Nicolas de Pesloüan wrote:
> Le 26/09/2011 22:05, Stephen Hemminger a écrit :
> > On Mon, 26 Sep 2011 22:02:21 +0200
> > Nicolas de Pesloüan<nicolas.2p.debian@gmail.com> wrote:
> [...]
> > > Stephen,
> > >
> > > What do you think about a generic per-interface option that would cause
> > > bind() to accept tentative
> > > address hold by a particular interface? This of course violate IPv6
> > > principle, but we are talking
> > > about interfaces that are unable to do DAD, either permanently or until
> > > something happens on the
> > > underlying device.
> > >
> > > echo 1> /sys/class/net/br0/allow_bind_on_tentative_address
> > > echo 1> /sys/class/net/dummy0/allow_bind_on_tentative_address
> > > echo 1> /sys/class/net/wlan0/allow_bind_on_tentative_address
> > > and so on...
> > >
> > > And we may possibly automatically reset this option to 0 if DAD eventually
> > > causes the address to be
> > > considered duplicate.
> >
> > The issue is that if DAD rejects a duplicate, the socket is dead and
> > application is
> > out of luck.
>
> Yes, and this is by design. Setting the option would state "I want to allow
> early bind(), prior to DAD and I assume the fact that a possible duplicate
> address will cause the corresponding socket to be dead and so the using
> application."
How about a setting just completely disabling this
duplicate-address-detection crap?
I do not want my servers to ever give up servicing a configured IP no
matter what else on the network tries to interfere.
If there are two machines using the same IP at a moment, then it may not
work so great, but both should have all their services up and running,
and once the invalid one got disconnected ("switch port down")
everything works - not needing to reboot the real one because some
daemons were not able to bind their service IPs.
c'ya
sven-haegar
--
Three may keep a secret, if two of them are dead.
- Ben F.
^ permalink raw reply
* [PATCH] Break up the single NBD lock into one per NBD device
From: H.K. Jerry Chu @ 2011-09-26 23:34 UTC (permalink / raw)
To: davem; +Cc: netdev, Jerry Chu
From: Jerry Chu <hkchu@google.com>
This patch breaks up the single NBD lock into one per
disk. The single NBD lock has become a serious performance
bottleneck when multiple NBD disks are being used.
The original comment on why a single lock may be ok no
longer holds for today's much faster NICs.
Signed-off-by: H.K. Jerry Chu <hkchu@google.com>
---
drivers/block/nbd.c | 22 +++++++++-------------
1 files changed, 9 insertions(+), 13 deletions(-)
diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index f533f33..355e15c 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -58,20 +58,9 @@ static unsigned int debugflags;
static unsigned int nbds_max = 16;
static struct nbd_device *nbd_dev;
+static spinlock_t *nbd_locks;
static int max_part;
-/*
- * Use just one lock (or at most 1 per NIC). Two arguments for this:
- * 1. Each NIC is essentially a synchronization point for all servers
- * accessed through that NIC so there's no need to have more locks
- * than NICs anyway.
- * 2. More locks lead to more "Dirty cache line bouncing" which will slow
- * down each lock to the point where they're actually slower than just
- * a single lock.
- * Thanks go to Jens Axboe and Al Viro for their LKML emails explaining this!
- */
-static DEFINE_SPINLOCK(nbd_lock);
-
#ifndef NDEBUG
static const char *ioctl_cmd_to_ascii(int cmd)
{
@@ -753,6 +742,12 @@ static int __init nbd_init(void)
if (!nbd_dev)
return -ENOMEM;
+ nbd_locks = kcalloc(nbds_max, sizeof(*nbd_locks), GFP_KERNEL);
+ if (!nbd_locks) {
+ kfree(nbd_dev);
+ return -ENOMEM;
+ }
+
part_shift = 0;
if (max_part > 0) {
part_shift = fls(max_part);
@@ -784,7 +779,7 @@ static int __init nbd_init(void)
* every gendisk to have its very own request_queue struct.
* These structs are big so we dynamically allocate them.
*/
- disk->queue = blk_init_queue(do_nbd_request, &nbd_lock);
+ disk->queue = blk_init_queue(do_nbd_request, &nbd_locks[i]);
if (!disk->queue) {
put_disk(disk);
goto out;
@@ -832,6 +827,7 @@ out:
put_disk(nbd_dev[i].disk);
}
kfree(nbd_dev);
+ kfree(nbd_locks);
return err;
}
--
1.7.3.1
^ permalink raw reply related
* RE: [net-next 02/10] ixgbevf: Fix broken trunk vlan
From: Rose, Gregory V @ 2011-09-26 23:24 UTC (permalink / raw)
To: Jesse Gross
Cc: Kirsher, Jeffrey T, davem@davemloft.net, netdev@vger.kernel.org,
gospo@redhat.com, Jiri Pirko
In-Reply-To: <CAEP_g=-xqgrS1hjApx5bPE2GFkAPJa6meaL0nmUcUbvSOPK-hQ@mail.gmail.com>
> -----Original Message-----
> From: Jesse Gross [mailto:jesse@nicira.com]
> Sent: Monday, September 26, 2011 4:09 PM
> To: Rose, Gregory V
> Cc: Kirsher, Jeffrey T; davem@davemloft.net; netdev@vger.kernel.org;
> gospo@redhat.com; Jiri Pirko
> Subject: Re: [net-next 02/10] ixgbevf: Fix broken trunk vlan
>
> On Mon, Sep 26, 2011 at 8:57 AM, Rose, Gregory V
> <gregory.v.rose@intel.com> wrote:
> >> -----Original Message-----
> >> From: Jesse Gross [mailto:jesse@nicira.com]
> >> Sent: Saturday, September 24, 2011 9:33 AM
> >> To: Kirsher, Jeffrey T
> >> Cc: davem@davemloft.net; Rose, Gregory V; netdev@vger.kernel.org;
> >> gospo@redhat.com; Jiri Pirko
> >> Subject: Re: [net-next 02/10] ixgbevf: Fix broken trunk vlan
> >>
> >> What happens if you run tcpdump without configuring vlan devices?
> >> Shouldn't you see tagged packets for the vlans that are being trunked
> >> to you? I think this will strip tags in that case. The apparent
> >> behavior of vlan filters here is also surprising to me because on one
> >> hand if they're truly filtering this test shouldn't be needed and on
> >> the other hand they don't seem to be disabled in promiscuous mode.
> >
> > I think you're not quite understanding the action the HW is taking here.
> In the physical function driver we have put the VF on a VLAN without it
> knowing that it's on a VLAN. Once that is done by the PF, the VF is not
> allowed to configure its own VLANs anymore. However, the descriptor still
> includes a bit for the VLAN tag indicating it was a packet that arrived on
> a VLAN. The HW is inserting and stripping the VLAN tag though without any
> awareness of that by the VF driver.
> >
> > It's a security measure to allow an administrator to put a VF on a VLAN
> to provide another level of isolation for the VF.
> >
> > Intel VFs don't support promiscuous mode. If you ran tcpdump you
> wouldn't see the VLAN tags because they've been stripped by the HW. The
> VF has no choice in this.
>
> I understand that VFs are limited in what they can do. What I'm
> concerned about are differences in how the driver behaves when a vlan
> device is configured on it vs. not. There are two cases that I think
> you will see different behavior:
>
> * The VF driver has it's own vlan filters. I'm assuming (correct me
> if I'm wrong) that this will further restrict the vlans that the guest
> sees from the set that have been configured on the PF driver. If that
> is correct, then putting the VF interface in promiscuous mode should
> disable the filters and allow packets from all vlans that the PF
> allows. This situation is the same as if an upstream physical switch
> is trunking only a subset of vlans to an end host and the NIC is put
> in promiscuous mode. However, it doesn't look like the VF driver does
> anything in response to being in promiscuous mode. This shouldn't
> require any hardware support because it is just clearing the filter
> table.
The VF does not have its own VLAN filters. It must request them through the PF via the mailbox messaging feature in the NIC. When the PF puts the VF in trunk VLAN mode via the 'ip link set <dev> vf <n> vlan <vlanid>' command then the PF also flags that VF and will not take VLAN filter requests from it. In effect, the VF is forced to a VLAN and has no choice. So it cannot further restrict what VLANs the guest sees. And the VF can only be on a single trunk VLAN, it does not support multiple trunk VLANs.
And again, the VF doesn’t support promiscuous mode. The VF device HW doesn't have that feature.
> * It looks like the VF driver is receiving not just an indication that
> a tag was present but the actual tag and although it was already
> stripped by the NIC it can be passed up to the network stack just as
> if it was stripped in a non-SR-IOV NIC. After this patch, if you run
> tcpdump on the VF interface you will see packets with tags if a vlan
> device is configured but packets without tags if there is no vlan
> device.
>
No. In trunk VLAN mode the receive descriptor provided by the HW has a VLAN tag present bit and that is set but unless someone has used vconfig to configure a VLAN and a bit is set for that VLAN in the active_vlans bit table then the packet is sent up the stack without the tag. Upper layers don't have access to the driver's internal descriptor rings and have no idea that the VLAN tag present bit was set in the descriptor. Upper layer SW in the network stack won't be looking for VLAN tags since it never requested any VLANs. And since the VLAN tag was stripped, and the upper layers haven't ever set a VLAN filter, then there is no expectation of a VLAN tag.
> Does the VF know whether it is assigned to a particular vlan or is
> allowed to send/receive tagged packets (essentially the difference
> between an access port or a trunk port)?
Yes, it knows if it has requested a VLAN filter via the active_vlans bit table. If no VLANs are set in the active_vlans table then it knows to ignore the VLAN tag present bit set in the descriptor since it must be in trunk VLAN mode.
> Or is that why the presence
> of vlan device is used as an indication?
Correct, that is the case.
- Greg
^ permalink raw reply
* Re: [PATCH v3 1/7] Basic kernel memory functionality for the Memory Controller
From: Glauber Costa @ 2011-09-26 23:18 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: linux-kernel, paul, lizf, ebiederm, davem, gthelen, netdev,
linux-mm, kirill
In-Reply-To: <20110926193451.b419f630.kamezawa.hiroyu@jp.fujitsu.com>
On 09/26/2011 07:34 AM, KAMEZAWA Hiroyuki wrote:
> On Sun, 18 Sep 2011 21:56:39 -0300
> Glauber Costa<glommer@parallels.com> wrote:
>
>> This patch lays down the foundation for the kernel memory component
>> of the Memory Controller.
>>
>> As of today, I am only laying down the following files:
>>
>> * memory.independent_kmem_limit
>> * memory.kmem.limit_in_bytes (currently ignored)
>> * memory.kmem.usage_in_bytes (always zero)
>>
>> Signed-off-by: Glauber Costa<glommer@parallels.com>
>> CC: Paul Menage<paul@paulmenage.org>
>> CC: Greg Thelen<gthelen@google.com>
>
> I'm sorry that my slow review is delaying you.
>
>
>> ---
>> Documentation/cgroups/memory.txt | 30 +++++++++-
>> init/Kconfig | 11 ++++
>> mm/memcontrol.c | 115 ++++++++++++++++++++++++++++++++++++--
>> 3 files changed, 148 insertions(+), 8 deletions(-)
>>
>> diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt
>> index 6f3c598..6f1954a 100644
>> --- a/Documentation/cgroups/memory.txt
>> +++ b/Documentation/cgroups/memory.txt
>> @@ -44,8 +44,9 @@ Features:
>> - oom-killer disable knob and oom-notifier
>> - Root cgroup has no limit controls.
>>
>> - Kernel memory and Hugepages are not under control yet. We just manage
>> - pages on LRU. To add more controls, we have to take care of performance.
>> + Hugepages is not under control yet. We just manage pages on LRU. To add more
>> + controls, we have to take care of performance. Kernel memory support is work
>> + in progress, and the current version provides basically functionality.
>>
>> Brief summary of control files.
>>
>> @@ -56,8 +57,11 @@ Brief summary of control files.
>> (See 5.5 for details)
>> memory.memsw.usage_in_bytes # show current res_counter usage for memory+Swap
>> (See 5.5 for details)
>> + memory.kmem.usage_in_bytes # show current res_counter usage for kmem only.
>> + (See 2.7 for details)
>> memory.limit_in_bytes # set/show limit of memory usage
>> memory.memsw.limit_in_bytes # set/show limit of memory+Swap usage
>> + memory.kmem.limit_in_bytes # if allowed, set/show limit of kernel memory
>> memory.failcnt # show the number of memory usage hits limits
>> memory.memsw.failcnt # show the number of memory+Swap hits limits
>> memory.max_usage_in_bytes # show max memory usage recorded
>> @@ -72,6 +76,9 @@ Brief summary of control files.
>> memory.oom_control # set/show oom controls.
>> memory.numa_stat # show the number of memory usage per numa node
>>
>> + memory.independent_kmem_limit # select whether or not kernel memory limits are
>> + independent of user limits
>> +
>> 1. History
>>
>> The memory controller has a long history. A request for comments for the memory
>> @@ -255,6 +262,25 @@ When oom event notifier is registered, event will be delivered.
>> per-zone-per-cgroup LRU (cgroup's private LRU) is just guarded by
>> zone->lru_lock, it has no lock of its own.
>>
>> +2.7 Kernel Memory Extension (CONFIG_CGROUP_MEM_RES_CTLR_KMEM)
>> +
>> + With the Kernel memory extension, the Memory Controller is able to limit
>> +the amount of kernel memory used by the system. Kernel memory is fundamentally
>> +different than user memory, since it can't be swapped out, which makes it
>> +possible to DoS the system by consuming too much of this precious resource.
>> +Kernel memory limits are not imposed for the root cgroup.
>> +
>> +Memory limits as specified by the standard Memory Controller may or may not
>> +take kernel memory into consideration. This is achieved through the file
>> +memory.independent_kmem_limit. A Value different than 0 will allow for kernel
>> +memory to be controlled separately.
>> +
>> +When kernel memory limits are not independent, the limit values set in
>> +memory.kmem files are ignored.
>> +
>> +Currently no soft limit is implemented for kernel memory. It is future work
>> +to trigger slab reclaim when those limits are reached.
>> +
>> 3. User Interface
>>
>> 0. Configuration
>> diff --git a/init/Kconfig b/init/Kconfig
>> index d627783..49e5839 100644
>> --- a/init/Kconfig
>> +++ b/init/Kconfig
>> @@ -689,6 +689,17 @@ config CGROUP_MEM_RES_CTLR_SWAP_ENABLED
>> For those who want to have the feature enabled by default should
>> select this option (if, for some reason, they need to disable it
>> then swapaccount=0 does the trick).
>> +config CGROUP_MEM_RES_CTLR_KMEM
>> + bool "Memory Resource Controller Kernel Memory accounting"
>> + depends on CGROUP_MEM_RES_CTLR
>> + default y
>> + help
>> + The Kernel Memory extension for Memory Resource Controller can limit
>> + the amount of memory used by kernel objects in the system. Those are
>> + fundamentally different from the entities handled by the standard
>> + Memory Controller, which are page-based, and can be swapped. Users of
>> + the kmem extension can use it to guarantee that no group of processes
>> + will ever exhaust kernel resources alone.
>>
>> config CGROUP_PERF
>> bool "Enable perf_event per-cpu per-container group (cgroup) monitoring"
>> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
>> index ebd1e86..d32e931 100644
>> --- a/mm/memcontrol.c
>> +++ b/mm/memcontrol.c
>> @@ -73,7 +73,11 @@ static int really_do_swap_account __initdata = 0;
>> #define do_swap_account (0)
>> #endif
>>
>> -
>> +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
>> +int do_kmem_account __read_mostly = 1;
>> +#else
>> +#define do_kmem_account 0
>> +#endif
>
>
> Hmm, do we really need this boot option ?
> From my experience to have swap-accounting boot option,
> this scares us ;) I think config is enough.
>
>
>
>
>> /*
>> * Statistics for memory cgroup.
>> */
>> @@ -270,6 +274,10 @@ struct mem_cgroup {
>> */
>> struct res_counter memsw;
>> /*
>> + * the counter to account for kmem usage.
>> + */
>> + struct res_counter kmem;
>> + /*
>> * Per cgroup active and inactive list, similar to the
>> * per zone LRU lists.
>> */
>> @@ -321,6 +329,11 @@ struct mem_cgroup {
>> */
>> unsigned long move_charge_at_immigrate;
>> /*
>> + * Should kernel memory limits be stabilished independently
>> + * from user memory ?
>> + */
>> + int kmem_independent;
>> + /*
>> * percpu counter.
>> */
>> struct mem_cgroup_stat_cpu *stat;
>> @@ -388,9 +401,14 @@ enum charge_type {
>> };
>>
>> /* for encoding cft->private value on file */
>> -#define _MEM (0)
>> -#define _MEMSWAP (1)
>> -#define _OOM_TYPE (2)
>> +
>> +enum mem_type {
>> + _MEM = 0,
>> + _MEMSWAP,
>> + _OOM_TYPE,
>> + _KMEM,
>> +};
>> +
>
> ok, nice clean up.
>
>
>> #define MEMFILE_PRIVATE(x, val) (((x)<< 16) | (val))
>> #define MEMFILE_TYPE(val) (((val)>> 16)& 0xffff)
>> #define MEMFILE_ATTR(val) ((val)& 0xffff)
>> @@ -3943,10 +3961,15 @@ static inline u64 mem_cgroup_usage(struct mem_cgroup *mem, bool swap)
>> u64 val;
>>
>> if (!mem_cgroup_is_root(mem)) {
>> + val = 0;
>> + if (!mem->kmem_independent)
>> + val = res_counter_read_u64(&mem->kmem, RES_USAGE);
>
>> if (!swap)
>> - return res_counter_read_u64(&mem->res, RES_USAGE);
>> + val += res_counter_read_u64(&mem->res, RES_USAGE);
>> else
>> - return res_counter_read_u64(&mem->memsw, RES_USAGE);
>> + val += res_counter_read_u64(&mem->memsw, RES_USAGE);
>> +
>> + return val;
>> }
>>
>> val = mem_cgroup_recursive_stat(mem, MEM_CGROUP_STAT_CACHE);
>> @@ -3979,6 +4002,10 @@ static u64 mem_cgroup_read(struct cgroup *cont, struct cftype *cft)
>> else
>> val = res_counter_read_u64(&mem->memsw, name);
>> break;
>> + case _KMEM:
>> + val = res_counter_read_u64(&mem->kmem, name);
>> + break;
>> +
>> default:
>> BUG();
>> break;
>> @@ -4756,6 +4783,21 @@ static int mem_cgroup_reset_vmscan_stat(struct cgroup *cgrp,
>> return 0;
>> }
>>
>> +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
>> +static u64 kmem_limit_independent_read(struct cgroup *cont, struct cftype *cft)
>> +{
>> + return mem_cgroup_from_cont(cont)->kmem_independent;
>> +}
>> +
>> +static int kmem_limit_independent_write(struct cgroup *cont, struct cftype *cft,
>> + u64 val)
>> +{
>> + cgroup_lock();
>> + mem_cgroup_from_cont(cont)->kmem_independent = !!val;
>> + cgroup_unlock();
>
> Hm. This code allows that parent/child can have different settings.
> Could you add parent-child check as..
>
> "If parent sets use_hierarchy==1, children must have the same kmem_independent value
> with parant's one."
>
> How do you think ? I think a hierarchy must have the same config.
BTW, Kame:
Look again (I forgot myself when I first replied to you)
Only in the root cgroup those files get registered.
So shouldn't be a problem, because children won't even
be able to see them.
Do you agree with this ?
>
> BTW...I don't like naming a little ;)
>
> memory->consolidated/shared/?????_kmem_accounting ?
> Or
> memory->kmem_independent_accounting ?
>
> or some better naming ?
>
> Thanks,
> -Kame
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [net-next 02/10] ixgbevf: Fix broken trunk vlan
From: Jesse Gross @ 2011-09-26 23:08 UTC (permalink / raw)
To: Rose, Gregory V
Cc: Kirsher, Jeffrey T, davem@davemloft.net, netdev@vger.kernel.org,
gospo@redhat.com, Jiri Pirko
In-Reply-To: <43F901BD926A4E43B106BF17856F0755019C519319@orsmsx508.amr.corp.intel.com>
On Mon, Sep 26, 2011 at 8:57 AM, Rose, Gregory V
<gregory.v.rose@intel.com> wrote:
>> -----Original Message-----
>> From: Jesse Gross [mailto:jesse@nicira.com]
>> Sent: Saturday, September 24, 2011 9:33 AM
>> To: Kirsher, Jeffrey T
>> Cc: davem@davemloft.net; Rose, Gregory V; netdev@vger.kernel.org;
>> gospo@redhat.com; Jiri Pirko
>> Subject: Re: [net-next 02/10] ixgbevf: Fix broken trunk vlan
>>
>> On Sat, Sep 24, 2011 at 2:17 AM, Jeff Kirsher
>> <jeffrey.t.kirsher@intel.com> wrote:
>> > From: Greg Rose <gregory.v.rose@intel.com>
>> >
>> > Changes to clean up the vlan rx path broke trunk vlan. Trunk vlans in
>> > a VF driver are those set using:
>> >
>> > "ip link set <pfdev> vf <n> <vlanid>"
>> >
>> > Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
>> > CC: Jiri Pirko <jpirko@redhat.com>
>> > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>> > ---
>> > drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 6 ++----
>> > 1 files changed, 2 insertions(+), 4 deletions(-)
>> >
>> > diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
>> b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
>> > index d72905b..4930c46 100644
>> > --- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
>> > +++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
>> > @@ -293,12 +293,10 @@ static void ixgbevf_receive_skb(struct
>> ixgbevf_q_vector *q_vector,
>> > {
>> > struct ixgbevf_adapter *adapter = q_vector->adapter;
>> > bool is_vlan = (status & IXGBE_RXD_STAT_VP);
>> > + u16 tag = le16_to_cpu(rx_desc->wb.upper.vlan);
>> >
>> > - if (is_vlan) {
>> > - u16 tag = le16_to_cpu(rx_desc->wb.upper.vlan);
>> > -
>> > + if (is_vlan && test_bit(tag, adapter->active_vlans))
>> > __vlan_hwaccel_put_tag(skb, tag);
>> > - }
>>
>> What happens if you run tcpdump without configuring vlan devices?
>> Shouldn't you see tagged packets for the vlans that are being trunked
>> to you? I think this will strip tags in that case. The apparent
>> behavior of vlan filters here is also surprising to me because on one
>> hand if they're truly filtering this test shouldn't be needed and on
>> the other hand they don't seem to be disabled in promiscuous mode.
>
> I think you're not quite understanding the action the HW is taking here. In the physical function driver we have put the VF on a VLAN without it knowing that it's on a VLAN. Once that is done by the PF, the VF is not allowed to configure its own VLANs anymore. However, the descriptor still includes a bit for the VLAN tag indicating it was a packet that arrived on a VLAN. The HW is inserting and stripping the VLAN tag though without any awareness of that by the VF driver.
>
> It's a security measure to allow an administrator to put a VF on a VLAN to provide another level of isolation for the VF.
>
> Intel VFs don't support promiscuous mode. If you ran tcpdump you wouldn't see the VLAN tags because they've been stripped by the HW. The VF has no choice in this.
I understand that VFs are limited in what they can do. What I'm
concerned about are differences in how the driver behaves when a vlan
device is configured on it vs. not. There are two cases that I think
you will see different behavior:
* The VF driver has it's own vlan filters. I'm assuming (correct me
if I'm wrong) that this will further restrict the vlans that the guest
sees from the set that have been configured on the PF driver. If that
is correct, then putting the VF interface in promiscuous mode should
disable the filters and allow packets from all vlans that the PF
allows. This situation is the same as if an upstream physical switch
is trunking only a subset of vlans to an end host and the NIC is put
in promiscuous mode. However, it doesn't look like the VF driver does
anything in response to being in promiscuous mode. This shouldn't
require any hardware support because it is just clearing the filter
table.
* It looks like the VF driver is receiving not just an indication that
a tag was present but the actual tag and although it was already
stripped by the NIC it can be passed up to the network stack just as
if it was stripped in a non-SR-IOV NIC. After this patch, if you run
tcpdump on the VF interface you will see packets with tags if a vlan
device is configured but packets without tags if there is no vlan
device.
Does the VF know whether it is assigned to a particular vlan or is
allowed to send/receive tagged packets (essentially the difference
between an access port or a trunk port)? Or is that why the presence
of vlan device is used as an indication?
^ permalink raw reply
* RE: [net-next-2.6 PATCH 0/3 RFC] macvlan: MAC Address filtering support for passthru mode
From: Christian Benvenuti (benve) @ 2011-09-26 23:06 UTC (permalink / raw)
To: Roopa Prabhu (roprabhu), Michael S. Tsirkin
Cc: Sridhar Samudrala, netdev, dragos.tatulea, arnd,
David Wang (dwang2), kaber, davem, eric.dumazet, mchan, kvm
In-Reply-To: <CA974FD6.343A2%roprabhu@cisco.com>
> -----Original Message-----
> From: Roopa Prabhu (roprabhu)
> Sent: Thursday, September 15, 2011 6:47 AM
> To: Michael S. Tsirkin
> Cc: Sridhar Samudrala; netdev@vger.kernel.org;
> dragos.tatulea@gmail.com; arnd@arndb.de; David Wang (dwang2);
Christian
> Benvenuti (benve); kaber@trash.net; davem@davemloft.net;
> eric.dumazet@gmail.com; mchan@broadcom.com; kvm@vger.kernel.org
> Subject: Re: [net-next-2.6 PATCH 0/3 RFC] macvlan: MAC Address
> filtering support for passthru mode
>
>
>
> The netlink patch is still in the works. I will post the patches after
> I
> clean it up a bit and also accommodate or find answers to most
> questions
> discussed for non-passthru case. Thought I will post the netlink
> interface
> here to see if anyone has any early comments. I have a
> rtnl_link_ops->set_rx_filter defined.
>
> [IFLA_RX_FILTER] = {
> [IFLA_ADDRESS_FILTER] = {
> [IFLA_ADDRESS_FILTER_FLAGS]
> [IFLA_ADDRESS_LIST] = {
> [IFLA_ADDRESS_LIST_ENTRY]
> }
> }
> [IFLA_VLAN_FILTER] = {
> [IFLA_VLAN_LIST] = {
> [IFLA_VLAN]
> }
> }
> }
>
> Some open questions:
> - The VLAN filter above shows a VLAN list. It could also be a
> bitmap or
> the interface could provide both a bitmap and VLAN list for more
> flexibility
> . Like the below
>
> [IFLA_RX_FILTER] = {
> [IFLA_ADDRESS_FILTER] = {
> [IFLA_ADDRESS_FILTER_FLAGS]
> [IFLA_ADDRESS_LIST] = {
> [IFLA_ADDRESS_LIST_ENTRY]
> }
> }
> [IFLA_VLAN_FILTER] = {
> [IFLA_VLAN_BITMAP]
> [IFLA_VLAN_LIST] = {
> [IFLA_VLAN]
> }
> }
> }
The simplest interface probably is to stick to a bitmap (knowing that in
the worst
case it will take 256 bytes, but we can compress it ...), because
sending
a vlan list may end up requiring much more than that (on interfaces
configured as trunks).
This regardless of whether the most common use case is that of a server
configured
with just few vlans or that of a switch configured with few trunks.
Another option would be a list of ranges, but that one would not work
well
in those cases where trunks are configured, for example, to carry big
numbers
of odd or even vlan IDs or other groups of vlans IDs that cannot be
grouped
into ranges. Probably an acceptable compromise, if we care about the
size
of this attribute, would be:
- to use a list of IDs for less than 256 vlans (or a list of ranges)
- to use a bitmap for more than 256 vlan.
I would recommend the two attributes (IFLA_VLAN_BITMAP and
IFLA_VLAN_LIST)
to be mutually exclusive to reduce the complexity of the merging and
error/misconfig detection code.
> - Do you see any advantage in keeping Unicast and multicast
address
> list
> separate ? Something like the below :
> [IFLA_RX_FILTER] = {
> [IFLA_ADDRESS_FILTER_FLAGS]
> [IFLA_UC_ADDRESS_FILTER] = {
> [IFLA_ADDRESS_LIST] = {
> [IFLA_ADDRESS_LIST_ENTRY]
> }
> }
> [IFLA_MC_ADDRESS_FILTER] = {
> [IFLA_ADDRESS_LIST] = {
> [IFLA_ADDRESS_LIST_ENTRY]
> }
> }
> [IFLA_VLAN_FILTER] = {
> [IFLA_VLAN_LIST] = {
> [IFLA_VLAN]
> }
> }
> }
I personally like the idea of grouping UC and MC addresses into two
distinct
attributes/groups.
The receiver (the kernel) would have to check them anyway (I suppose),
but
I like the idea of having the kernel being able to detect the case
where, for
example, the user configures a MC address thinking he is actually
configuring
a UC address.
Most probably the iproute2 commands used to configure/add/del UC and MC
address
will be assigned two different keywords.
BTW, once this code will be in, it will be possible for "ip link show"
to show
all UC/MC MAC addresses; right now "ip link" only shows dev->dev_addr.
This output is useful for debugging.
The output from "ip maddr" only shows the MC list and anyway I think the
best
place for the list of MAC addresses is "ip link show".
Would "ip link show" also show the list of vlans?
Probably, best would be to add new flags (to ask for the extended
output) or
simply add the extra output (uc/mc/vlan lists) under the already
existent "-s" flag ?
> - Is there any need to keep address and vlan filters separate. And
> have
> two rtnl_link_ops, set_rx_address_filter, set_rx_vlan_filter ?. I
don't
> see
> one .
>
> [IFLA_RX_ADDRESS_FILTER] = {
> [IFLA_ADDRESS_FILTER_FLAGS]
> [IFLA_ADDRESS_LIST] = {
> [IFLA_ADDRESS_LIST_ENTRY]
> }
> }
> [IFLA_RX_VLAN_FILTER] = {
> [IFLA_VLAN_LIST] = {
> [IFLA_VLAN]
> }
> }
I think both approaches are good.
Anyway, given that you can have/configure nested vlans, having
IFLA_RX_VLAN_FILTER
inside IFLA_RX_FILTER would be syntactically correct too.
/Chris
> Thanks,
> Roopa
>
>
>
> On 9/12/11 10:02 AM, "Roopa Prabhu" <roprabhu@cisco.com> wrote:
>
> >
> >
> >
> > On 9/11/11 12:03 PM, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> >
> >> On Sun, Sep 11, 2011 at 06:18:01AM -0700, Roopa Prabhu wrote:
> >>>
> >>>
> >>>
> >>> On 9/11/11 2:44 AM, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> >>>
> >>>>
> >>>> Yes, but what I mean is, if the size of the single filter table
> >>>> is limited, we need to decide how many addresses is
> >>>> each guest allowed. If we let one guest ask for
> >>>> as many as it wants, it can lock others out.
> >>>
> >>> Yes true. In these cases ie when the number of unicast addresses
> being
> >>> registered is more than it can handle, The VF driver will put the
> VF in
> >>> promiscuous mode (Or at least its supposed to do. I think all
> drivers do
> >>> that).
> >>>
> >>>
> >>> Thanks,
> >>> Roopa
> >>
> >> Right, so that works at least but likely performs worse
> >> than a hardware filter. So we better allocate it in
> >> some fair way, as a minimum. Maybe a way for
> >> the admin to control that allocation is useful.
> >
> > Yes I think we will have to do something like that. There is a
> maximum that hw
> > can support. Might need to consider that too. But there is no
> interface to get
> > that today. I think the virtualization case gets a little trickier.
> Virtio-net
> > allows upto 64 unicast addresses. But the lowerdev may allow only
> upto say 10
> > unicast addresses (I think intel supports 10 unicast addresses on
the
> VF). Am
> > not sure if there is a good way to notify the guest of blocked
> addresses.
> > Maybe putting the lower dev in promiscuous mode could be a policy
> decision too
> > in this case.
> >
> > One other thing, I had indicated that I will look up details on
> opening my
> > patch for non-passthru to enable hw filtering (without adding
> filtering
> > support in macvlan right away. Ie phase1). Turns out in current code
> in
> > macvlan_handle_frame, for non-passthru case, it does not fwd unicast
> pkts
> > destined to macs other than the ones in macvlan hash. So a filter or
> hash
> > lookup there for additional unicast addresses needs to be definitely
> added for
> > non-passthru.
> >
> > Thanks,
> > Roopa
> >
> >
> >
^ permalink raw reply
* Re: [PATCH v3 4/7] per-cgroup tcp buffers control
From: Glauber Costa @ 2011-09-26 22:52 UTC (permalink / raw)
To: avagin
Cc: linux-kernel, paul, lizf, kamezawa.hiroyu, ebiederm, davem,
gthelen, netdev, linux-mm, kirill
In-Reply-To: <4E808EA6.4000301@gmail.com>
On 09/26/2011 11:39 AM, Andrew Vagin wrote:
> We can't change net.ipv4.tcp_mem if a cgroup with memory controller
> isn't mounted.
>
> [root@dhcp-10-30-20-19 ~]# sysctl -w net.ipv4.tcp_mem="3 2 3"
> error: "Invalid argument" setting key "net.ipv4.tcp_mem"
>
> It's because tcp_max_memory is initialized in mem_cgroup_populate:
>
> mem_cgroup_populate->register_kmem_files->sockets_populate->tcp_init_cgroup
Thank you, will fix it
>> +int sockets_populate(struct cgroup *cgrp, struct cgroup_subsys *ss)
>> +{
>> + struct proto *proto;
>> + int ret = 0;
>> +
>> + read_lock(&proto_list_lock);
>> + list_for_each_entry(proto,&proto_list, node) {
>> + if (proto->init_cgroup)
>> + ret |= proto->init_cgroup(proto, cgrp, ss);
>> + }
>> + if (!ret)
>> + goto out;
>> +
>> + list_for_each_entry_continue_reverse(proto,&proto_list, node)
>> + if (proto->destroy_cgroup)
>> + proto->destroy_cgroup(proto, cgrp, ss);
>> +
>> +out:
>> + read_unlock(&proto_list_lock);
>> + return ret;
>> +}
>
>> @@ -198,6 +203,21 @@ static int ipv4_tcp_mem(ctl_table *ctl, int write,
>> if (ret)
>> return ret;
>>
>> +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
>> + rcu_read_lock();
>> + cg = mem_cgroup_from_task(current);
>> + for (i = 0; i< 3; i++)
>> + if (vec[i]> tcp_max_memory(cg)) {
>> + rcu_read_unlock();
>> + return -EINVAL;
>> + }
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v3 6/7] tcp buffer limitation: per-cgroup limit
From: Glauber Costa @ 2011-09-26 22:49 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: Greg Thelen, linux-kernel, paul, lizf, ebiederm, davem, netdev,
linux-mm, kirill
In-Reply-To: <20110926200247.c80f7e47.kamezawa.hiroyu@jp.fujitsu.com>
On 09/26/2011 08:02 AM, KAMEZAWA Hiroyuki wrote:
> On Sat, 24 Sep 2011 10:30:42 -0300
> Glauber Costa<glommer@parallels.com> wrote:
>
>> On 09/22/2011 03:01 AM, Greg Thelen wrote:
>>> On Sun, Sep 18, 2011 at 5:56 PM, Glauber Costa<glommer@parallels.com> wrote:
>>>> +static inline bool mem_cgroup_is_root(struct mem_cgroup *mem)
>>>> +{
>>>> + return (mem == root_mem_cgroup);
>>>> +}
>>>> +
>>>
>>> Why are you adding a copy of mem_cgroup_is_root(). I see one already
>>> in v3.0. Was it deleted in a previous patch?
>>
>> Already answered by another good samaritan.
>>
>>>> +static int tcp_write_maxmem(struct cgroup *cgrp, struct cftype *cft, u64 val)
>>>> +{
>>>> + struct mem_cgroup *sg = mem_cgroup_from_cont(cgrp);
>>>> + struct mem_cgroup *parent = parent_mem_cgroup(sg);
>>>> + struct net *net = current->nsproxy->net_ns;
>>>> + int i;
>>>> +
>>>> + if (!cgroup_lock_live_group(cgrp))
>>>> + return -ENODEV;
>>>
>>> Why is cgroup_lock_live_cgroup() needed here? Does it protect updates
>>> to sg->tcp_prot_mem[*]?
>>>
>>>> +static u64 tcp_read_maxmem(struct cgroup *cgrp, struct cftype *cft)
>>>> +{
>>>> + struct mem_cgroup *sg = mem_cgroup_from_cont(cgrp);
>>>> + u64 ret;
>>>> +
>>>> + if (!cgroup_lock_live_group(cgrp))
>>>> + return -ENODEV;
>>>
>>> Why is cgroup_lock_live_cgroup() needed here? Does it protect updates
>>> to sg->tcp_max_memory?
>>
>> No, that is not my understanding. My understanding is this lock is
>> needed to protect against the cgroup just disappearing under our nose.
>>
>
> Hm. reference count of dentry for cgroup isn't enough ?
>
> Thanks,
> -Kame
>
think think think think think think...
Yeah, I guess it is.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v3 4/7] per-cgroup tcp buffers control
From: Glauber Costa @ 2011-09-26 22:48 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: linux-kernel, paul, lizf, ebiederm, davem, gthelen, netdev,
linux-mm, kirill
In-Reply-To: <20110926195906.f1f5831c.kamezawa.hiroyu@jp.fujitsu.com>
On 09/26/2011 07:59 AM, KAMEZAWA Hiroyuki wrote:
> On Sun, 18 Sep 2011 21:56:42 -0300
> Glauber Costa<glommer@parallels.com> wrote:
>
>> With all the infrastructure in place, this patch implements
>> per-cgroup control for tcp memory pressure handling.
>>
>> Signed-off-by: Glauber Costa<glommer@parallels.com>
>> CC: David S. Miller<davem@davemloft.net>
>> CC: Hiroyouki Kamezawa<kamezawa.hiroyu@jp.fujitsu.com>
>> CC: Eric W. Biederman<ebiederm@xmission.com>
>
> a comment below.
>
>> +int tcp_init_cgroup(struct proto *prot, struct cgroup *cgrp,
>> + struct cgroup_subsys *ss)
>> +{
>> + struct mem_cgroup *cg = mem_cgroup_from_cont(cgrp);
>> + unsigned long limit;
>> +
>> + cg->tcp_memory_pressure = 0;
>> + atomic_long_set(&cg->tcp_memory_allocated, 0);
>> + percpu_counter_init(&cg->tcp_sockets_allocated, 0);
>> +
>> + limit = nr_free_buffer_pages() / 8;
>> + limit = max(limit, 128UL);
>> +
>> + cg->tcp_prot_mem[0] = sysctl_tcp_mem[0];
>> + cg->tcp_prot_mem[1] = sysctl_tcp_mem[1];
>> + cg->tcp_prot_mem[2] = sysctl_tcp_mem[2];
>> +
>
> Then, the parameter doesn't inherit parent's one ?
>
> I think sockets_populate should pass 'parent' and
>
>
> I think you should have a function
>
> mem_cgroup_should_inherit_parent_settings(parent)
>
> (This is because you made this feature as a part of memcg.
> please provide expected behavior.)
>
All right Kame, will do.
Thanks.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v3 2/7] socket: initial cgroup code.
From: Glauber Costa @ 2011-09-26 22:47 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: Balbir Singh, Greg Thelen, linux-kernel, paul, lizf, ebiederm,
davem, netdev, linux-mm, kirill
In-Reply-To: <20110926195213.12da87b4.kamezawa.hiroyu@jp.fujitsu.com>
On 09/26/2011 07:52 AM, KAMEZAWA Hiroyuki wrote:
> On Sat, 24 Sep 2011 11:45:04 -0300
> Glauber Costa<glommer@parallels.com> wrote:
>
>> On 09/22/2011 12:09 PM, Balbir Singh wrote:
>>> On Thu, Sep 22, 2011 at 11:30 AM, Greg Thelen<gthelen@google.com> wrote:
>>>> On Wed, Sep 21, 2011 at 11:59 AM, Glauber Costa<glommer@parallels.com> wrote:
>>>>> Right now I am working under the assumption that tasks are long lived inside
>>>>> the cgroup. Migration potentially introduces some nasty locking problems in
>>>>> the mem_schedule path.
>>>>>
>>>>> Also, unless I am missing something, the memcg already has the policy of
>>>>> not carrying charges around, probably because of this very same complexity.
>>>>>
>>>>> True that at least it won't EBUSY you... But I think this is at least a way
>>>>> to guarantee that the cgroup under our nose won't disappear in the middle of
>>>>> our allocations.
>>>>
>>>> Here's the memcg user page behavior using the same pattern:
>>>>
>>>> 1. user page P is allocate by task T in memcg M1
>>>> 2. T is moved to memcg M2. The P charge is left behind still charged
>>>> to M1 if memory.move_charge_at_immigrate=0; or the charge is moved to
>>>> M2 if memory.move_charge_at_immigrate=1.
>>>> 3. rmdir M1 will try to reclaim P (if P was left in M1). If unable to
>>>> reclaim, then P is recharged to parent(M1).
>>>>
>>>
>>> We also have some magic in page_referenced() to remove pages
>>> referenced from different containers. What we do is try not to
>>> penalize a cgroup if another cgroup is referencing this page and the
>>> page under consideration is being reclaimed from the cgroup that
>>> touched it.
>>>
>>> Balbir Singh
>> Do you guys see it as a showstopper for this series to be merged, or can
>> we just TODO it ?
>>
>
> In my experience, 'I can't rmdir cgroup.' is always an important/difficult
> problem. The users cannot know where the accouting is leaking other than
> kmem.usage_in_bytes or memory.usage_in_bytes. and can't fix the issue.
>
> please add EXPERIMENTAL to Kconfig until this is fixed.
I am working on something here that may allow it.
But I think it is independent of the rest, and I can repost the series
fixing the problems raised here without it, + EXPERIMENTAL.
Btw, using EXPERIMENTAL here is a very good idea. I think that we should
turn EXPERIMENTAL on even if I fix for that exists, for a least a couple
of months until we see how this thing really evolves.
What do you think?
>> I can push a proposal for it, but it would be done in a separate patch
>> anyway. Also, we may be in better conditions to fix this when the slab
>> part is merged - since it will likely have the same problems...
>>
>
> Yes. considering sockets which can be shared between tasks(cgroups)
> you'll finally need
> - owner task of socket
> - account moving callback
>
> Or disallow task moving once accounted.
I personally think disallowing task movement once accounted is
reasonable. At least for starters.
I think I can add at least that to the next proposal. Famous last words
is, it should not be that hard...
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v3 1/7] Basic kernel memory functionality for the Memory Controller
From: Glauber Costa @ 2011-09-26 22:44 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: linux-kernel, paul, lizf, ebiederm, davem, gthelen, netdev,
linux-mm, kirill
In-Reply-To: <20110926193451.b419f630.kamezawa.hiroyu@jp.fujitsu.com>
>> #endif
>>
>> -
>> +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
>> +int do_kmem_account __read_mostly = 1;
>> +#else
>> +#define do_kmem_account 0
>> +#endif
>
>
> Hmm, do we really need this boot option ?
> From my experience to have swap-accounting boot option,
> this scares us ;) I think config is enough.
If no one else wants it, I can remove it. I personally
don't need it, just wanted to follow the convention laid down by swap here.
>
>
>
>> /*
>> * Statistics for memory cgroup.
>> */
>> @@ -270,6 +274,10 @@ struct mem_cgroup {
>> */
>> struct res_counter memsw;
>> /*
>> + * the counter to account for kmem usage.
>> + */
>> + struct res_counter kmem;
>> + /*
>> * Per cgroup active and inactive list, similar to the
>> * per zone LRU lists.
>> */
>> @@ -321,6 +329,11 @@ struct mem_cgroup {
>> */
>> unsigned long move_charge_at_immigrate;
>> /*
>> + * Should kernel memory limits be stabilished independently
>> + * from user memory ?
>> + */
>> + int kmem_independent;
>> + /*
>> * percpu counter.
>> */
>> struct mem_cgroup_stat_cpu *stat;
>> @@ -388,9 +401,14 @@ enum charge_type {
>> };
>>
>> /* for encoding cft->private value on file */
>> -#define _MEM (0)
>> -#define _MEMSWAP (1)
>> -#define _OOM_TYPE (2)
>> +
>> +enum mem_type {
>> + _MEM = 0,
>> + _MEMSWAP,
>> + _OOM_TYPE,
>> + _KMEM,
>> +};
>> +
>
> ok, nice clean up.
>
>
>> #define MEMFILE_PRIVATE(x, val) (((x)<< 16) | (val))
>> #define MEMFILE_TYPE(val) (((val)>> 16)& 0xffff)
>> #define MEMFILE_ATTR(val) ((val)& 0xffff)
>> @@ -3943,10 +3961,15 @@ static inline u64 mem_cgroup_usage(struct mem_cgroup *mem, bool swap)
>> u64 val;
>>
>> if (!mem_cgroup_is_root(mem)) {
>> + val = 0;
>> + if (!mem->kmem_independent)
>> + val = res_counter_read_u64(&mem->kmem, RES_USAGE);
>
>> if (!swap)
>> - return res_counter_read_u64(&mem->res, RES_USAGE);
>> + val += res_counter_read_u64(&mem->res, RES_USAGE);
>> else
>> - return res_counter_read_u64(&mem->memsw, RES_USAGE);
>> + val += res_counter_read_u64(&mem->memsw, RES_USAGE);
>> +
>> + return val;
>> }
>>
>> val = mem_cgroup_recursive_stat(mem, MEM_CGROUP_STAT_CACHE);
>> @@ -3979,6 +4002,10 @@ static u64 mem_cgroup_read(struct cgroup *cont, struct cftype *cft)
>> else
>> val = res_counter_read_u64(&mem->memsw, name);
>> break;
>> + case _KMEM:
>> + val = res_counter_read_u64(&mem->kmem, name);
>> + break;
>> +
>> default:
>> BUG();
>> break;
>> @@ -4756,6 +4783,21 @@ static int mem_cgroup_reset_vmscan_stat(struct cgroup *cgrp,
>> return 0;
>> }
>>
>> +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
>> +static u64 kmem_limit_independent_read(struct cgroup *cont, struct cftype *cft)
>> +{
>> + return mem_cgroup_from_cont(cont)->kmem_independent;
>> +}
>> +
>> +static int kmem_limit_independent_write(struct cgroup *cont, struct cftype *cft,
>> + u64 val)
>> +{
>> + cgroup_lock();
>> + mem_cgroup_from_cont(cont)->kmem_independent = !!val;
>> + cgroup_unlock();
>
> Hm. This code allows that parent/child can have different settings.
> Could you add parent-child check as..
>
> "If parent sets use_hierarchy==1, children must have the same kmem_independent value
> with parant's one."
Agree.
> How do you think ? I think a hierarchy must have the same config.
Yes, I think this is reasonable.
>
> BTW...I don't like naming a little ;)
>
> memory->consolidated/shared/?????_kmem_accounting ?
> Or
> memory->kmem_independent_accounting ?
>
> or some better naming ?
I can go with kmem_independent_accounting if you like, it is fine
by me.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: Bridge stays down until a port is added
From: Stephen Hemminger @ 2011-09-26 22:42 UTC (permalink / raw)
To: Nicolas de Pesloüan; +Cc: Marc Haber, netdev
In-Reply-To: <4E80F8BD.4010401@gmail.com>
> And this might also allow to set an IPv6 address on a dummy interface, which Marc Haber reported as
> not being allowed for now, probably because DAD cannot succeed on a dummy interface and as such, a
> bind() cannot be allowed, and as such, setting the IPv6 address is currently useless.
For dummy, the interface should probably have the IFF_NOARP flag set.
There isn't any point in doing network discovery on a non-connected
interface. That would make DAD a no-op and bind would work.
^ permalink raw reply
* [RFC] bridge: handle bridge group address per 802.1 standards
From: Stephen Hemminger @ 2011-09-26 22:36 UTC (permalink / raw)
To: netdev
The Linux bridge code would process all packets addressed to
the multicast address 01:80:C2:00:00:0X as local and
and never forward. This may have been correct in the ancient past, but
reading the relevant standards, the correct behavior is to handle only
the bridge group address as a special case and leave all other link
local multicast packets alone.
Recently there has been some complaints about forwarding (or not) of
802.1X EAPOL frames by the bridge. Thanks to Tony Jeffree of the
802.1 Bridging Working Group for point me in the correct direction.
The 802.1X-2010 standard Table 11-1 details how different
addresses are assigned based on connectivity associations.
Bridge group address: 01-80-C2-00-00-00
PAE group address: 01-80-C2-00-00-03
Link Layer Discovery 01-80-C2-00-00-0E
Warning: this may mean that some people using bridge who expect
link local packets to be isolated, now need to add firewall rules.
But in my opinion, following the standard is the correct thing to
do regardless.
This means when using 802.1x with libvirt, there are several options:
1. Use macvtap not bridge
2. Turn off STP in libvirt
3. Use PAE group address for 802.1x
4. Provide a user level application using AF_LLC to forward
the 802.2 frames
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
--- a/net/bridge/br_input.c 2011-09-16 13:12:58.061369744 -0700
+++ b/net/bridge/br_input.c 2011-09-26 11:57:41.724554692 -0700
@@ -126,18 +126,6 @@ static int br_handle_local_finish(struct
return 0; /* process further */
}
-/* Does address match the link local multicast address.
- * 01:80:c2:00:00:0X
- */
-static inline int is_link_local(const unsigned char *dest)
-{
- __be16 *a = (__be16 *)dest;
- static const __be16 *b = (const __be16 *)br_group_address;
- static const __be16 m = cpu_to_be16(0xfff0);
-
- return ((a[0] ^ b[0]) | (a[1] ^ b[1]) | ((a[2] ^ b[2]) & m)) == 0;
-}
-
/*
* Return NULL if skb is handled
* note: already called with rcu_read_lock
@@ -161,13 +149,10 @@ rx_handler_result_t br_handle_frame(stru
p = br_port_get_rcu(skb->dev);
- if (unlikely(is_link_local(dest))) {
- /* Pause frames shouldn't be passed up by driver anyway */
- if (skb->protocol == htons(ETH_P_PAUSE))
- goto drop;
-
- /* If STP is turned off, then forward */
- if (p->br->stp_enabled == BR_NO_STP && dest[5] == 0)
+ /* Special handling for bridge group address */
+ if (unlikely(compare_ether_addr(dest, br_group_address) == 0)) {
+ /* If STP is turned off, then act like a hub. */
+ if (p->br->stp_enabled == BR_NO_STP)
goto forward;
if (NF_HOOK(NFPROTO_BRIDGE, NF_BR_LOCAL_IN, skb, skb->dev,
^ permalink raw reply
* Re: Bridge stays down until a port is added
From: Nicolas de Pesloüan @ 2011-09-26 22:12 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Marc Haber, netdev
In-Reply-To: <20110926130507.1435d76b@nehalam.linuxnetplumber.net>
Le 26/09/2011 22:05, Stephen Hemminger a écrit :
> On Mon, 26 Sep 2011 22:02:21 +0200
> Nicolas de Pesloüan<nicolas.2p.debian@gmail.com> wrote:
[...]
>> Stephen,
>>
>> What do you think about a generic per-interface option that would cause bind() to accept tentative
>> address hold by a particular interface? This of course violate IPv6 principle, but we are talking
>> about interfaces that are unable to do DAD, either permanently or until something happens on the
>> underlying device.
>>
>> echo 1> /sys/class/net/br0/allow_bind_on_tentative_address
>> echo 1> /sys/class/net/dummy0/allow_bind_on_tentative_address
>> echo 1> /sys/class/net/wlan0/allow_bind_on_tentative_address
>> and so on...
>>
>> And we may possibly automatically reset this option to 0 if DAD eventually causes the address to be
>> considered duplicate.
>
> The issue is that if DAD rejects a duplicate, the socket is dead and application is
> out of luck.
Yes, and this is by design. Setting the option would state "I want to allow early bind(), prior to
DAD and I assume the fact that a possible duplicate address will cause the corresponding socket to
be dead and so the using application."
In the particular use case of a bridge to connect to virtual machines, the user can reasonably
assume that he know what it is doing on this private LAN. As such, he would accept the risk to have
applications die if he end up with a duplicate address.
And this might also allow to set an IPv6 address on a dummy interface, which Marc Haber reported as
not being allowed for now, probably because DAD cannot succeed on a dummy interface and as such, a
bind() cannot be allowed, and as such, setting the IPv6 address is currently useless.
Nicolas.
^ permalink raw reply
* Re: [PATCH 1/4] IPVS: Add documentation for new sysctl entries
From: Simon Horman @ 2011-09-26 22:07 UTC (permalink / raw)
To: Randy Dunlap
Cc: lvs-devel, netdev, netfilter-devel, netfilter, Wensong Zhang,
Julian Anastasov, Patrick McHardy
In-Reply-To: <4E80B379.2040701@xenotime.net>
On Mon, Sep 26, 2011 at 10:16:41AM -0700, Randy Dunlap wrote:
> On 09/25/2011 06:23 PM, Simon Horman wrote:
> > Add missing documentation for conntrack, snat_reroute and sync_version.
> >
> > Also fix up a typo, IPVS_DEBUG should be IP_VS_DEBUG.
> >
> > Signed-off-by: Simon Horman <horms@verge.net.au>
> >
> > conntrack
> > ---
> > Documentation/networking/ipvs-sysctl.txt | 53 +++++++++++++++++++++++++++++-
> > 1 files changed, 52 insertions(+), 1 deletions(-)
> >
> > diff --git a/Documentation/networking/ipvs-sysctl.txt b/Documentation/networking/ipvs-sysctl.txt
> > index 4ccdbca..5214339 100644
> > --- a/Documentation/networking/ipvs-sysctl.txt
> > +++ b/Documentation/networking/ipvs-sysctl.txt
> > @@ -15,6 +15,23 @@ amemthresh - INTEGER
> > enabled and the variable is automatically set to 2, otherwise
> > the strategy is disabled and the variable is set to 1.
> >
> > +conntrack - BOOLEAN
> > + 0 - disabled (default)
> > + not 0 - enabled
> > +
> > + If set, maintain connection tracking entries for
> > + connections handled by IPVS.
> > +
> > + This should be enabled if connections handled by IPVS are to be
> > + also handled by stateful firewall rules. That is, iptables rules
> > + that make use of connection tracking. It is a performance
> > + optimisation to disable this setting otherwise.
> > +
> > + Connections handled by the IPVS FTP application module
> > + will have connection tracking entries regardless of this setting.
> > +
> > + Only available when IPVS is compiled with the CONFIG_IP_VS_NFCT
>
> seems to be missing something. Maybe
>
> Only available when IPVS is compiled with CONFIG_IP_VS_NFCT enabled.
> or
> Only available when IPVS is compiled with the CONFIG_IP_VS_NFCT
> symbol enabled.
>
> > +
> > cache_bypass - BOOLEAN
> > 0 - disabled (default)
> > not 0 - enabled
> > @@ -39,7 +56,7 @@ debug_level - INTEGER
> > 11 - IPVS packet handling (ip_vs_in/ip_vs_out)
> > 12 or more - packet traversal
> >
> > - Only available when IPVS is compiled with the CONFIG_IPVS_DEBUG
> > + Only available when IPVS is compiled with the CONFIG_IP_VS_DEBUG
>
> with CONFIG_IP_VS_DEBUG enabled.
>
> >
> > Higher debugging levels include the messages for lower debugging
> > levels, so setting debug level 2, includes level 0, 1 and 2
Thanks Randy,
I was just blindly copying the existing language.
I'll make a follow up patch which incorporates your suggestions.
^ 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