* Re: [PATCH net-next 3/3] net: allow to leave the buffer fragmented in skb_cow_data()
From: Eric Dumazet @ 2013-11-05 14:33 UTC (permalink / raw)
To: Mathias Krause
Cc: David S. Miller, Steffen Klassert, Herbert Xu, Dmitry Tarnyagin,
netdev
In-Reply-To: <14f30e8f5f8405c1ca73b6d3a554441c1736142d.1381923854.git.mathias.krause@secunet.com>
On Tue, 2013-11-05 at 14:54 +0100, Mathias Krause wrote:
> Do not linearize the buffer per se but only if we're expected to expand
> the tail. All callers can handle fragmented buffers and even expect
> them!
>
> Not linearizing the buffer leads to a small performance improvement for
> the IPsec receive path in case the network driver passed us a fragmented
> buffer.
>
> With this patch applied I was able to increase the throughput of an
> IPsec gateway from 7.12 Gbit/s to 7.28 Gbit/s.
What is the driver you used ?
^ permalink raw reply
* Re: [PATCH net-next 3/3] net: allow to leave the buffer fragmented in skb_cow_data()
From: Mathias Krause @ 2013-11-05 14:43 UTC (permalink / raw)
To: Eric Dumazet
Cc: David S. Miller, Steffen Klassert, Herbert Xu, Dmitry Tarnyagin,
netdev
In-Reply-To: <1383661995.4291.137.camel@edumazet-glaptop2.roam.corp.google.com>
On 05.11.2013 15:33, Eric Dumazet wrote:
> On Tue, 2013-11-05 at 14:54 +0100, Mathias Krause wrote:
>> Do not linearize the buffer per se but only if we're expected to expand
>> the tail. All callers can handle fragmented buffers and even expect
>> them!
>>
>> Not linearizing the buffer leads to a small performance improvement for
>> the IPsec receive path in case the network driver passed us a fragmented
>> buffer.
>>
>> With this patch applied I was able to increase the throughput of an
>> IPsec gateway from 7.12 Gbit/s to 7.28 Gbit/s.
>
> What is the driver you used ?
The device driver is ixgbe driving an Intel X520-T2. Why you're asking?
^ permalink raw reply
* Re: [PATCH v2 0/2] l2 hardware accelerated macvlans
From: Vlad Yasevich @ 2013-11-05 14:47 UTC (permalink / raw)
To: John Fastabend, nhorman, alexander.h.duyck
Cc: netdev, andy, davem, jeffrey.t.kirsher
In-Reply-To: <20131104185717.11802.69282.stgit@jf-dev1-dcblab>
Hi John
On 11/04/2013 02:01 PM, John Fastabend wrote:
> This patch adds support to offload macvlan net_devices to the
> hardware. With these patches packets are pushed to the macvlan
> net_device directly and do not pass through the lower dev.
>
> The patches here have made it through multiple iterations
> each with a slightly different focus. First I tried to
> push these as a new link type called "VMDQ". The patches
> shown here,
>
> http://comments.gmane.org/gmane.linux.network/237617
>
> Following this implementation I renamed the link type
> "VSI" and addressed various comments. Finally Neil
> Horman picked up the patches and integrated the offload
> into the macvlan code. Here,
>
> http://permalink.gmane.org/gmane.linux.network/285658
>
> The attached series is clean-up of his patches, with a
> few fixes. I suspect Neil will add his signed-off-by
> line assuming I didn't mangle anything.
>
> If folks find this series acceptable there are a few
> items we can work on next. First broadcast and multicast
> will use the hardware even for local traffic with this
> 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
>
> As always any comments/feedback welcome.
>
> I'm going to continue testing these on top of ixgbe but
> I believe these are stable and wanted to get them out to
> a wider audience. I've tested multiple offloaded macvlans
> with iperf and netperf using multiple sessions of each
> and seen no issues.
>
> My basic I/O test is here but I've also done some link
> testing and others,
>
> #ip link add link eth2 numtxqueues 4 numrxqueues 4 txqueuelen 50 type macvlan
> #tc qdisc add dev macvlan0 mq
> #iperf -c 10.0.0.1 -P 8 -t 5000 -i 10
>
> Changelog:
> v2: two fixes to ixgbe when all features DCB, FCoE, SR-IOV
> are enabled with macvlans. A VMDQ_P() reference
> should have been accel->pool and do not set the offset
> of the ring index from dfwd add call. The offset is used
> by SR-IOV so clearing it can cause SR-IOV quue index's
> to go sideways. With these fixes testing macvlan's with
> SRIOV enabled was successful.
>
> Thanks,
> John
>
> ---
>
> John Fastabend (2):
> ixgbe: enable l2 forwarding acceleration for macvlans
> net: Add layer 2 hardware acceleration operations for macvlan devices
>
>
> drivers/net/ethernet/intel/ixgbe/ixgbe.h | 20 +
> drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c | 12 +
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 463 +++++++++++++++++++++----
> drivers/net/macvlan.c | 36 ++
> include/linux/if_macvlan.h | 1
> include/linux/netdev_features.h | 2
> include/linux/netdevice.h | 36 ++
> include/uapi/linux/if.h | 1
> net/core/dev.c | 18 +
> net/core/ethtool.c | 1
> net/sched/sch_generic.c | 2
> 11 files changed, 504 insertions(+), 88 deletions(-)
>
^ permalink raw reply
* Re: [patch net-next 3/3] fix skb_morph to preserve skb->sk and skb->destructor pointers
From: Jiri Pirko @ 2013-11-05 14:47 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev, davem, pablo, netfilter-devel, yoshfuji, kadlec, kaber,
mleitner, kuznet, jmorris, wensong, horms, ja, edumazet, pshelar,
jasowang, alexander.h.duyck, coreteam, fw
In-Reply-To: <1383660372.4291.134.camel@edumazet-glaptop2.roam.corp.google.com>
Tue, Nov 05, 2013 at 03:06:12PM CET, eric.dumazet@gmail.com wrote:
>On Tue, 2013-11-05 at 12:02 +0100, Jiri Pirko wrote:
>> Currently __skb_clone sets skb->sk and skb->destructor to NULL. This is
>> not right for skb_morph use case because skb->sk may be previously
>> set (e. g. by xt_TPROXY).
>>
>> Also, during skb_morph the destructor should not be called. It might be
>> previously set, e. g. by xt_TPROXY to sock_edemux, and that would cause
>> put sk while skb is still in flight.
>
>truesize alert. You should add some documentation that skb_morph()
>must not be used in transmit path.
>
>Its not clear to be how this can happen.
>
>skb_morph() being used only from ipv4 defrag (or ipv6 reassembly).
nod
>
>Maybe the problem could be fixed by doing this defrag _before_ setting
>skb->sk ?
skb->sk is set for exmaple in xt_TPROXY that is before reassemly is
done, because reassembly is done after all the netfilter code pass the
skb through. I do not see how this can be changed in the way you are
suggesting.
>
>Also, I would prefer you find a way to put all this logic inside
>skb_morph() instead of adding such complexity in this already complex
>code, I fear the compiler will generate slower code with your patch on
>fast path.
>
>Maybe something as simple as following (untested) patch ?
I had very similar patch prepared. But I did not like it so I chose the
other way. I'm more or less okay with doing this this way though...
>
>Note that the truesize concern might need some care.
>
>diff --git a/net/core/skbuff.c b/net/core/skbuff.c
>index 3735fad5616e..afabfd6ef341 100644
>--- a/net/core/skbuff.c
>+++ b/net/core/skbuff.c
>@@ -793,18 +793,28 @@ static struct sk_buff *__skb_clone(struct sk_buff *n, struct sk_buff *skb)
>
> /**
> * skb_morph - morph one skb into another
>- * @dst: the skb to receive the contents
>+ * @skb: the skb to receive the contents
> * @src: the skb to supply the contents
> *
> * This is identical to skb_clone except that the target skb is
>- * supplied by the user.
>+ * supplied by the user, and that we keep target skb destructor in place,
>+ * meaning this can not be used in transmit path, as skb->truesize might
>+ * change.
> *
> * The target skb is returned upon exit.
> */
>-struct sk_buff *skb_morph(struct sk_buff *dst, struct sk_buff *src)
>+struct sk_buff *skb_morph(struct sk_buff *skb, struct sk_buff *src)
> {
>- skb_release_all(dst);
>- return __skb_clone(dst, src);
>+ struct sock *save_sk = skb->sk;
>+ void (*save_destructor)(struct sk_buff *) = skb->destructor;
>+
>+ skb->sk = NULL;
>+ skb->destructor = NULL;
>+ skb_release_all(skb);
>+ __skb_clone(skb, src);
>+ skb->sk = save_sk;
>+ skb->destructor = save_destructor;
>+ return skb;
> }
> EXPORT_SYMBOL_GPL(skb_morph);
>
>
>
^ 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
* 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 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 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
* [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] 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
* 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
* [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
* [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
* 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
* 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: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
* [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] 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
* 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 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] 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-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 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
* [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
* 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
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