* Re: [patch net-next 2/3] netfilter: ip6_tables: use reasm skb for matching
From: Jiri Pirko @ 2013-11-05 18:21 UTC (permalink / raw)
To: Patrick McHardy
Cc: Florian Westphal, netdev, davem, pablo, netfilter-devel, yoshfuji,
kadlec, mleitner, kuznet, jmorris, wensong, horms, ja, edumazet,
pshelar, jasowang, alexander.h.duyck, coreteam
In-Reply-To: <20131105181923.GB7435@macbook.localnet>
Tue, Nov 05, 2013 at 07:19:24PM CET, kaber@trash.net wrote:
>On Tue, Nov 05, 2013 at 04:39:21PM +0100, Florian Westphal wrote:
>> Jiri Pirko <jiri@resnulli.us> wrote:
>> > Tue, Nov 05, 2013 at 02:41:19PM CET, kaber@trash.net wrote:
>> > >executing the rules on the reassembled packet multiple times, one
>> > >for each fragment.
>> >
>> [..]
>> > End even though, the matching is now done for each fragment skb anyway. The
>> > change is only to do it on different skb. I see no erformance or any
>> > other problem in that.
>>
>> One problem that comes to mind is that nfacct or quota match will
>> now account num_of_fragments * length_of_reassemled_skb bytes.
>
>indeed. The easiest way to fix all this (and, btw, also the
>pskb_expand_head() oops which is currently reported by multiple people)
>is to get rid of all the fragmentation handling and simply use the
>reassembled skb.
Okay. That will resolve the skb->sk rewrite problem as well. I will
prepare a patch.
^ permalink raw reply
* Re: [patch net-next 2/3] netfilter: ip6_tables: use reasm skb for matching
From: Patrick McHardy @ 2013-11-05 18:19 UTC (permalink / raw)
To: Florian Westphal
Cc: Jiri Pirko, netdev, davem, pablo, netfilter-devel, yoshfuji,
kadlec, mleitner, kuznet, jmorris, wensong, horms, ja, edumazet,
pshelar, jasowang, alexander.h.duyck, coreteam
In-Reply-To: <20131105153921.GD15370@breakpoint.cc>
On Tue, Nov 05, 2013 at 04:39:21PM +0100, Florian Westphal wrote:
> Jiri Pirko <jiri@resnulli.us> wrote:
> > Tue, Nov 05, 2013 at 02:41:19PM CET, kaber@trash.net wrote:
> > >executing the rules on the reassembled packet multiple times, one
> > >for each fragment.
> >
> [..]
> > End even though, the matching is now done for each fragment skb anyway. The
> > change is only to do it on different skb. I see no erformance or any
> > other problem in that.
>
> One problem that comes to mind is that nfacct or quota match will
> now account num_of_fragments * length_of_reassemled_skb bytes.
indeed. The easiest way to fix all this (and, btw, also the
pskb_expand_head() oops which is currently reported by multiple people)
is to get rid of all the fragmentation handling and simply use the
reassembled skb.
^ permalink raw reply
* Re: [PATCH 3/7] IBM Akebono: Add support for a new PHY to the IBM emac driver
From: Ben Hutchings @ 2013-11-05 18:16 UTC (permalink / raw)
To: Alistair Popple; +Cc: linuxppc-dev, David S. Miller, netdev
In-Reply-To: <1383629471-16979-3-git-send-email-alistair@popple.id.au>
On Tue, 2013-11-05 at 16:31 +1100, Alistair Popple wrote:
[...]
> --- a/drivers/net/ethernet/ibm/emac/Kconfig
> +++ b/drivers/net/ethernet/ibm/emac/Kconfig
> @@ -55,6 +55,10 @@ config IBM_EMAC_RGMII
> bool
> default n
>
> +config IBM_EMAC_RGMII_WOL
> + bool
> + default n
> +
[...]
So no-one can even build-test this at present!
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [patch net-next 2/3] netfilter: ip6_tables: use reasm skb for matching
From: Patrick McHardy @ 2013-11-05 18:16 UTC (permalink / raw)
To: Jiri Pirko
Cc: Florian Westphal, netdev, davem, pablo, netfilter-devel, yoshfuji,
kadlec, mleitner, kuznet, jmorris, wensong, horms, ja, edumazet,
pshelar, jasowang, alexander.h.duyck, coreteam
In-Reply-To: <20131105150115.GB2438@minipsycho.orion>
On Tue, Nov 05, 2013 at 04:01:15PM +0100, Jiri Pirko wrote:
> Tue, Nov 05, 2013 at 02:41:19PM CET, kaber@trash.net wrote:
> >On Tue, Nov 05, 2013 at 02:32:05PM +0100, Florian Westphal wrote:
> >> Jiri Pirko <jiri@resnulli.us> wrote:
> >> > This patch fixes for example following situation:
> >> > On HOSTA do:
> >> > ip6tables -I INPUT -p icmpv6 -j DROP
> >> > ip6tables -I INPUT -p icmpv6 -m icmp6 --icmpv6-type 128 -j ACCEPT
> >>
> >> untested:
> >>
> >> -A INPUT -p icmpv6 -m icmp6 --icmpv6-type 128 -j ACCEPT
> >> -A INPUT -p icmpv6 -m conntrack --ctstatus CONFIRMED -j ACCEPT
> >> -A INPUT -p icmpv6 -j DROP
> >>
> >> > and on HOSTB you do:
> >> > ping6 HOSTA -s2000 (MTU is 1500)
> >> >
> >> > Incoming echo requests will be filtered out on HOSTA. This issue does
> >> > not occur with smaller packets than MTU (where fragmentation does not happen).
> >>
> >> Patrick, any reason not to kill the special-casing (ct has assigned helper or
> >> unconfirmed conntrack) in __ipv6_conntrack_in() ?
> >>
> >> This should make ipv6 frag behaviour consistent; right now its rather
> >> confusing from ruleset point of view, especially the first packet
> >> of a connection is always seen as reassembled.
> >>
> >> So with Jiris rules
> >>
> >> -A INPUT -p icmpv6 -m icmp6 --icmpv6-type 128 -j ACCEPT
> >> -A INPUT -p icmpv6 -j DROP
> >>
> >> ping6 -s $bignum works for the first packet but not for subsequent ones
> >> which is quite irritating.
> >
> >Well, the reason was to avoid unnecessary work doing refragmentation
> >unless really required. I know its rather complicated, but IPv6 has
> >always required treating fragments manually or using conntrack state.
> >
> >I'm not objecting to changing this, but the patches as they are are
> >not the way to go. First, moving nfct_frag to struct sk_buff seems
>
> I'm a bit lost. What "nfct_frag" are you reffering to here?
I meant nfct_reasm of course.
> >like a real waste of space for this quite rare case. Also, we can't
> >just use the reassembled packet in ip6tables, when modifying it we
> >will still output the unchanged fragments. An last of all, we'll be
> >executing the rules on the reassembled packet multiple times, one
> >for each fragment.
>
> Reassembled skb would be only used for matching where no changes takes
> place.
That still doesn't work, our matches are not purely passive.
> End even though, the matching is now done for each fragment skb anyway. The
> change is only to do it on different skb. I see no erformance or any
> other problem in that.
Accounting, quota, statistic, limit, ... come to mind. Basically any
match that keeps state.
> >So if someone wants to change this, simply *only* pass the reassembled
> >packet through the netfilter hooks and drop the fragments, as in IPv4.
>
> This is unfortunatelly not possible because in forwarding use case, the
> fragments have to be send out as they come in.
No, the IPv6 NAT patches fixed that, we still do proper refragmentation
and we still respect the original fragment sizes, thus are not responsible
for potentially exceeding the PMTU on the following path.
^ permalink raw reply
* Donation Project
From: Mrs. Mary Saleh Saville @ 2013-11-05 18:07 UTC (permalink / raw)
To: net_lm, netcomp3000, netbizpak, netballpk, netabuse, netadmin,
netcourt, netdev, net, netcom_dps, netbizn, net.country,
netcruiser, netcom, netadmin, netbsd-docs-ru, netbehaviour,
netadmin, netbytes, net, netbsd-soccvs, netbeans-info, netadmin,
net, net, netadm, net, netadm, netchatcomp, netbazar, netangels,
net96, net_central, net-abuse, netcontact, netddang, netcom,
net-artidaya, netbank, netannounce, netcell, netbank, net,
netcomp, netabuse, netcompd, netcom, net818, net, net1
Hello,
I am Mrs. Mary Saleh Saville an ageing widow suffering from long time illness. I have some funds I inherited from my late husband, the sum of US$3,500,000.00 and I am in need of a very honest and God fearing person that will use the fund for God's work to help the less privileged out there.
I have mapped out$1,200.000.00 for your personal use in this work. While the rest will be for the work.Please if you would be able to use the funds for the Lord's work kindly reply for further details.
Your full name:
Your full address:
Your telephone/mobile number:
Your fax Number:
Your full company name:
Your age:
Thanks and God bless.
Mrs. Mary Saleh Saville
^ permalink raw reply
* [PATCH] jme: Remove unused #define PFX
From: Joe Perches @ 2013-11-05 17:29 UTC (permalink / raw)
To: netdev; +Cc: Guo-Fu Tseng, LKML
It's unused, remove it.
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/ethernet/jme.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/jme.h b/drivers/net/ethernet/jme.h
index 3efc897..58cd67c 100644
--- a/drivers/net/ethernet/jme.h
+++ b/drivers/net/ethernet/jme.h
@@ -28,7 +28,6 @@
#define DRV_NAME "jme"
#define DRV_VERSION "1.0.8"
-#define PFX DRV_NAME ": "
#define PCI_DEVICE_ID_JMICRON_JMC250 0x0250
#define PCI_DEVICE_ID_JMICRON_JMC260 0x0260
^ permalink raw reply related
* Re: [PATCH net v2] vti: fix spd lookup: match plaintext pkt, not ipsec pkt
From: Christophe Gouault @ 2013-11-05 17:24 UTC (permalink / raw)
To: Eric Dumazet
Cc: Steffen Klassert, David S. Miller, Herbert Xu, netdev,
Saurabh Mohan, Sergei Shtylyov
In-Reply-To: <1383670903.4291.142.camel@edumazet-glaptop2.roam.corp.google.com>
Hello Eric,
On 11/05/2013 06:01 PM, Eric Dumazet wrote:
> On Tue, 2013-11-05 at 16:58 +0100, Christophe Gouault wrote:
>
>> diff --git a/net/ipv4/ip_vti.c b/net/ipv4/ip_vti.c
>> index 6e87f85..bcd85be 100644
>> --- a/net/ipv4/ip_vti.c
>> +++ b/net/ipv4/ip_vti.c
>> @@ -126,6 +126,7 @@ static int vti_rcv(struct sk_buff *skb)
>> if (tunnel != NULL) {
>> struct pcpu_tstats *tstats;
>> u32 oldmark = skb->mark;
>> + u16 netoff = skb_network_header(skb) - skb->data;
> unsigned int nhoff = skb_network_offset(skb);
>
> There is no need to assume u16 here, even if the implementation
> currently has this assumption.
>
> You also could just use faster operation (no need to access
> skb->data/head)
>
> unsigned int old_nh = skb->network_header;
>
> ...
> at restore, use :
> skb->network_header = old_nh;
>
> instead of the more expensive skb_set_network_header()
OK, I was not sure if it was generally agreed to directly manipulate the
skb->network_header. I will send a v3 tomorrow with your suggested
optimization.
Best Regards,
Christophe
^ permalink raw reply
* RE: [patch net-next] ipv6: allow userspace to create address with IFLA_F_TEMPORARY flag
From: David Laight @ 2013-11-05 17:12 UTC (permalink / raw)
To: nicolas.dichtel, David Miller, jiri, vyasevich, netdev, kuznet,
jmorris, yoshfuji, kaber, thaller, stephen
In-Reply-To: <52792499.3030201@6wind.com>
> From: Nicolas Dichtel [mailto:nicolas.dichtel@6wind.com]
...
> If I remember well, another problem is to be able to send these packets with
> 0.0.0.0 when another IP address is available on the system:
>
> RFC2131
> 4.1 Constructing and sending DHCP messages
> ...
> DHCP messages broadcast by a client prior to that client obtaining
> its IP address must have the source address field in the IP header
> set to 0.
>
> We made a patch (never proposed upstream) to add a socket option to keep
> this 0.0.0.0 address.
> If people are interested, I can try to port it on net-next.
Really, what dhcp does before the interface has an address doesn't
really matter - using bpf isn't a problem.
What it needs to do is switch to using a normal socket for the renewals.
Maybe I'll try asking Roy about it on the NetBSD lists.
David
^ permalink raw reply
* Re: [patch net-next] ipv6: allow userspace to create address with IFLA_F_TEMPORARY flag
From: Nicolas Dichtel @ 2013-11-05 17:02 UTC (permalink / raw)
To: David Laight, David Miller, jiri, vyasevich, netdev, kuznet,
jmorris, yoshfuji, kaber, thaller, stephen
In-Reply-To: <20131029124010.GA15762@order.stressinduktion.org>
Le 29/10/2013 13:40, Hannes Frederic Sowa a écrit :
> On Tue, Oct 29, 2013 at 09:37:06AM -0000, David Laight wrote:
>>> Note that you don't even need to put the DHCP protocol core into the
>>> kernel to fix the promiscuous problem. You just have to use the
>>> current kernel interfaces correctly.
>>>
>>> It used to be the case a very long time ago that you couldn't even
>>> receive broadcast UDP datagrams on a socket until an address was
>>> configured on it.
>>>
>>> So everyone turns on promiscuous mode and uses RAW sockets or
>>> AF_PACKET.
>>>
>>> Stupid? yes.
>>
>> Not only that, but the dhcp client could use a normal UDP socket
>> to keep the lease renewed - I suspect it has only ever needed
>> to use the BPF interface (I didn't think it set promiscuous)
>> when acquiring the initial lease.
>
> Yes, this is a very unfortunate situation. From my experience it is not that
> easy to get a patch merged into isc-dhcp.
>
> It seems not that invasive to switch from af_packet to an udp socket with
> SO_BROADCAST set.
If I remember well, another problem is to be able to send these packets with
0.0.0.0 when another IP address is available on the system:
RFC2131
4.1 Constructing and sending DHCP messages
...
DHCP messages broadcast by a client prior to that client obtaining
its IP address must have the source address field in the IP header
set to 0.
We made a patch (never proposed upstream) to add a socket option to keep
this 0.0.0.0 address.
If people are interested, I can try to port it on net-next.
Nicolas
^ permalink raw reply
* Re: [PATCH net v2] vti: fix spd lookup: match plaintext pkt, not ipsec pkt
From: Eric Dumazet @ 2013-11-05 17:01 UTC (permalink / raw)
To: Christophe Gouault
Cc: Steffen Klassert, David S. Miller, Herbert Xu, netdev,
Saurabh Mohan, Sergei Shtylyov
In-Reply-To: <1383667121-23798-1-git-send-email-christophe.gouault@6wind.com>
On Tue, 2013-11-05 at 16:58 +0100, Christophe Gouault wrote:
> diff --git a/net/ipv4/ip_vti.c b/net/ipv4/ip_vti.c
> index 6e87f85..bcd85be 100644
> --- a/net/ipv4/ip_vti.c
> +++ b/net/ipv4/ip_vti.c
> @@ -126,6 +126,7 @@ static int vti_rcv(struct sk_buff *skb)
> if (tunnel != NULL) {
> struct pcpu_tstats *tstats;
> u32 oldmark = skb->mark;
> + u16 netoff = skb_network_header(skb) - skb->data;
unsigned int nhoff = skb_network_offset(skb);
There is no need to assume u16 here, even if the implementation
currently has this assumption.
You also could just use faster operation (no need to access
skb->data/head)
unsigned int old_nh = skb->network_header;
...
at restore, use :
skb->network_header = old_nh;
instead of the more expensive skb_set_network_header()
^ permalink raw reply
* Re: [PATCH net-next RFC 0/5] xen-netback: TX grant mapping instead of copy
From: Zoltan Kiss @ 2013-11-05 17:01 UTC (permalink / raw)
To: Ian Campbell; +Cc: wei.liu2, xen-devel, netdev, linux-kernel, jonathan.davies
In-Reply-To: <5273FA37.6020903@citrix.com>
On 01/11/13 19:00, Zoltan Kiss wrote:
> >> Based on my investigations the packet get only copied if it is
> delivered to
> >>Dom0 stack, which is due to this patch:
> >>https://lkml.org/lkml/2012/7/20/363
> >>That's a bit unfortunate, but as far as I know for the huge majority
> this use
> >>case is not too important.
>> Likely to be true, but it would still be interesting to know how badly
>> this use case suffers with this change, and any increase in CPU usage
>> would be interesting to know about as well.
> I can't find my numbers, but as far as I remember it wasn't
> significantly worse than grant copy. I will check that again.
I've measured it now: with my patch it was 5.2 Gbps, without it 5.4.
Both cases iperf in Dom0 maxed out its CPU, mostly in soft interrupt
context, based on top.
Zoli
^ permalink raw reply
* Re: [PATCH net-next v2] bonding: add option to specify the number of queues per bond device
From: Nikolay Aleksandrov @ 2013-11-05 16:50 UTC (permalink / raw)
To: netdev; +Cc: andy, fubar, vfalico, davem
In-Reply-To: <1383670049-15235-1-git-send-email-nikolay@redhat.com>
On 11/05/2013 05:47 PM, Nikolay Aleksandrov wrote:
> Before this patch the only way to specify the number of queues of a bond
> device was to use the tx_queues module parameter on module load. Since
> we can have different setups with different requirements, it's
> beneficial to be able to specify the number of queues per bond device
> creation. This patch adds this ability and uses tx_queues as a default
> and as a fallback in case of an invalid "queues" value.
> The queues are specified when creating a new bond device through sysfs
> by using " " as a delimiter between the name and the value, e.g.:
> echo "+bond1 8" > bonding_masters
> will create bond1 device with 8 queues.
> Add an example in the documentation, and also trim a few extra spaces
> and tabs while at it.
>
> Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
> ---
Aaaaargh, I'm not posting anymore patches today.
Self-nack again, I forgot about the queues initialization in the store_bonds and
that ends up in a warning when no value is specified, I'm so mad at myself.
Apologies again, this patch can be reviewed as I intend to post a v3 with the
proper initialization of queues to tx_queues in store_bonds as the only change.
Nik
^ permalink raw reply
* [PATCH net-next v2] bonding: add option to specify the number of queues per bond device
From: Nikolay Aleksandrov @ 2013-11-05 16:47 UTC (permalink / raw)
To: netdev; +Cc: andy, fubar, vfalico, davem
Before this patch the only way to specify the number of queues of a bond
device was to use the tx_queues module parameter on module load. Since
we can have different setups with different requirements, it's
beneficial to be able to specify the number of queues per bond device
creation. This patch adds this ability and uses tx_queues as a default
and as a fallback in case of an invalid "queues" value.
The queues are specified when creating a new bond device through sysfs
by using " " as a delimiter between the name and the value, e.g.:
echo "+bond1 8" > bonding_masters
will create bond1 device with 8 queues.
Add an example in the documentation, and also trim a few extra spaces
and tabs while at it.
Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
---
v2: change the delimiter to a space, also improve the warning message and
the documentation
Documentation/networking/bonding.txt | 24 +++++++++++++++---------
drivers/net/bonding/bond_main.c | 6 +++---
drivers/net/bonding/bond_sysfs.c | 20 ++++++++++++++++----
drivers/net/bonding/bonding.h | 2 +-
4 files changed, 35 insertions(+), 17 deletions(-)
diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt
index 2cdb8b6..f87c9a2 100644
--- a/Documentation/networking/bonding.txt
+++ b/Documentation/networking/bonding.txt
@@ -23,7 +23,7 @@ multiple network interfaces into a single logical "bonded" interface.
The behavior of the bonded interfaces depends upon the mode; generally
speaking, modes provide either hot standby or load balancing services.
Additionally, link integrity monitoring may be performed.
-
+
The bonding driver originally came from Donald Becker's
beowulf patches for kernel 2.0. It has changed quite a bit since, and
the original tools from extreme-linux and beowulf sites will not work
@@ -1308,6 +1308,10 @@ Creating and Destroying Bonds
To add a new bond foo:
# echo +foo > /sys/class/net/bonding_masters
+To add a new bond foo with 10 queues instead of the default tx_queues:
+# echo "+foo 10" > /sys/class/net/bonding_masters
+The space between the name and the value is used as a delimiter.
+
To remove an existing bond bar:
# echo -bar > /sys/class/net/bonding_masters
@@ -1485,8 +1489,10 @@ using the traffic control utilities inherent in linux.
By default the bonding driver is multiqueue aware and 16 queues are created
when the driver initializes (see Documentation/networking/multiqueue.txt
for details). If more or less queues are desired the module parameter
-tx_queues can be used to change this value. There is no sysfs parameter
-available as the allocation is done at module init time.
+tx_queues can be used to change this value or the number of queues can be
+specified when creating a bonding device through sysfs by using space as
+a delimiter (e.g., "+bond1 10" will create a bonding device called bond1
+with 10 queues). The tx_queues module parameter value is used as a default.
The output of the file /proc/net/bonding/bondX has changed so the output Queue
ID is now printed for each slave:
@@ -1542,7 +1548,7 @@ that normal output policy selection should take place. One benefit to simply
leaving the qid for a slave to 0 is the multiqueue awareness in the bonding
driver that is now present. This awareness allows tc filters to be placed on
slave devices as well as bond devices and the bonding driver will simply act as
-a pass-through for selecting output queues on the slave device rather than
+a pass-through for selecting output queues on the slave device rather than
output port selection.
This feature first appeared in bonding driver version 3.7.0 and support for
@@ -2225,7 +2231,7 @@ broadcast: Like active-backup, there is not much advantage to this
the same speed and duplex. Also, as with all bonding load
balance modes other than balance-rr, no single connection will
be able to utilize more than a single interface's worth of
- bandwidth.
+ bandwidth.
Additionally, the linux bonding 802.3ad implementation
distributes traffic by peer (using an XOR of MAC addresses),
@@ -2284,7 +2290,7 @@ when they are configured in parallel as part of an isolated network
between two or more systems, for example:
+-----------+
- | Host A |
+ | Host A |
+-+---+---+-+
| | |
+--------+ | +---------+
@@ -2296,7 +2302,7 @@ between two or more systems, for example:
+--------+ | +---------+
| | |
+-+---+---+-+
- | Host B |
+ | Host B |
+-----------+
In this configuration, the switches are isolated from one
@@ -2524,7 +2530,7 @@ bonding driver.
(either the internal Ethernet Switch Module, or an external switch) to
avoid fail-over delay issues when using bonding.
-
+
15. Frequently Asked Questions
==============================
@@ -2561,7 +2567,7 @@ monitored, and should it recover, it will rejoin the bond (in whatever
manner is appropriate for the mode). See the sections on High
Availability and the documentation for each mode for additional
information.
-
+
Link monitoring can be enabled via either the miimon or
arp_interval parameters (described in the module parameters section,
above). In general, miimon monitors the carrier state as sensed by
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 4dd5ee2..95fd7d8 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -4414,7 +4414,7 @@ unsigned int bond_get_num_tx_queues(void)
* Caller must NOT hold rtnl_lock; we need to release it here before we
* set up our sysfs entries.
*/
-int bond_create(struct net *net, const char *name)
+int bond_create(struct net *net, const char *name, int queues)
{
struct net_device *bond_dev;
int res;
@@ -4423,7 +4423,7 @@ int bond_create(struct net *net, const char *name)
bond_dev = alloc_netdev_mq(sizeof(struct bonding),
name ? name : "bond%d",
- bond_setup, tx_queues);
+ bond_setup, queues);
if (!bond_dev) {
pr_err("%s: eek! can't alloc netdev!\n", name);
rtnl_unlock();
@@ -4502,7 +4502,7 @@ static int __init bonding_init(void)
bond_create_debugfs();
for (i = 0; i < max_bonds; i++) {
- res = bond_create(&init_net, NULL);
+ res = bond_create(&init_net, NULL, tx_queues);
if (res)
goto err;
}
diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
index 75dc4d0..edc42dd 100644
--- a/drivers/net/bonding/bond_sysfs.c
+++ b/drivers/net/bonding/bond_sysfs.c
@@ -104,10 +104,17 @@ static ssize_t bonding_store_bonds(struct class *cls,
{
struct bond_net *bn =
container_of(attr, struct bond_net, class_attr_bonding_masters);
+ unsigned int tx_queues = bond_get_num_tx_queues();
char command[IFNAMSIZ + 1] = {0, };
- char *ifname;
- int rv, res = count;
-
+ int rv, res = count, queues = 0;
+ char *ifname, *delim;
+
+ delim = strchr(buffer, ' ');
+ if (delim) {
+ *delim = '\0';
+ if (sscanf(++delim, "%d", &queues) != 1)
+ queues = tx_queues;
+ }
sscanf(buffer, "%16s", command); /* IFNAMSIZ*/
ifname = command + 1;
if ((strlen(command) <= 1) ||
@@ -115,8 +122,13 @@ static ssize_t bonding_store_bonds(struct class *cls,
goto err_no_cmd;
if (command[0] == '+') {
+ if (queues < 1 || queues > 255) {
+ pr_warn("%s: Invalid number of queues (%d) specified, should be between 1 and 255, resetting to %u.\n",
+ ifname, queues, tx_queues);
+ queues = tx_queues;
+ }
pr_info("%s is being created...\n", ifname);
- rv = bond_create(bn->net, ifname);
+ rv = bond_create(bn->net, ifname, queues);
if (rv) {
if (rv == -EEXIST)
pr_info("%s already exists.\n", ifname);
diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
index 77a07a1..453cd1f 100644
--- a/drivers/net/bonding/bonding.h
+++ b/drivers/net/bonding/bonding.h
@@ -404,7 +404,7 @@ struct bond_net;
int bond_arp_rcv(const struct sk_buff *skb, struct bonding *bond, struct slave *slave);
int bond_dev_queue_xmit(struct bonding *bond, struct sk_buff *skb, struct net_device *slave_dev);
void bond_xmit_slave_id(struct bonding *bond, struct sk_buff *skb, int slave_id);
-int bond_create(struct net *net, const char *name);
+int bond_create(struct net *net, const char *name, int queues);
int bond_create_sysfs(struct bond_net *net);
void bond_destroy_sysfs(struct bond_net *net);
void bond_prepare_sysfs_group(struct bonding *bond);
--
1.8.1.4
^ permalink raw reply related
* Re: [PATCH net-next v2 2/4] ipv6: enable IPV6_FLOWLABEL_MGR for getsockopt
From: Hannes Frederic Sowa @ 2013-11-05 16:22 UTC (permalink / raw)
To: Florent Fourcot, netdev
In-Reply-To: <20131105160838.GH8832@order.stressinduktion.org>
On Tue, Nov 05, 2013 at 05:08:38PM +0100, Hannes Frederic Sowa wrote:
> On Tue, Nov 05, 2013 at 03:28:56PM +0100, Florent Fourcot wrote:
> > + spin_lock_bh(&ip6_fl_lock);
> > + rcu_read_lock_bh();
> > +
> > + for_each_sk_fl_rcu(np, sfl) {
> > + if (sfl->fl->label == (np->flow_label & IPV6_FLOWLABEL_MASK)) {
>
> The iteration is protected by rcu, so need to take the ip6_fl_lock. We should
^no ^ here.
Sorry,
Hannes
^ permalink raw reply
* Payment Alert,
From: © Western Union @ 2013-11-04 22:06 UTC (permalink / raw)
This is to re-notify you that your Xmas bonus grant of the US$500,000.00(Dollars) which was deposited here in our western union office in your name is still very much available for pickup. Contact the person of Agent Rick James Email: rickjamesharts002@admin.in.th for your M.T.C.N Numbers, Mobile:+44-7035-916-544
^ permalink raw reply
* Re: [PATCH net-next v2 2/4] ipv6: enable IPV6_FLOWLABEL_MGR for getsockopt
From: Hannes Frederic Sowa @ 2013-11-05 16:08 UTC (permalink / raw)
To: Florent Fourcot; +Cc: netdev
In-Reply-To: <1383661738-6083-2-git-send-email-florent.fourcot@enst-bretagne.fr>
On Tue, Nov 05, 2013 at 03:28:56PM +0100, Florent Fourcot wrote:
> + spin_lock_bh(&ip6_fl_lock);
> + rcu_read_lock_bh();
> +
> + for_each_sk_fl_rcu(np, sfl) {
> + if (sfl->fl->label == (np->flow_label & IPV6_FLOWLABEL_MASK)) {
The iteration is protected by rcu, so need to take the ip6_fl_lock. We should
lock the smallest region which needs to be protected. This is only the body of
the if.
Using fl->label without lock is fine, because it is immutable after interning.
> + freq->flr_label = sfl->fl->label;
> + freq->flr_dst = sfl->fl->dst;
> + freq->flr_share = sfl->fl->share;
> + freq->flr_expires = (sfl->fl->expires - jiffies) / HZ;
> + freq->flr_linger = sfl->fl->linger / HZ;
> +
> + rcu_read_unlock_bh();
> + spin_unlock_bh(&ip6_fl_lock);
Please reverse these two lines then.
Could you take a look at your patch regarding fl6_renew, too? Can we
push locking into the function there, too?
Greetings,
Hannes
^ permalink raw reply
* [PATCH net v2] vti: fix spd lookup: match plaintext pkt, not ipsec pkt
From: Christophe Gouault @ 2013-11-05 15:58 UTC (permalink / raw)
To: christophe.gouault, Steffen Klassert, David S. Miller
Cc: Herbert Xu, netdev, Saurabh Mohan, Sergei Shtylyov
In-Reply-To: <1383646612-30103-1-git-send-email-christophe.gouault@6wind.com>
The vti interface inbound and outbound SPD lookups are based on the
ipsec packet instead of the plaintext packet.
Not only is it counterintuitive, it also restricts vti interfaces
to a single policy (whose selector must match the tunnel local and
remote addresses).
The policy selector is supposed to match the plaintext packet, before
encryption or after decryption.
This patch performs the SPD lookup based on the plaintext packet. It
enables to create several polices bound to the vti interface (via a
mark equal to the vti interface okey).
It remains possible to apply the same policy to all packets entering
the vti interface, by setting an any-to-any selector (src 0.0.0.0/0
dst 0.0.0.0/0 proto any mark OKEY).
Signed-off-by: Christophe Gouault <christophe.gouault@6wind.com>
---
v2:
- Fixed comment style
- Checked with checkpatch.pl and sparse
---
net/ipv4/ip_vti.c | 29 ++++++++++++++++++++++++++++-
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/ip_vti.c b/net/ipv4/ip_vti.c
index 6e87f85..bcd85be 100644
--- a/net/ipv4/ip_vti.c
+++ b/net/ipv4/ip_vti.c
@@ -126,6 +126,7 @@ static int vti_rcv(struct sk_buff *skb)
if (tunnel != NULL) {
struct pcpu_tstats *tstats;
u32 oldmark = skb->mark;
+ u16 netoff = skb_network_header(skb) - skb->data;
int ret;
@@ -133,7 +134,13 @@ static int vti_rcv(struct sk_buff *skb)
* only match policies with this mark.
*/
skb->mark = be32_to_cpu(tunnel->parms.o_key);
+ /* The packet is decrypted, but not yet decapsulated.
+ * Temporarily make network_header point to the inner header
+ * for policy check.
+ */
+ skb_reset_network_header(skb);
ret = xfrm4_policy_check(NULL, XFRM_POLICY_IN, skb);
+ skb_set_network_header(skb, netoff);
skb->mark = oldmark;
if (!ret)
return -1;
@@ -166,6 +173,8 @@ static netdev_tx_t vti_tunnel_xmit(struct sk_buff *skb, struct net_device *dev)
struct iphdr *old_iph = ip_hdr(skb);
__be32 dst = tiph->daddr;
struct flowi4 fl4;
+ struct flowi fl;
+ u32 oldmark = skb->mark;
int err;
if (skb->protocol != htons(ETH_P_IP))
@@ -173,17 +182,35 @@ static netdev_tx_t vti_tunnel_xmit(struct sk_buff *skb, struct net_device *dev)
tos = old_iph->tos;
+ /* SPD lookup: we must provide a dst_entry to xfrm_lookup, normally the
+ * route to the final destination. However this route is a route via
+ * the vti interface. Now vti interfaces typically have the NOXFRM
+ * flag, hence xfrm_lookup would bypass IPsec.
+ *
+ * Therefore, we feed xfrm_lookup with a route to the vti tunnel remote
+ * endpoint instead.
+ */
memset(&fl4, 0, sizeof(fl4));
flowi4_init_output(&fl4, tunnel->parms.link,
be32_to_cpu(tunnel->parms.o_key), RT_TOS(tos),
RT_SCOPE_UNIVERSE,
IPPROTO_IPIP, 0,
dst, tiph->saddr, 0, 0);
- rt = ip_route_output_key(dev_net(dev), &fl4);
+ rt = __ip_route_output_key(tunnel->net, &fl4);
if (IS_ERR(rt)) {
dev->stats.tx_carrier_errors++;
goto tx_error_icmp;
}
+
+ memset(&fl, 0, sizeof(fl));
+ /* Temporarily mark the skb with the tunnel o_key, to look up
+ * for a policy with this mark, matching the plaintext traffic.
+ */
+ skb->mark = be32_to_cpu(tunnel->parms.o_key);
+ __xfrm_decode_session(skb, &fl, AF_INET, 0);
+ skb->mark = oldmark;
+ rt = (struct rtable *)xfrm_lookup(tunnel->net, &rt->dst, &fl, NULL, 0);
+
/* if there is no transform then this tunnel is not functional.
* Or if the xfrm is not mode tunnel.
*/
--
1.7.10.4
^ permalink raw reply related
* [PATCH v2] phy: Add MOXA MDIO driver
From: Jonas Jensen @ 2013-11-05 15:55 UTC (permalink / raw)
To: netdev
Cc: linux-arm-kernel, linux-kernel, devicetree, f.fainelli,
grant.likely, Jonas Jensen
In-Reply-To: <1383317673-14704-1-git-send-email-jonas.jensen@gmail.com>
The MOXA UC-711X hardware(s) has an ethernet controller that seem
to be developed internally. The IC used is "RTL8201CP".
This patch adds an MDIO driver which handles the MII bus.
Signed-off-by: Jonas Jensen <jonas.jensen@gmail.com>
---
Notes:
Thanks for the feedback.
Besides what is below I plan to submit changes suggested by
Grant as a separate patch (to Documentation/devicetree/bindings/net/phy.txt)
Changes since v1:
1. split changes to drivers/net/phy/realtek.c into separate patch
driver code:
2. use dev_dbg() instead of dev_err()
3. use id "%s-%d-mii" instead of "%s-mii"
4. call mdiobus_free() on of_mdiobus_register() failure
DT binding document:
5. remove it, submitting changes (to Documentation/devicetree/bindings/net/moxa,moxart-mac.txt) along with changes to the driver
Applies to next-20131105
drivers/net/phy/Kconfig | 7 ++
drivers/net/phy/Makefile | 1 +
drivers/net/phy/mdio-moxart.c | 201 ++++++++++++++++++++++++++++++++++++++++++
3 files changed, 209 insertions(+)
create mode 100644 drivers/net/phy/mdio-moxart.c
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 342561a..9b5d46c 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -154,6 +154,13 @@ config MDIO_SUN4I
interface units of the Allwinner SoC that have an EMAC (A10,
A12, A10s, etc.)
+config MDIO_MOXART
+ tristate "MOXA ART MDIO interface support"
+ depends on ARCH_MOXART
+ help
+ This driver supports the MDIO interface found in the network
+ interface units of the MOXA ART SoC
+
config MDIO_BUS_MUX
tristate
depends on OF_MDIO
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index 23a2ab2..9013dfa 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -31,3 +31,4 @@ obj-$(CONFIG_MDIO_BUS_MUX) += mdio-mux.o
obj-$(CONFIG_MDIO_BUS_MUX_GPIO) += mdio-mux-gpio.o
obj-$(CONFIG_MDIO_BUS_MUX_MMIOREG) += mdio-mux-mmioreg.o
obj-$(CONFIG_MDIO_SUN4I) += mdio-sun4i.o
+obj-$(CONFIG_MDIO_MOXART) += mdio-moxart.o
diff --git a/drivers/net/phy/mdio-moxart.c b/drivers/net/phy/mdio-moxart.c
new file mode 100644
index 0000000..a5741cb
--- /dev/null
+++ b/drivers/net/phy/mdio-moxart.c
@@ -0,0 +1,201 @@
+/* MOXA ART Ethernet (RTL8201CP) MDIO interface driver
+ *
+ * Copyright (C) 2013 Jonas Jensen <jonas.jensen@gmail.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include <linux/delay.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/of_address.h>
+#include <linux/of_mdio.h>
+#include <linux/phy.h>
+#include <linux/platform_device.h>
+#include <linux/regulator/consumer.h>
+
+#define REG_PHY_CTRL 0
+#define REG_PHY_WRITE_DATA 4
+
+/* REG_PHY_CTRL */
+#define MIIWR BIT(27) /* init write sequence (auto cleared)*/
+#define MIIRD BIT(26)
+#define REGAD_MASK 0x3e00000
+#define PHYAD_MASK 0x1f0000
+#define MIIRDATA_MASK 0xffff
+
+/* REG_PHY_WRITE_DATA */
+#define MIIWDATA_MASK 0xffff
+
+struct moxart_mdio_data {
+ void __iomem *base;
+};
+
+static int moxart_mdio_read(struct mii_bus *bus, int mii_id, int regnum)
+{
+ struct moxart_mdio_data *data = bus->priv;
+ u32 ctrl = 0;
+ unsigned int count = 5;
+
+ dev_dbg(&bus->dev, "%s\n", __func__);
+
+ ctrl |= MIIRD | ((mii_id << 16) & PHYAD_MASK) |
+ ((regnum << 21) & REGAD_MASK);
+
+ writel(ctrl, data->base + REG_PHY_CTRL);
+
+ do {
+ ctrl = readl(data->base + REG_PHY_CTRL);
+
+ if (!(ctrl & MIIRD))
+ return ctrl & MIIRDATA_MASK;
+
+ mdelay(10);
+ count--;
+ } while (count > 0);
+
+ dev_dbg(&bus->dev, "%s timed out\n", __func__);
+
+ return -ETIMEDOUT;
+}
+
+static int moxart_mdio_write(struct mii_bus *bus, int mii_id,
+ int regnum, u16 value)
+{
+ struct moxart_mdio_data *data = bus->priv;
+ u32 ctrl = 0;
+ unsigned int count = 5;
+
+ dev_dbg(&bus->dev, "%s\n", __func__);
+
+ ctrl |= MIIWR | ((mii_id << 16) & PHYAD_MASK) |
+ ((regnum << 21) & REGAD_MASK);
+
+ value &= MIIWDATA_MASK;
+
+ writel(value, data->base + REG_PHY_WRITE_DATA);
+ writel(ctrl, data->base + REG_PHY_CTRL);
+
+ do {
+ ctrl = readl(data->base + REG_PHY_CTRL);
+
+ if (!(ctrl & MIIWR))
+ return 0;
+
+ mdelay(10);
+ count--;
+ } while (count > 0);
+
+ dev_dbg(&bus->dev, "%s timed out\n", __func__);
+
+ return -ETIMEDOUT;
+}
+
+static int moxart_mdio_reset(struct mii_bus *bus)
+{
+ int data, i;
+
+ for (i = 0; i < PHY_MAX_ADDR; i++) {
+ data = moxart_mdio_read(bus, i, MII_BMCR);
+ if (data < 0)
+ continue;
+
+ data |= BMCR_RESET;
+ if (moxart_mdio_write(bus, i, MII_BMCR, data) < 0)
+ continue;
+ }
+
+ return 0;
+}
+
+static int moxart_mdio_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct mii_bus *bus;
+ struct moxart_mdio_data *data;
+ struct resource *res;
+ int ret, i;
+
+ bus = mdiobus_alloc_size(sizeof(*data));
+ if (!bus)
+ return -ENOMEM;
+
+ bus->name = "MOXA ART Ethernet MII";
+ bus->read = &moxart_mdio_read;
+ bus->write = &moxart_mdio_write;
+ bus->reset = &moxart_mdio_reset;
+ snprintf(bus->id, MII_BUS_ID_SIZE, "%s-%d-mii", pdev->name, pdev->id);
+ bus->parent = &pdev->dev;
+
+ bus->irq = devm_kzalloc(&pdev->dev, sizeof(int) * PHY_MAX_ADDR,
+ GFP_KERNEL);
+ if (!bus->irq) {
+ ret = -ENOMEM;
+ goto err_out_free_mdiobus;
+ }
+
+ /* Setting PHY_IGNORE_INTERRUPT here even if it has no effect,
+ * of_mdiobus_register() sets these PHY_POLL.
+ * Ideally, the interrupt from MAC controller could be used to
+ * detect link state changes, not polling, i.e. if there was
+ * a way phy_driver could set PHY_HAS_INTERRUPT but have that
+ * interrupt handled in ethernet drivercode.
+ */
+ for (i = 0; i < PHY_MAX_ADDR; i++)
+ bus->irq[i] = PHY_IGNORE_INTERRUPT;
+
+ data = bus->priv;
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ data->base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(data->base)) {
+ ret = PTR_ERR(data->base);
+ goto err_out_free_mdiobus;
+ }
+
+ ret = of_mdiobus_register(bus, np);
+ if (ret < 0)
+ goto err_out_free_mdiobus;
+
+ platform_set_drvdata(pdev, bus);
+
+ return 0;
+
+err_out_free_mdiobus:
+ mdiobus_free(bus);
+ return ret;
+}
+
+static int moxart_mdio_remove(struct platform_device *pdev)
+{
+ struct mii_bus *bus = platform_get_drvdata(pdev);
+
+ mdiobus_unregister(bus);
+ mdiobus_free(bus);
+
+ return 0;
+}
+
+static const struct of_device_id moxart_mdio_dt_ids[] = {
+ { .compatible = "moxa,moxart-mdio" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, moxart_mdio_dt_ids);
+
+static struct platform_driver moxart_mdio_driver = {
+ .probe = moxart_mdio_probe,
+ .remove = moxart_mdio_remove,
+ .driver = {
+ .name = "moxart-mdio",
+ .of_match_table = moxart_mdio_dt_ids,
+ },
+};
+
+module_platform_driver(moxart_mdio_driver);
+
+MODULE_DESCRIPTION("MOXA ART MDIO interface driver");
+MODULE_AUTHOR("Jonas Jensen <jonas.jensen@gmail.com>");
+MODULE_LICENSE("GPL");
--
1.8.2.1
^ permalink raw reply related
* Re: [PATCH net-next] bonding: add option to specify the number of queues per bond device
From: Nikolay Aleksandrov @ 2013-11-05 15:46 UTC (permalink / raw)
To: netdev; +Cc: andy, fubar, vfalico
In-Reply-To: <52791287.1070101@redhat.com>
On 11/05/2013 04:45 PM, Nikolay Aleksandrov wrote:
> On 11/05/2013 04:41 PM, Nikolay Aleksandrov wrote:
>> Before this patch the only way to specify the number of queues of a bond
>> device was to use the tx_queues module parameter on module load. Since
>> we can have different setups with different requirements, it's
>> beneficial to be able to specify the number of queues per bond device
>> creation. This patch adds this ability and uses tx_queues as a default
>> and as a fallback in case of an invalid "queues" value.
>> The queues are specified when creating a new bond device through sysfs
>> by using the ":" as a delimiter between the name and the value, e.g.:
>> echo +bond1:8 > bonding_masters
>> will create bond1 device with 8 queues. The value 0 is reserved for
>> using the default number of queues (global tx_queues set on module
>> loading).
>> Add an example in the documentation, and also trim a few extra spaces
>> and tabs while at it.
>>
>> Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
>> ---
> ugh, self-nack I chose the wrong delimiter, it's allowed to be in an interface
> name :-)
>
> Will re-post by using "." as a delimiter.
> Sorry for the noise.
Again too much caffeine, disregard the "." sentence.
>
> Nik
>
^ permalink raw reply
* Re: [PATCH net-next] bonding: add option to specify the number of queues per bond device
From: Nikolay Aleksandrov @ 2013-11-05 15:45 UTC (permalink / raw)
To: netdev; +Cc: andy, fubar, vfalico
In-Reply-To: <1383666093-4115-1-git-send-email-nikolay@redhat.com>
On 11/05/2013 04:41 PM, Nikolay Aleksandrov wrote:
> Before this patch the only way to specify the number of queues of a bond
> device was to use the tx_queues module parameter on module load. Since
> we can have different setups with different requirements, it's
> beneficial to be able to specify the number of queues per bond device
> creation. This patch adds this ability and uses tx_queues as a default
> and as a fallback in case of an invalid "queues" value.
> The queues are specified when creating a new bond device through sysfs
> by using the ":" as a delimiter between the name and the value, e.g.:
> echo +bond1:8 > bonding_masters
> will create bond1 device with 8 queues. The value 0 is reserved for
> using the default number of queues (global tx_queues set on module
> loading).
> Add an example in the documentation, and also trim a few extra spaces
> and tabs while at it.
>
> Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
> ---
ugh, self-nack I chose the wrong delimiter, it's allowed to be in an interface
name :-)
Will re-post by using "." as a delimiter.
Sorry for the noise.
Nik
^ permalink raw reply
* [PATCH net-next] bonding: add option to specify the number of queues per bond device
From: Nikolay Aleksandrov @ 2013-11-05 15:41 UTC (permalink / raw)
To: netdev; +Cc: andy, fubar, vfalico
Before this patch the only way to specify the number of queues of a bond
device was to use the tx_queues module parameter on module load. Since
we can have different setups with different requirements, it's
beneficial to be able to specify the number of queues per bond device
creation. This patch adds this ability and uses tx_queues as a default
and as a fallback in case of an invalid "queues" value.
The queues are specified when creating a new bond device through sysfs
by using the ":" as a delimiter between the name and the value, e.g.:
echo +bond1:8 > bonding_masters
will create bond1 device with 8 queues. The value 0 is reserved for
using the default number of queues (global tx_queues set on module
loading).
Add an example in the documentation, and also trim a few extra spaces
and tabs while at it.
Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
---
Documentation/networking/bonding.txt | 17 ++++++++++-------
drivers/net/bonding/bond_main.c | 8 ++++----
drivers/net/bonding/bond_sysfs.c | 17 ++++++++++++++---
drivers/net/bonding/bonding.h | 2 +-
4 files changed, 29 insertions(+), 15 deletions(-)
diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt
index 3856ed2..b51e852 100644
--- a/Documentation/networking/bonding.txt
+++ b/Documentation/networking/bonding.txt
@@ -23,7 +23,7 @@ multiple network interfaces into a single logical "bonded" interface.
The behavior of the bonded interfaces depends upon the mode; generally
speaking, modes provide either hot standby or load balancing services.
Additionally, link integrity monitoring may be performed.
-
+
The bonding driver originally came from Donald Becker's
beowulf patches for kernel 2.0. It has changed quite a bit since, and
the original tools from extreme-linux and beowulf sites will not work
@@ -1299,6 +1299,9 @@ Creating and Destroying Bonds
To add a new bond foo:
# echo +foo > /sys/class/net/bonding_masters
+To add a new bond foo with 10 queues instead of the default tx_queues:
+# echo +foo:10 > /sys/class/net/bonding_masters
+
To remove an existing bond bar:
# echo -bar > /sys/class/net/bonding_masters
@@ -1533,7 +1536,7 @@ that normal output policy selection should take place. One benefit to simply
leaving the qid for a slave to 0 is the multiqueue awareness in the bonding
driver that is now present. This awareness allows tc filters to be placed on
slave devices as well as bond devices and the bonding driver will simply act as
-a pass-through for selecting output queues on the slave device rather than
+a pass-through for selecting output queues on the slave device rather than
output port selection.
This feature first appeared in bonding driver version 3.7.0 and support for
@@ -2216,7 +2219,7 @@ broadcast: Like active-backup, there is not much advantage to this
the same speed and duplex. Also, as with all bonding load
balance modes other than balance-rr, no single connection will
be able to utilize more than a single interface's worth of
- bandwidth.
+ bandwidth.
Additionally, the linux bonding 802.3ad implementation
distributes traffic by peer (using an XOR of MAC addresses),
@@ -2275,7 +2278,7 @@ when they are configured in parallel as part of an isolated network
between two or more systems, for example:
+-----------+
- | Host A |
+ | Host A |
+-+---+---+-+
| | |
+--------+ | +---------+
@@ -2287,7 +2290,7 @@ between two or more systems, for example:
+--------+ | +---------+
| | |
+-+---+---+-+
- | Host B |
+ | Host B |
+-----------+
In this configuration, the switches are isolated from one
@@ -2515,7 +2518,7 @@ bonding driver.
(either the internal Ethernet Switch Module, or an external switch) to
avoid fail-over delay issues when using bonding.
-
+
15. Frequently Asked Questions
==============================
@@ -2552,7 +2555,7 @@ monitored, and should it recover, it will rejoin the bond (in whatever
manner is appropriate for the mode). See the sections on High
Availability and the documentation for each mode for additional
information.
-
+
Link monitoring can be enabled via either the miimon or
arp_interval parameters (described in the module parameters section,
above). In general, miimon monitors the carrier state as sensed by
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index a141f40..2ad43f0 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -4367,9 +4367,9 @@ unsigned int bond_get_num_tx_queues(void)
/* Create a new bond based on the specified name and bonding parameters.
* If name is NULL, obtain a suitable "bond%d" name for us.
* Caller must NOT hold rtnl_lock; we need to release it here before we
- * set up our sysfs entries.
+ * set up our sysfs entries. If queues is 0 then use the global tx_queues.
*/
-int bond_create(struct net *net, const char *name)
+int bond_create(struct net *net, const char *name, int queues)
{
struct net_device *bond_dev;
int res;
@@ -4378,7 +4378,7 @@ int bond_create(struct net *net, const char *name)
bond_dev = alloc_netdev_mq(sizeof(struct bonding),
name ? name : "bond%d",
- bond_setup, tx_queues);
+ bond_setup, queues ? queues : tx_queues);
if (!bond_dev) {
pr_err("%s: eek! can't alloc netdev!\n", name);
rtnl_unlock();
@@ -4457,7 +4457,7 @@ static int __init bonding_init(void)
bond_create_debugfs();
for (i = 0; i < max_bonds; i++) {
- res = bond_create(&init_net, NULL);
+ res = bond_create(&init_net, NULL, tx_queues);
if (res)
goto err;
}
diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
index 47749c9..22c86d3 100644
--- a/drivers/net/bonding/bond_sysfs.c
+++ b/drivers/net/bonding/bond_sysfs.c
@@ -104,9 +104,15 @@ static ssize_t bonding_store_bonds(struct class *cls,
struct bond_net *bn =
container_of(attr, struct bond_net, class_attr_bonding_masters);
char command[IFNAMSIZ + 1] = {0, };
- char *ifname;
- int rv, res = count;
+ int rv, res = count, queues = 0;
+ char *ifname, *delim;
+ delim = strchr(buffer, ':');
+ if (delim) {
+ *delim = '\0';
+ if (sscanf(++delim, "%d", &queues) != 1)
+ queues = 0;
+ }
sscanf(buffer, "%16s", command); /* IFNAMSIZ*/
ifname = command + 1;
if ((strlen(command) <= 1) ||
@@ -114,8 +120,13 @@ static ssize_t bonding_store_bonds(struct class *cls,
goto err_no_cmd;
if (command[0] == '+') {
+ if (queues < 0 || queues > 255) {
+ pr_warn("%s: Invalid number of queues (%d) specified, resetting to default.\n",
+ ifname, queues);
+ queues = 0;
+ }
pr_info("%s is being created...\n", ifname);
- rv = bond_create(bn->net, ifname);
+ rv = bond_create(bn->net, ifname, queues);
if (rv) {
if (rv == -EEXIST)
pr_info("%s already exists.\n", ifname);
diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
index 046a605..31ae6da 100644
--- a/drivers/net/bonding/bonding.h
+++ b/drivers/net/bonding/bonding.h
@@ -403,7 +403,7 @@ struct bond_net;
int bond_arp_rcv(const struct sk_buff *skb, struct bonding *bond, struct slave *slave);
int bond_dev_queue_xmit(struct bonding *bond, struct sk_buff *skb, struct net_device *slave_dev);
void bond_xmit_slave_id(struct bonding *bond, struct sk_buff *skb, int slave_id);
-int bond_create(struct net *net, const char *name);
+int bond_create(struct net *net, const char *name, int queues);
int bond_create_sysfs(struct bond_net *net);
void bond_destroy_sysfs(struct bond_net *net);
void bond_prepare_sysfs_group(struct bonding *bond);
--
1.8.1.4
^ permalink raw reply related
* Re: [patch net-next 2/3] netfilter: ip6_tables: use reasm skb for matching
From: Florian Westphal @ 2013-11-05 15:39 UTC (permalink / raw)
To: Jiri Pirko
Cc: Patrick McHardy, Florian Westphal, netdev, davem, pablo,
netfilter-devel, yoshfuji, kadlec, mleitner, kuznet, jmorris,
wensong, horms, ja, edumazet, pshelar, jasowang,
alexander.h.duyck, coreteam
In-Reply-To: <20131105150115.GB2438@minipsycho.orion>
Jiri Pirko <jiri@resnulli.us> wrote:
> Tue, Nov 05, 2013 at 02:41:19PM CET, kaber@trash.net wrote:
> >executing the rules on the reassembled packet multiple times, one
> >for each fragment.
>
[..]
> End even though, the matching is now done for each fragment skb anyway. The
> change is only to do it on different skb. I see no erformance or any
> other problem in that.
One problem that comes to mind is that nfacct or quota match will
now account num_of_fragments * length_of_reassemled_skb bytes.
^ permalink raw reply
* Re: [PATCH v2 0/2] l2 hardware accelerated macvlans
From: Vlad Yasevich @ 2013-11-05 15:20 UTC (permalink / raw)
To: John Fastabend
Cc: nhorman, alexander.h.duyck, netdev, andy, davem,
jeffrey.t.kirsher
In-Reply-To: <52790C01.3070107@intel.com>
On 11/05/2013 10:17 AM, John Fastabend wrote:
> On 11/5/2013 6:47 AM, Vlad Yasevich wrote:
>> Hi John
>>
>
> [...]
>
>>> series. It would be best (I think) to use the software
>>> path for macvlan to macvlan traffic and save the PCIe
>>> bus. Also this only allows for layer 2 mac forwarding
>>> where some hardware supports more interesting forwarding
>>> capabilities. Integrating with OVS may be useful here.
>>
>> This seems to be saying that for macvlan-macvlan
>> case, you still prefere to do software based forwarding, but
>> patch 1 in the series seem to always attempt to do hardware
>> offloaded forwarding regardless of traffic and macvlan type.
>> Can you clarify.
>>
>> Thanks
>> -vlad
>>
>
> This series always attempts to do hardware offload even in the
> macvlan-macvlan case as you note. I'm suggesting a further
> optimization might be to use the software based forwarding in
> this case. My plan is to investigate this after I get the initial
> series completed.
>
Ahh. Got it.
Thanks
-vlad
^ permalink raw reply
* Re: [PATCH v2 0/2] l2 hardware accelerated macvlans
From: John Fastabend @ 2013-11-05 15:17 UTC (permalink / raw)
To: Vlad Yasevich
Cc: nhorman, alexander.h.duyck, netdev, andy, davem,
jeffrey.t.kirsher
In-Reply-To: <5279051B.6000406@gmail.com>
On 11/5/2013 6:47 AM, Vlad Yasevich wrote:
> Hi John
>
[...]
>> series. It would be best (I think) to use the software
>> path for macvlan to macvlan traffic and save the PCIe
>> bus. Also this only allows for layer 2 mac forwarding
>> where some hardware supports more interesting forwarding
>> capabilities. Integrating with OVS may be useful here.
>
> This seems to be saying that for macvlan-macvlan
> case, you still prefere to do software based forwarding, but
> patch 1 in the series seem to always attempt to do hardware
> offloaded forwarding regardless of traffic and macvlan type.
> Can you clarify.
>
> Thanks
> -vlad
>
This series always attempts to do hardware offload even in the
macvlan-macvlan case as you note. I'm suggesting a further
optimization might be to use the software based forwarding in
this case. My plan is to investigate this after I get the initial
series completed.
.John
^ permalink raw reply
* Re: [patch net-next 2/3] netfilter: ip6_tables: use reasm skb for matching
From: Jiri Pirko @ 2013-11-05 15:01 UTC (permalink / raw)
To: Patrick McHardy
Cc: Florian Westphal, netdev, davem, pablo, netfilter-devel, yoshfuji,
kadlec, mleitner, kuznet, jmorris, wensong, horms, ja, edumazet,
pshelar, jasowang, alexander.h.duyck, coreteam
In-Reply-To: <20131105134118.GA5818@macbook.localnet>
Tue, Nov 05, 2013 at 02:41:19PM CET, kaber@trash.net wrote:
>On Tue, Nov 05, 2013 at 02:32:05PM +0100, Florian Westphal wrote:
>> Jiri Pirko <jiri@resnulli.us> wrote:
>> > This patch fixes for example following situation:
>> > On HOSTA do:
>> > ip6tables -I INPUT -p icmpv6 -j DROP
>> > ip6tables -I INPUT -p icmpv6 -m icmp6 --icmpv6-type 128 -j ACCEPT
>>
>> untested:
>>
>> -A INPUT -p icmpv6 -m icmp6 --icmpv6-type 128 -j ACCEPT
>> -A INPUT -p icmpv6 -m conntrack --ctstatus CONFIRMED -j ACCEPT
>> -A INPUT -p icmpv6 -j DROP
>>
>> > and on HOSTB you do:
>> > ping6 HOSTA -s2000 (MTU is 1500)
>> >
>> > Incoming echo requests will be filtered out on HOSTA. This issue does
>> > not occur with smaller packets than MTU (where fragmentation does not happen).
>>
>> Patrick, any reason not to kill the special-casing (ct has assigned helper or
>> unconfirmed conntrack) in __ipv6_conntrack_in() ?
>>
>> This should make ipv6 frag behaviour consistent; right now its rather
>> confusing from ruleset point of view, especially the first packet
>> of a connection is always seen as reassembled.
>>
>> So with Jiris rules
>>
>> -A INPUT -p icmpv6 -m icmp6 --icmpv6-type 128 -j ACCEPT
>> -A INPUT -p icmpv6 -j DROP
>>
>> ping6 -s $bignum works for the first packet but not for subsequent ones
>> which is quite irritating.
>
>Well, the reason was to avoid unnecessary work doing refragmentation
>unless really required. I know its rather complicated, but IPv6 has
>always required treating fragments manually or using conntrack state.
>
>I'm not objecting to changing this, but the patches as they are are
>not the way to go. First, moving nfct_frag to struct sk_buff seems
I'm a bit lost. What "nfct_frag" are you reffering to here?
>like a real waste of space for this quite rare case. Also, we can't
>just use the reassembled packet in ip6tables, when modifying it we
>will still output the unchanged fragments. An last of all, we'll be
>executing the rules on the reassembled packet multiple times, one
>for each fragment.
Reassembled skb would be only used for matching where no changes takes
place.
End even though, the matching is now done for each fragment skb anyway. The
change is only to do it on different skb. I see no erformance or any
other problem in that.
>
>So if someone wants to change this, simply *only* pass the reassembled
>packet through the netfilter hooks and drop the fragments, as in IPv4.
This is unfortunatelly not possible because in forwarding use case, the
fragments have to be send out as they come in.
^ 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