* Re: [PATCH net v3] vti: fix spd lookup: match plaintext pkt, not ipsec pkt
From: Christophe Gouault @ 2013-11-07 12:55 UTC (permalink / raw)
To: Steffen Klassert
Cc: David S. Miller, Herbert Xu, netdev, Saurabh Mohan,
Sergei Shtylyov, Eric Dumazet
In-Reply-To: <20131107112549.GP31491@secunet.com>
Hello Steffen,
I am also interested in knowing Saurabh's intentions regarding the
behavior of policies bound to vti interfaces.
However, please note that setting a policy with a wildcard selector
works in both cases (before or after this patch), so a common test case
can be defined.
Actually the *previous* patch on vti (7263a5187f9e vti: get rid of nf
mark rule in prerouting) introduced significant changes, and implies
behaviors dependant on the kernel version, but it seemed to meet
Saurabh's agreement, as the following thread witnesses:
http://www.spinics.net/lists/netdev/msg253134.html
Best Regards,
Christophe
On 11/07/2013 12:25 PM, Steffen Klassert wrote:
> On Wed, Nov 06, 2013 at 09:05:53AM +0100, Christophe Gouault wrote:
>> 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>
> Hm, this patch breaks my current vti test setup. I would need to
> configure the policies and states dependent on the kernel version
> if we apply this patch...
>
> It would be good to hear from the original author of the vti code
> whether the current behaviour is intentional before we do anything
> here.
^ permalink raw reply
* Re: [PATCH net-next 6/8] bonding: add arp_ip_target netlink support
From: Jiri Pirko @ 2013-11-07 12:56 UTC (permalink / raw)
To: Scott Feldman; +Cc: vfalico, fubar, andy, netdev, shm
In-Reply-To: <C580A3C6-BF26-4316-A6F5-6DB02319B100@cumulusnetworks.com>
Thu, Nov 07, 2013 at 11:56:35AM CET, sfeldma@cumulusnetworks.com wrote:
>
>On Nov 7, 2013, at 12:16 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>
>> Thu, Nov 07, 2013 at 10:43:30AM CET, sfeldma@cumulusnetworks.com wrote:
>>> Add IFLA_BOND_ARP_IP_TARGET to allow get/set of bonding parameter
>>> arp_ip_target via netlink.
>>>
>>> Signed-off-by: Scott Feldman <sfeldma@cumulusnetworks.com>
>>> ---
>>> drivers/net/bonding/bond_netlink.c | 43 ++++++++++++++-
>>> drivers/net/bonding/bond_options.c | 102 ++++++++++++++++++++++++++++++++++++
>>> drivers/net/bonding/bond_sysfs.c | 77 +++------------------------
>>> drivers/net/bonding/bonding.h | 3 +
>>> include/uapi/linux/if_link.h | 1
>>> 5 files changed, 155 insertions(+), 71 deletions(-)
>>>
>>> diff --git a/drivers/net/bonding/bond_netlink.c b/drivers/net/bonding/bond_netlink.c
>>> index 9c50165..e4673ba 100644
>>> --- a/drivers/net/bonding/bond_netlink.c
>>> +++ b/drivers/net/bonding/bond_netlink.c
>>> @@ -29,6 +29,7 @@ static const struct nla_policy bond_policy[IFLA_BOND_MAX + 1] = {
>>> [IFLA_BOND_DOWNDELAY] = { .type = NLA_U32 },
>>> [IFLA_BOND_USE_CARRIER] = { .type = NLA_U8 },
>>> [IFLA_BOND_ARP_INTERVAL] = { .type = NLA_U32 },
>>> + [IFLA_BOND_ARP_IP_TARGET] = { .type = NLA_NESTED },
>>> };
>>>
>>> static int bond_validate(struct nlattr *tb[], struct nlattr *data[])
>>> @@ -109,6 +110,21 @@ static int bond_changelink(struct net_device *bond_dev,
>>> if (err)
>>> return err;
>>> }
>>> + if (data[IFLA_BOND_ARP_IP_TARGET]) {
>>> + struct nlattr *attr;
>>> + int rem;
>>> +
>>> + err = bond_option_arp_ip_target_clear_all(bond);
>>> + if (err)
>>> + return err;
>>> +
>>
>> Hmm. I think this is not correct. I think you should not clear all. They
>> might be needed to be used but for a brief moment, they disappear.
>>
>> Just set or unset them one by one.
>
>That’s a good catch. I should compare existing set with new set and retain entries entries common to both sets (and add/remove uncommon ones).
>
>Just to be clear, for netlink, the idea is to push a set of ip targets addrs as a nested attribute and process as a set. This is consistent with arp_ip_target documentation in Documentation/networking/bonding.txt where arp_ip_target is passed as a comma-separated list of addrs. However, it’s not consistent with the sysfs interface where addrs are added/removed one at a time using “+” or “-“ prefix.
I believe that the behaviour you described is ok.
>
>e.g.:
>
>ip link add bond7 type bond mode 1
>ip link set dev bond7 type bond arp_ip_target 10.0.0.1,10.0.0.5
>ip link set dev bond7 type bond arp_ip_target 10.0.0.1
>
>
>>> @@ -141,6 +159,8 @@ static int bond_fill_info(struct sk_buff *skb,
>>> {
>>> struct bonding *bond = netdev_priv(bond_dev);
>>> struct net_device *slave_dev = bond_option_active_slave_get(bond);
>>> + struct nlattr *targets;
>>> + int i, targets_added;
>>>
>>> if (nla_put_u8(skb, IFLA_BOND_MODE, bond->params.mode))
>>> goto nla_put_failure;
>>> @@ -152,10 +172,12 @@ static int bond_fill_info(struct sk_buff *skb,
>>> if (nla_put_u32(skb, IFLA_BOND_MIIMON, bond->params.miimon))
>>> goto nla_put_failure;
>>>
>>> - if (nla_put_u32(skb, IFLA_BOND_UPDELAY, bond->params.updelay))
>>> + if (nla_put_u32(skb, IFLA_BOND_UPDELAY,
>>> + bond->params.updelay * bond->params.miimon))
>>> goto nla_put_failure;
>>
>> This bit should probably no be here :)
>
>Drats, that change goes with earlier patch. I’ll fix on patch set resend for issue above.
>
>-scott
^ permalink raw reply
* Using HTB over MultiQ
From: Anton 'EvilMan' Danilov @ 2013-11-07 13:12 UTC (permalink / raw)
To: netdev
Hello.
I'm experimenting with high performance linux router with 10G NICs.
On high traffic rates the performance are limited by the lock of root
queue discipline. For avoid impact of locking i've decided to build
QoS scheme over the multiq qdisc.
And I have the issues with use to multiq discipline.
My setup:
1. Multiq qdisc is on top of interface.
2. To every multiq class i've attached htb discipline with own
hierachy of child classes.
3. The filters (u32 with hashing) are attached to the root multiq discipline.
Graphical scheme of hierarchy -
http://pixpin.ru/images/2013/11/07/multiq-hierarchy1.png
Fragments of script:
#add top qdisc and classes
qdisc add dev eth0 root handle 10: multiq
qdisc add dev eth0 parent 10:1 handle 11: htb
class add dev eth0 parent 11: classid 11:1 htb rate 1250Mbit
qdisc add dev eth0 parent 10:2 handle 12: htb
class add dev eth0 parent 12: classid 12:1 htb rate 1250Mbit
qdisc add dev eth0 parent 10:3 handle 13: htb
class add dev eth0 parent 13: classid 13:1 htb rate 1250Mbit
qdisc add dev eth0 parent 10:4 handle 14: htb
class add dev eth0 parent 14: classid 14:1 htb rate 1250Mbit
qdisc add dev eth0 parent 10:5 handle 15: htb
class add dev eth0 parent 15: classid 15:1 htb rate 1250Mbit
qdisc add dev eth0 parent 10:6 handle 16: htb
class add dev eth0 parent 16: classid 16:1 htb rate 1250Mbit
qdisc add dev eth0 parent 10:7 handle 17: htb
class add dev eth0 parent 17: classid 17:1 htb rate 1250Mbit
qdisc add dev eth0 parent 10:8 handle 18: htb
class add dev eth0 parent 18: classid 18:1 htb rate 1250Mbit
#add leaf classes and qdiscs (several hundreds)
...
class add dev eth0 parent 11:1 classid 11:1736 htb rate 1024kbit
qdisc add dev eth0 parent 11:1736 handle 1736 pfifo limit 50
...
But I see zero statistics on the leaf htb classes and nonzero
statistics on the classifier filters:
~$ tc -s -p filter list dev eth1
...
filter parent 10: protocol ip pref 5 u32 fh 2:f2:800 order 2048 key
ht 2 bkt f2 flowid 11:1736 (rule hit 306 success 306)
match IP src xx.xx.xx.xx/30 (success 306 )
...
~$ tc -s -s -d c ls dev eth1 classid 11:1736
class htb 11:1736 parent 11:1 leaf 1736: prio 0 quantum 12800 rate
1024Kbit ceil 1024Kbit burst 1599b/1 mpu 0b overhead 0b cburst 1599b/1
mpu 0b overhead 0b level 0
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
lended: 0 borrowed: 0 giants: 0
tokens: 195312 ctokens: 195312
I think I've lost from view the some aspects of settings.
Has anyone setuped the like complex scheme over the multiq discipline?
--
Anton.
^ permalink raw reply
* [PATCHv2 next-next 2/3] caif: use pskb_put() instead of reimplementing its functionality
From: Mathias Krause @ 2013-11-07 13:18 UTC (permalink / raw)
To: David S. Miller, Steffen Klassert, Herbert Xu
Cc: Dmitry Tarnyagin, Ben Hutchings, Eric Dumazet, netdev,
Mathias Krause, David S. Miller
In-Reply-To: <1383830306-16697-1-git-send-email-mathias.krause@secunet.com>
Also remove the warning for fragmented packets -- skb_cow_data() will
linearize the buffer, removing all fragments.
Signed-off-by: Mathias Krause <mathias.krause@secunet.com>
Cc: Dmitry Tarnyagin <dmitry.tarnyagin@lockless.no>
Cc: "David S. Miller" <davem@davemloft.net>
---
net/caif/cfpkt_skbuff.c | 12 +-----------
1 files changed, 1 insertions(+), 11 deletions(-)
diff --git a/net/caif/cfpkt_skbuff.c b/net/caif/cfpkt_skbuff.c
index 6493351..1be0b52 100644
--- a/net/caif/cfpkt_skbuff.c
+++ b/net/caif/cfpkt_skbuff.c
@@ -203,20 +203,10 @@ int cfpkt_add_body(struct cfpkt *pkt, const void *data, u16 len)
PKT_ERROR(pkt, "cow failed\n");
return -EPROTO;
}
- /*
- * Is the SKB non-linear after skb_cow_data()? If so, we are
- * going to add data to the last SKB, so we need to adjust
- * lengths of the top SKB.
- */
- if (lastskb != skb) {
- pr_warn("Packet is non-linear\n");
- skb->len += len;
- skb->data_len += len;
- }
}
/* All set to put the last SKB and optionally write data there. */
- to = skb_put(lastskb, len);
+ to = pskb_put(skb, lastskb, len);
if (likely(data))
memcpy(to, data, len);
return 0;
--
1.7.2.3
^ permalink raw reply related
* [PATCHv2 next-next 0/3] move pskb_put (was: IPsec improvements)
From: Mathias Krause @ 2013-11-07 13:18 UTC (permalink / raw)
To: David S. Miller, Steffen Klassert, Herbert Xu
Cc: Dmitry Tarnyagin, Ben Hutchings, Eric Dumazet, netdev,
Mathias Krause
This series moves pskb_put() to the core code, making the code
duplication in caif obsolete (patches 1 and 2).
Patch 3 fixes a few kernel-doc issues.
v2 of this series does no longer contain the skb_cow_data() patch and
therefore no performance improvements for IPsec. The change is still
under discussion, but otherwise independent from the above changes.
Please apply!
v2:
- kernel-doc fixes for pskb_put, as noticed by Ben
- dropped skb_cow_data patch as it's still discussed
- added a kernel-doc fixes patch (patch 3)
Mathias Krause (3):
net: move pskb_put() to core code
caif: use pskb_put() instead of reimplementing its functionality
net: skbuff - kernel-doc fixes
include/linux/skbuff.h | 3 ++-
include/net/esp.h | 2 --
net/caif/cfpkt_skbuff.c | 12 +-----------
net/core/skbuff.c | 33 ++++++++++++++++++++++++++++-----
net/xfrm/xfrm_algo.c | 13 -------------
5 files changed, 31 insertions(+), 32 deletions(-)
--
1.7.2.3
^ permalink raw reply
* [PATCHv2 next-next 3/3] net: skbuff - kernel-doc fixes
From: Mathias Krause @ 2013-11-07 13:18 UTC (permalink / raw)
To: David S. Miller, Steffen Klassert, Herbert Xu
Cc: Dmitry Tarnyagin, Ben Hutchings, Eric Dumazet, netdev,
Mathias Krause, David S. Miller
In-Reply-To: <1383830306-16697-1-git-send-email-mathias.krause@secunet.com>
Use "@" to refer to parameters in the kernel-doc description. According
to Documentation/kernel-doc-nano-HOWTO.txt "&" shall be used to refer to
structures only.
Signed-off-by: Mathias Krause <mathias.krause@secunet.com>
Cc: "David S. Miller" <davem@davemloft.net>
---
include/linux/skbuff.h | 2 +-
net/core/skbuff.c | 10 +++++-----
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 491dd6c..036ec7d 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -1357,7 +1357,7 @@ static inline void __skb_fill_page_desc(struct sk_buff *skb, int i,
* @size: the length of the data
*
* As per __skb_fill_page_desc() -- initialises the @i'th fragment of
- * @skb to point to &size bytes at offset @off within @page. In
+ * @skb to point to @size bytes at offset @off within @page. In
* addition updates @skb such that @i is the last fragment.
*
* Does not take any additional reference on the fragment.
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 2fbea08..8c5197f 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -1051,8 +1051,8 @@ EXPORT_SYMBOL(__pskb_copy);
* @ntail: room to add at tail
* @gfp_mask: allocation priority
*
- * Expands (or creates identical copy, if &nhead and &ntail are zero)
- * header of skb. &sk_buff itself is not changed. &sk_buff MUST have
+ * Expands (or creates identical copy, if @nhead and @ntail are zero)
+ * header of @skb. &sk_buff itself is not changed. &sk_buff MUST have
* reference count of 1. Returns zero in the case of success or error,
* if expansion failed. In the last case, &sk_buff is not changed.
*
@@ -2563,14 +2563,14 @@ EXPORT_SYMBOL(skb_prepare_seq_read);
* @data: destination pointer for data to be returned
* @st: state variable
*
- * Reads a block of skb data at &consumed relative to the
+ * Reads a block of skb data at @consumed relative to the
* lower offset specified to skb_prepare_seq_read(). Assigns
- * the head of the data block to &data and returns the length
+ * the head of the data block to @data and returns the length
* of the block or 0 if the end of the skb data or the upper
* offset has been reached.
*
* The caller is not required to consume all of the data
- * returned, i.e. &consumed is typically set to the number
+ * returned, i.e. @consumed is typically set to the number
* of bytes already consumed and the next call to
* skb_seq_read() will return the remaining part of the block.
*
--
1.7.2.3
^ permalink raw reply related
* [PATCHv2 next-next 1/3] net: move pskb_put() to core code
From: Mathias Krause @ 2013-11-07 13:18 UTC (permalink / raw)
To: David S. Miller, Steffen Klassert, Herbert Xu
Cc: Dmitry Tarnyagin, Ben Hutchings, Eric Dumazet, netdev,
Mathias Krause, Steffen Klassert, David S. Miller, Herbert Xu
In-Reply-To: <1383830306-16697-1-git-send-email-mathias.krause@secunet.com>
This function has usage beside IPsec so move it to the core skbuff code.
While doing so, give it some documentation and change its return type to
'unsigned char *' to be in line with skb_put().
Signed-off-by: Mathias Krause <mathias.krause@secunet.com>
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
---
v2: kernel-doc fixes, as noticed by Ben
include/linux/skbuff.h | 1 +
include/net/esp.h | 2 --
net/core/skbuff.c | 23 +++++++++++++++++++++++
net/xfrm/xfrm_algo.c | 13 -------------
4 files changed, 24 insertions(+), 15 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 2e153b6..491dd6c 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -1417,6 +1417,7 @@ static inline void skb_set_tail_pointer(struct sk_buff *skb, const int offset)
/*
* Add data to an sk_buff
*/
+unsigned char *pskb_put(struct sk_buff *skb, struct sk_buff *tail, int len);
unsigned char *skb_put(struct sk_buff *skb, unsigned int len);
static inline unsigned char *__skb_put(struct sk_buff *skb, unsigned int len)
{
diff --git a/include/net/esp.h b/include/net/esp.h
index c92213c..a43be85 100644
--- a/include/net/esp.h
+++ b/include/net/esp.h
@@ -3,8 +3,6 @@
#include <linux/skbuff.h>
-void *pskb_put(struct sk_buff *skb, struct sk_buff *tail, int len);
-
struct ip_esp_hdr;
static inline struct ip_esp_hdr *ip_esp_hdr(const struct sk_buff *skb)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 3735fad..2fbea08 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -1264,6 +1264,29 @@ free_skb:
EXPORT_SYMBOL(skb_pad);
/**
+ * pskb_put - add data to the tail of a potentially fragmented buffer
+ * @skb: start of the buffer to use
+ * @tail: tail fragment of the buffer to use
+ * @len: amount of data to add
+ *
+ * This function extends the used data area of the potentially
+ * fragmented buffer. @tail must be the last fragment of @skb -- or
+ * @skb itself. If this would exceed the total buffer size the kernel
+ * will panic. A pointer to the first byte of the extra data is
+ * returned.
+ */
+
+unsigned char *pskb_put(struct sk_buff *skb, struct sk_buff *tail, int len)
+{
+ if (tail != skb) {
+ skb->data_len += len;
+ skb->len += len;
+ }
+ return skb_put(tail, len);
+}
+EXPORT_SYMBOL_GPL(pskb_put);
+
+/**
* skb_put - add data to a buffer
* @skb: buffer to use
* @len: amount of data to add
diff --git a/net/xfrm/xfrm_algo.c b/net/xfrm/xfrm_algo.c
index ab4ef72..debe733 100644
--- a/net/xfrm/xfrm_algo.c
+++ b/net/xfrm/xfrm_algo.c
@@ -802,17 +802,4 @@ int xfrm_count_pfkey_enc_supported(void)
}
EXPORT_SYMBOL_GPL(xfrm_count_pfkey_enc_supported);
-#if defined(CONFIG_INET_ESP) || defined(CONFIG_INET_ESP_MODULE) || defined(CONFIG_INET6_ESP) || defined(CONFIG_INET6_ESP_MODULE)
-
-void *pskb_put(struct sk_buff *skb, struct sk_buff *tail, int len)
-{
- if (tail != skb) {
- skb->data_len += len;
- skb->len += len;
- }
- return skb_put(tail, len);
-}
-EXPORT_SYMBOL_GPL(pskb_put);
-#endif
-
MODULE_LICENSE("GPL");
--
1.7.2.3
^ permalink raw reply related
* Re: Using HTB over MultiQ
From: Eric Dumazet @ 2013-11-07 14:11 UTC (permalink / raw)
To: Anton 'EvilMan' Danilov; +Cc: netdev
In-Reply-To: <CAEzD07+Haf-Kg52H7GsxC5XiQn2KXozHbxgL4Lvn0grhFXVFmA@mail.gmail.com>
On Thu, 2013-11-07 at 17:12 +0400, Anton 'EvilMan' Danilov wrote:
> Hello.
>
> I'm experimenting with high performance linux router with 10G NICs.
> On high traffic rates the performance are limited by the lock of root
> queue discipline. For avoid impact of locking i've decided to build
> QoS scheme over the multiq qdisc.
>
> And I have the issues with use to multiq discipline.
>
> My setup:
> 1. Multiq qdisc is on top of interface.
> 2. To every multiq class i've attached htb discipline with own
> hierachy of child classes.
> 3. The filters (u32 with hashing) are attached to the root multiq discipline.
>
> Graphical scheme of hierarchy -
> http://pixpin.ru/images/2013/11/07/multiq-hierarchy1.png
>
> Fragments of script:
>
> #add top qdisc and classes
> qdisc add dev eth0 root handle 10: multiq
> qdisc add dev eth0 parent 10:1 handle 11: htb
> class add dev eth0 parent 11: classid 11:1 htb rate 1250Mbit
> qdisc add dev eth0 parent 10:2 handle 12: htb
> class add dev eth0 parent 12: classid 12:1 htb rate 1250Mbit
> qdisc add dev eth0 parent 10:3 handle 13: htb
> class add dev eth0 parent 13: classid 13:1 htb rate 1250Mbit
> qdisc add dev eth0 parent 10:4 handle 14: htb
> class add dev eth0 parent 14: classid 14:1 htb rate 1250Mbit
> qdisc add dev eth0 parent 10:5 handle 15: htb
> class add dev eth0 parent 15: classid 15:1 htb rate 1250Mbit
> qdisc add dev eth0 parent 10:6 handle 16: htb
> class add dev eth0 parent 16: classid 16:1 htb rate 1250Mbit
> qdisc add dev eth0 parent 10:7 handle 17: htb
> class add dev eth0 parent 17: classid 17:1 htb rate 1250Mbit
> qdisc add dev eth0 parent 10:8 handle 18: htb
> class add dev eth0 parent 18: classid 18:1 htb rate 1250Mbit
>
> #add leaf classes and qdiscs (several hundreds)
> ...
> class add dev eth0 parent 11:1 classid 11:1736 htb rate 1024kbit
> qdisc add dev eth0 parent 11:1736 handle 1736 pfifo limit 50
> ...
>
> But I see zero statistics on the leaf htb classes and nonzero
> statistics on the classifier filters:
>
> ~$ tc -s -p filter list dev eth1
> ...
> filter parent 10: protocol ip pref 5 u32 fh 2:f2:800 order 2048 key
> ht 2 bkt f2 flowid 11:1736 (rule hit 306 success 306)
> match IP src xx.xx.xx.xx/30 (success 306 )
> ...
>
> ~$ tc -s -s -d c ls dev eth1 classid 11:1736
> class htb 11:1736 parent 11:1 leaf 1736: prio 0 quantum 12800 rate
> 1024Kbit ceil 1024Kbit burst 1599b/1 mpu 0b overhead 0b cburst 1599b/1
> mpu 0b overhead 0b level 0
> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
> rate 0bit 0pps backlog 0b 0p requeues 0
> lended: 0 borrowed: 0 giants: 0
> tokens: 195312 ctokens: 195312
>
> I think I've lost from view the some aspects of settings.
> Has anyone setuped the like complex scheme over the multiq discipline?
>
I think this is not going to work, because multiqueue selection happens
before applying the filters to find a flowid.
And queue selection selects the queue depending on factors that are not
coupled to your filters, like cpu number
It looks like you want to rate limit a large number of flows, you could
try the following setup :
for ETH in eth0
do
tc qd del dev $ETH root 2>/dev/null
tc qd add dev $ETH root handle 100: mq
for i in `seq 1 8`
do
tc qd add dev $ETH parent 100:$i handle $i fq maxrate 1Mbit
done
done
^ permalink raw reply
* Re: Using HTB over MultiQ
From: Eric Dumazet @ 2013-11-07 14:20 UTC (permalink / raw)
To: Anton 'EvilMan' Danilov; +Cc: netdev
In-Reply-To: <1383833480.9412.58.camel@edumazet-glaptop2.roam.corp.google.com>
On Thu, 2013-11-07 at 06:11 -0800, Eric Dumazet wrote:
> On Thu, 2013-11-07 at 17:12 +0400, Anton 'EvilMan' Danilov wrote:
> > Hello.
> >
> > I'm experimenting with high performance linux router with 10G NICs.
> > On high traffic rates the performance are limited by the lock of root
> > queue discipline. For avoid impact of locking i've decided to build
> > QoS scheme over the multiq qdisc.
> >
Oh well, this is a router.
So I think you need to change the device queue selection so that it only
depends on your filters / htb classes.
Otherwise flows for a particular 'customer' might be spread on the 8
queues, so the rate could be 8 * 1Mbit, instead of 1Mbit.
^ permalink raw reply
* Re: [PATCH net-next v2 1/3] net_sched: tbf: support of 64bit rates
From: Sergei Shtylyov @ 2013-11-07 14:25 UTC (permalink / raw)
To: Yang Yingliang, davem, netdev; +Cc: eric.dumazet, jhs, stephen
In-Reply-To: <1383790412-41944-2-git-send-email-yangyingliang@huawei.com>
Hello.
On 07-11-2013 6:13, Yang Yingliang wrote:
> With psched_ratecfg_precompute(), tbf can deal with 64bit rates.
> Add two new attributes so that tc can use them to break the 32bit
> limit.
> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
[...]
> diff --git a/net/sched/sch_tbf.c b/net/sched/sch_tbf.c
> index b057122..b736517 100644
> --- a/net/sched/sch_tbf.c
> +++ b/net/sched/sch_tbf.c
[...]
> @@ -402,6 +409,13 @@ static int tbf_dump(struct Qdisc *sch, struct sk_buff *skb)
> opt.buffer = PSCHED_NS2TICKS(q->buffer);
> if (nla_put(skb, TCA_TBF_PARMS, sizeof(opt), &opt))
> goto nla_put_failure;
> + if ((q->rate.rate_bytes_ps >= (1ULL << 32)) &&
> + nla_put_u64(skb, TCA_TBF_RATE64, q->rate.rate_bytes_ps))
> + goto nla_put_failure;
> + if (q->peak_present &&
> + (q->peak.rate_bytes_ps >= (1ULL << 32)) &&
> + nla_put_u64(skb, TCA_TBF_PRATE64, q->peak.rate_bytes_ps))
> + goto nla_put_failure;
According to the networking coding style, the *if* continuation lines
should start under the next character after (.
WBR, Sergei
^ permalink raw reply
* Re: [BUG] v3.12-rc5-139-gbdeeab6 assertion failed at drivers/net/bonding/bond_main.c (3398)
From: Veaceslav Falico @ 2013-11-07 14:24 UTC (permalink / raw)
To: David Miller; +Cc: thomas, netdev, fubar, andy, nikolay, robbat2
In-Reply-To: <20131019.184411.2017497732906948451.davem@davemloft.net>
On Sat, Oct 19, 2013 at 06:44:11PM -0400, David Miller wrote:
>From: Veaceslav Falico <vfalico@redhat.com>
>Date: Sat, 19 Oct 2013 22:52:22 +0200
>
>> Fixed in commit b32418705107265dfca5edfe2b547643e53a732e ("bonding:
>> RCUify
>> bond_set_rx_mode()") net-next. It should get into mainline soon.
>
>If it's in net-next it's not going into mainline soon.
>
>A change that fixes a bug should go into 'net', not 'net-next'.
Hi David,
Sorry for bringing this up - completely my fault. There are further reports
of this bug in mainline. I've read the
./Documentation/networking/netdev-FAQ.txt but haven't seen a way to get a
fix that got in net-next to the (correct) net tree.
Is there any way to do it?
Sorry again for the mess :-(.
Thank you!
^ permalink raw reply
* Re: Using HTB over MultiQ
From: Eric Dumazet @ 2013-11-07 14:29 UTC (permalink / raw)
To: Anton 'EvilMan' Danilov; +Cc: netdev
In-Reply-To: <CAEzD07+Haf-Kg52H7GsxC5XiQn2KXozHbxgL4Lvn0grhFXVFmA@mail.gmail.com>
On Thu, 2013-11-07 at 17:12 +0400, Anton 'EvilMan' Danilov wrote:
> But I see zero statistics on the leaf htb classes and nonzero
> statistics on the classifier filters:
>
> ~$ tc -s -p filter list dev eth1
> ...
> filter parent 10: protocol ip pref 5 u32 fh 2:f2:800 order 2048 key
> ht 2 bkt f2 flowid 11:1736 (rule hit 306 success 306)
> match IP src xx.xx.xx.xx/30 (success 306 )
> ...
Filter matches and flowid 11:1736 chosen
But then, when the packet enters HTB, it enters HTB on one of the 8 HTB
trees, and only one of them contains 11:1736 and could queue the packet
into its local pfifo 50.
For 7 others HTB trees, flowid 11:1736 doesn't match any htb class, so
packet is queued into the default queue attached to the HTB tree.
>
> ~$ tc -s -s -d c ls dev eth1 classid 11:1736
> class htb 11:1736 parent 11:1 leaf 1736: prio 0 quantum 12800 rate
> 1024Kbit ceil 1024Kbit burst 1599b/1 mpu 0b overhead 0b cburst 1599b/1
> mpu 0b overhead 0b level 0
> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
> rate 0bit 0pps backlog 0b 0p requeues 0
> lended: 0 borrowed: 0 giants: 0
> tokens: 195312 ctokens: 195312
^ permalink raw reply
* Re: [PATCH net-next v2 2/3] net_sched: fix some checkpatch errors
From: Sergei Shtylyov @ 2013-11-07 14:33 UTC (permalink / raw)
To: Yang Yingliang, davem, netdev; +Cc: eric.dumazet, jhs, stephen
In-Reply-To: <1383790412-41944-3-git-send-email-yangyingliang@huawei.com>
Hello.
On 07-11-2013 6:13, Yang Yingliang wrote:
> There are some checkpatch errors, fix them.
> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
> Suggested-by: Stephen Hemminger <stephen@networkplumber.org>
[...]
> diff --git a/net/sched/act_api.c b/net/sched/act_api.c
> index fd70728..d92a90e9 100644
> --- a/net/sched/act_api.c
> +++ b/net/sched/act_api.c
> @@ -191,7 +191,8 @@ u32 tcf_hash_new_index(u32 *idx_gen, struct tcf_hashinfo *hinfo)
> val = 1;
> } while (tcf_hash_lookup(val, hinfo));
>
> - return (*idx_gen = val);
> + *idx_gen = val;
> + return *idx_gen;
return val;
would have been simpler.
> diff --git a/net/sched/sch_cbq.c b/net/sched/sch_cbq.c
> index 7a42c81..a8f40f5 100644
> --- a/net/sched/sch_cbq.c
> +++ b/net/sched/sch_cbq.c
> @@ -1058,7 +1058,8 @@ static void cbq_normalize_quanta(struct cbq_sched_data *q, int prio)
> cl->quantum = (cl->weight*cl->allot*q->nclasses[prio])/
> q->quanta[prio];
> }
> - if (cl->quantum <= 0 || cl->quantum>32*qdisc_dev(cl->qdisc)->mtu) {
> + if (cl->quantum <= 0 ||
> + cl->quantum > 32*qdisc_dev(cl->qdisc)->mtu) {
According to the networking coding style, the continuation line should
start right under 'cl' on the first line of *if*. The way you did it makes it
harder for the eyes to differentiate the code in the *if* branch from the *if*
expression.
> pr_warning("CBQ: class %08x has bad quantum==%ld, repaired.\n",
> cl->common.classid, cl->quantum);
> cl->quantum = qdisc_dev(cl->qdisc)->mtu/2 + 1;
[...]
WBR, Sergei
^ permalink raw reply
* Re: Using HTB over MultiQ
From: John Fastabend @ 2013-11-07 14:39 UTC (permalink / raw)
To: Eric Dumazet, Anton 'EvilMan' Danilov; +Cc: netdev
In-Reply-To: <1383834021.9412.61.camel@edumazet-glaptop2.roam.corp.google.com>
On 11/7/2013 6:20 AM, Eric Dumazet wrote:
> On Thu, 2013-11-07 at 06:11 -0800, Eric Dumazet wrote:
>> On Thu, 2013-11-07 at 17:12 +0400, Anton 'EvilMan' Danilov wrote:
>>> Hello.
>>>
>>> I'm experimenting with high performance linux router with 10G NICs.
>>> On high traffic rates the performance are limited by the lock of root
>>> queue discipline. For avoid impact of locking i've decided to build
>>> QoS scheme over the multiq qdisc.
>>>
>
> Oh well, this is a router.
>
> So I think you need to change the device queue selection so that it only
> depends on your filters / htb classes.
>
> Otherwise flows for a particular 'customer' might be spread on the 8
> queues, so the rate could be 8 * 1Mbit, instead of 1Mbit.
>
With the multiq qdisc you could attach filter to the root qdisc and use
skbedit to set the queue_mapping field,
#tc filter add dev eth0 parent 1: protocol ip prio 1 u32 \
match ip dst 192.168.0.3 \
action skbedit queue_mapping 3
if you configure the filters to map to the correct classes this would
work.
Or another way would be use mqprio and steer packets to HTB classes
using the skb->priority. The priority can be set by iptables/nftables
or an ingress filter.
.John
^ permalink raw reply
* Re: [PATCH net-next v2 3/3] net_sched: Use pr_debug replace printk(KERN_DEBUG ...)
From: Sergei Shtylyov @ 2013-11-07 14:43 UTC (permalink / raw)
To: Yang Yingliang, davem, netdev; +Cc: eric.dumazet, jhs, stephen
In-Reply-To: <1383790412-41944-4-git-send-email-yangyingliang@huawei.com>
Hello.
On 07-11-2013 6:13, Yang Yingliang wrote:
> Replace printk(KERN_DEBUG ...) with pr_debug() and
Note that this is not an equivalent change: first variant always prints
the message, while pr_debug() only does this if DEBUG is #define'd or dynamic
debugging is enabled.
> replace pr_warning() with pr_warn().
This should probably be in a separate patch.
> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
> ---
> net/sched/sch_cbq.c | 2 +-
> net/sched/sch_dsmark.c | 2 +-
> net/sched/sch_gred.c | 4 ++--
> net/sched/sch_htb.c | 6 +++---
> 4 files changed, 7 insertions(+), 7 deletions(-)
> diff --git a/net/sched/sch_cbq.c b/net/sched/sch_cbq.c
> index a8f40f5..9e3a9dc 100644
> --- a/net/sched/sch_cbq.c
> +++ b/net/sched/sch_cbq.c
> @@ -1060,7 +1060,7 @@ static void cbq_normalize_quanta(struct cbq_sched_data *q, int prio)
> }
> if (cl->quantum <= 0 ||
> cl->quantum > 32*qdisc_dev(cl->qdisc)->mtu) {
> - pr_warning("CBQ: class %08x has bad quantum==%ld, repaired.\n",
> + pr_warn("CBQ: class %08x has bad quantum==%ld, repaired.\n",
> cl->common.classid, cl->quantum);
You should also adjust indentation of the continuation line. Same comment
to the code furhter below...
[...]
> diff --git a/net/sched/sch_htb.c b/net/sched/sch_htb.c
> index f6e8a74..6586f3b 100644
> --- a/net/sched/sch_htb.c
> +++ b/net/sched/sch_htb.c
> @@ -1484,13 +1484,13 @@ static int htb_change_class(struct Qdisc *sch, u32 classid,
> if (!cl->level) {
> cl->quantum = hopt->rate.rate / q->rate2quantum;
> if (!hopt->quantum && cl->quantum < 1000) {
> - pr_warning(
> + pr_warn(
> "HTB: quantum of class %X is small. Consider r2q change.\n",
It would have been good if you moved the string literal to the preceding
line. Same comment to the below code.
WBR, Sergei
^ permalink raw reply
* Re: Using HTB over MultiQ
From: Eric Dumazet @ 2013-11-07 14:54 UTC (permalink / raw)
To: John Fastabend; +Cc: Anton 'EvilMan' Danilov, netdev
In-Reply-To: <527BA63F.7040900@intel.com>
On Thu, 2013-11-07 at 06:39 -0800, John Fastabend wrote:
>
> With the multiq qdisc you could attach filter to the root qdisc and use
> skbedit to set the queue_mapping field,
>
> #tc filter add dev eth0 parent 1: protocol ip prio 1 u32 \
> match ip dst 192.168.0.3 \
> action skbedit queue_mapping 3
>
Oh right, this is the way ;)
I wonder if we can have 'action skbedit rxhash 34' ?
> if you configure the filters to map to the correct classes this would
> work.
>
> Or another way would be use mqprio and steer packets to HTB classes
> using the skb->priority. The priority can be set by iptables/nftables
> or an ingress filter.
Yes, but this might duplicate the 'customer' tree Anton has to put on
the filters anyway ?
^ permalink raw reply
* Re: Using HTB over MultiQ
From: Sergey Popovich @ 2013-11-07 13:49 UTC (permalink / raw)
To: netdev
In-Reply-To: <CAEzD07+Haf-Kg52H7GsxC5XiQn2KXozHbxgL4Lvn0grhFXVFmA@mail.gmail.com>
> But I see zero statistics on the leaf htb classes and nonzero
> statistics on the classifier filters:
>
> ~$ tc -s -p filter list dev eth1
> ...
> filter parent 10: protocol ip pref 5 u32 fh 2:f2:800 order 2048 key
> ht 2 bkt f2 flowid 11:1736 (rule hit 306 success 306)
> match IP src xx.xx.xx.xx/30 (success 306 )
> ...
>
> ~$ tc -s -s -d c ls dev eth1 classid 11:1736
> class htb 11:1736 parent 11:1 leaf 1736: prio 0 quantum 12800 rate
> 1024Kbit ceil 1024Kbit burst 1599b/1 mpu 0b overhead 0b cburst 1599b/1
> mpu 0b overhead 0b level 0
> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
> rate 0bit 0pps backlog 0b 0p requeues 0
> lended: 0 borrowed: 0 giants: 0
> tokens: 195312 ctokens: 195312
>
> I think I've lost from view the some aspects of settings.
> Has anyone setuped the like complex scheme over the multiq discipline?
Since
commit 64153ce0a7b61b2a5cacb01805cbf670142339e9
Author: Eric Dumazet
Date: Thu Jun 6 14:53:16 2013 -0700
net_sched: htb: do not setup default rate estimators
rate estimators do not setup by default. To enable rate estimators
you could try to load module sch_htb with htb_rate_est=1
or echo 1 >/sys/module/sch_htb/parameters/htb_rate_est and recreate
hierarchy.
--
SP5474-RIPE
Sergey Popovich
^ permalink raw reply
* Re: Using HTB over MultiQ
From: John Fastabend @ 2013-11-07 15:06 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Anton 'EvilMan' Danilov, netdev
In-Reply-To: <1383836068.9412.71.camel@edumazet-glaptop2.roam.corp.google.com>
On 11/7/2013 6:54 AM, Eric Dumazet wrote:
> On Thu, 2013-11-07 at 06:39 -0800, John Fastabend wrote:
>
>>
>> With the multiq qdisc you could attach filter to the root qdisc and use
>> skbedit to set the queue_mapping field,
>>
>> #tc filter add dev eth0 parent 1: protocol ip prio 1 u32 \
>> match ip dst 192.168.0.3 \
>> action skbedit queue_mapping 3
>>
>
> Oh right, this is the way ;)
>
> I wonder if we can have 'action skbedit rxhash 34' ?
>
Sure, it should easy enough.
>
>> if you configure the filters to map to the correct classes this would
>> work.
>>
>> Or another way would be use mqprio and steer packets to HTB classes
>> using the skb->priority. The priority can be set by iptables/nftables
>> or an ingress filter.
>
> Yes, but this might duplicate the 'customer' tree Anton has to put on
> the filters anyway ?
>
hmm not sure I understand. As long as customer flows are mapped to the
correct HTB qdisc via skb priority with the correct htb child classes
what would be duplicated?
^ permalink raw reply
* [PATCH] netdev: smc91x: enable for xtensa
From: Baruch Siach @ 2013-11-07 15:16 UTC (permalink / raw)
To: netdev; +Cc: Matthew Davey, Baruch Siach
Tested in VLAB Works Xtensa simulation.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
drivers/net/ethernet/smsc/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/smsc/Kconfig b/drivers/net/ethernet/smsc/Kconfig
index 068fc44..753630f 100644
--- a/drivers/net/ethernet/smsc/Kconfig
+++ b/drivers/net/ethernet/smsc/Kconfig
@@ -6,7 +6,7 @@ config NET_VENDOR_SMSC
bool "SMC (SMSC)/Western Digital devices"
default y
depends on ARM || ISA || MAC || ARM64 || MIPS || M32R || SUPERH || \
- BLACKFIN || MN10300 || COLDFIRE || PCI || PCMCIA
+ BLACKFIN || MN10300 || COLDFIRE || XTENSA || PCI || PCMCIA
---help---
If you have a network (Ethernet) card belonging to this class, say Y
and read the Ethernet-HOWTO, available from
@@ -39,7 +39,7 @@ config SMC91X
select CRC32
select MII
depends on (ARM || M32R || SUPERH || MIPS || BLACKFIN || \
- MN10300 || COLDFIRE || ARM64)
+ MN10300 || COLDFIRE || ARM64 || XTENSA)
---help---
This is a driver for SMC's 91x series of Ethernet chipsets,
including the SMC91C94 and the SMC91C111. Say Y if you want it
--
1.8.4.rc3
^ permalink raw reply related
* Re: Using HTB over MultiQ
From: John Fastabend @ 2013-11-07 15:17 UTC (permalink / raw)
To: John Fastabend; +Cc: Eric Dumazet, Anton 'EvilMan' Danilov, netdev
In-Reply-To: <527BAC8E.1090005@intel.com>
On Thu, Nov 07, 2013 at 07:06:54AM -0800, John Fastabend wrote:
> On 11/7/2013 6:54 AM, Eric Dumazet wrote:
> >On Thu, 2013-11-07 at 06:39 -0800, John Fastabend wrote:
> >
> >>
> >>With the multiq qdisc you could attach filter to the root qdisc and use
> >>skbedit to set the queue_mapping field,
> >>
> >>#tc filter add dev eth0 parent 1: protocol ip prio 1 u32 \
> >> match ip dst 192.168.0.3 \
> >> action skbedit queue_mapping 3
> >>
> >
> >Oh right, this is the way ;)
> >
> >I wonder if we can have 'action skbedit rxhash 34' ?
> >
>
> Sure, it should easy enough.
I think this is all it would take I only compile tested this for now.
If its useful I could send out a real (tested) patch later today.
diff --git a/include/net/tc_act/tc_skbedit.h b/include/net/tc_act/tc_skbedit.h
index e103fe0..3951f7d 100644
--- a/include/net/tc_act/tc_skbedit.h
+++ b/include/net/tc_act/tc_skbedit.h
@@ -27,6 +27,7 @@ struct tcf_skbedit {
u32 flags;
u32 priority;
u32 mark;
+ u32 rxhash;
u16 queue_mapping;
/* XXX: 16-bit pad here? */
};
diff --git a/include/uapi/linux/tc_act/tc_skbedit.h b/include/uapi/linux/tc_act/tc_skbedit.h
index 7a2e910..d5a1d55 100644
--- a/include/uapi/linux/tc_act/tc_skbedit.h
+++ b/include/uapi/linux/tc_act/tc_skbedit.h
@@ -27,6 +27,7 @@
#define SKBEDIT_F_PRIORITY 0x1
#define SKBEDIT_F_QUEUE_MAPPING 0x2
#define SKBEDIT_F_MARK 0x4
+#define SKBEDIT_F_RXHASH 0x8
struct tc_skbedit {
tc_gen;
@@ -39,6 +40,7 @@ enum {
TCA_SKBEDIT_PRIORITY,
TCA_SKBEDIT_QUEUE_MAPPING,
TCA_SKBEDIT_MARK,
+ TCA_SKBEDIT_RXHASH,
__TCA_SKBEDIT_MAX
};
#define TCA_SKBEDIT_MAX (__TCA_SKBEDIT_MAX - 1)
diff --git a/net/sched/act_skbedit.c b/net/sched/act_skbedit.c
index cb42211..f6b6820 100644
--- a/net/sched/act_skbedit.c
+++ b/net/sched/act_skbedit.c
@@ -55,6 +55,8 @@ static int tcf_skbedit(struct sk_buff *skb, const struct tc_action *a,
skb_set_queue_mapping(skb, d->queue_mapping);
if (d->flags & SKBEDIT_F_MARK)
skb->mark = d->mark;
+ if (d->flags & SKBEDIT_F_RXHASH)
+ skb->rxhash = d->rxhash;
spin_unlock(&d->tcf_lock);
return d->tcf_action;
@@ -65,6 +67,7 @@ static const struct nla_policy skbedit_policy[TCA_SKBEDIT_MAX + 1] = {
[TCA_SKBEDIT_PRIORITY] = { .len = sizeof(u32) },
[TCA_SKBEDIT_QUEUE_MAPPING] = { .len = sizeof(u16) },
[TCA_SKBEDIT_MARK] = { .len = sizeof(u32) },
+ [TCA_SKBEDIT_RXHASH] = { .len = sizeof(u32) },
};
static int tcf_skbedit_init(struct net *net, struct nlattr *nla,
@@ -75,7 +78,7 @@ static int tcf_skbedit_init(struct net *net, struct nlattr *nla,
struct tc_skbedit *parm;
struct tcf_skbedit *d;
struct tcf_common *pc;
- u32 flags = 0, *priority = NULL, *mark = NULL;
+ u32 flags = 0, *priority = NULL, *mark = NULL, *rxhash = NULL;
u16 *queue_mapping = NULL;
int ret = 0, err;
@@ -104,6 +107,11 @@ static int tcf_skbedit_init(struct net *net, struct nlattr *nla,
mark = nla_data(tb[TCA_SKBEDIT_MARK]);
}
+ if (tb[TCA_SKBEDIT_RXHASH] != NULL) {
+ flags |= SKBEDIT_F_RXHASH;
+ rxhash = nla_data(tb[TCA_SKBEDIT_RXHASH]);
+ }
+
if (!flags)
return -EINVAL;
@@ -135,6 +143,8 @@ static int tcf_skbedit_init(struct net *net, struct nlattr *nla,
d->queue_mapping = *queue_mapping;
if (flags & SKBEDIT_F_MARK)
d->mark = *mark;
+ if (flags & SKBEDIT_F_RXHASH)
+ d->rxhash = *rxhash;
d->tcf_action = parm->action;
@@ -181,6 +191,9 @@ static int tcf_skbedit_dump(struct sk_buff *skb, struct tc_action *a,
nla_put(skb, TCA_SKBEDIT_MARK, sizeof(d->mark),
&d->mark))
goto nla_put_failure;
+ if ((d->flags & SKBEDIT_F_RXHASH) &&
+ nla_put(skb, TCA_SKBEDIT_RXHASH, sizeof(d->rxhash),
+ &d->rxhash))
t.install = jiffies_to_clock_t(jiffies - d->tcf_tm.install);
t.lastuse = jiffies_to_clock_t(jiffies - d->tcf_tm.lastuse);
t.expires = jiffies_to_clock_t(d->tcf_tm.expires);
^ permalink raw reply related
* Re: Using HTB over MultiQ
From: Eric Dumazet @ 2013-11-07 16:10 UTC (permalink / raw)
To: John Fastabend; +Cc: John Fastabend, Anton 'EvilMan' Danilov, netdev
In-Reply-To: <20131107151727.GA31116@nitbit.x32>
On Thu, 2013-11-07 at 07:17 -0800, John Fastabend wrote:
> I think this is all it would take I only compile tested this for now.
> If its useful I could send out a real (tested) patch later today.
Well, this might be useful, my question was more 'Is it currently
supported', thanks !
^ permalink raw reply
* Re: Using HTB over MultiQ
From: Eric Dumazet @ 2013-11-07 16:13 UTC (permalink / raw)
To: Sergey Popovich; +Cc: netdev
In-Reply-To: <15059450.XJdZrMIbNO@tuxracer>
On Thu, 2013-11-07 at 15:49 +0200, Sergey Popovich wrote:
> commit 64153ce0a7b61b2a5cacb01805cbf670142339e9
> Author: Eric Dumazet
> Date: Thu Jun 6 14:53:16 2013 -0700
>
> net_sched: htb: do not setup default rate estimators
>
> rate estimators do not setup by default. To enable rate estimators
> you could try to load module sch_htb with htb_rate_est=1
> or echo 1 >/sys/module/sch_htb/parameters/htb_rate_est and recreate
> hierarchy.
>
To check if packets went through a class, you do not need
a rate estimator. Its 0 anyway after an idle period.
You have to take a look at counters as in :
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
^ permalink raw reply
* Re: [patch] net: make ndev->irq signed for error handling
From: Mugunthan V N @ 2013-11-07 16:33 UTC (permalink / raw)
To: Dan Carpenter; +Cc: David S. Miller, netdev, linux-kernel, kernel-janitors
In-Reply-To: <20131107122249.GN20521@mwanda>
On Thursday 07 November 2013 05:52 PM, Dan Carpenter wrote:
> On Thu, Nov 07, 2013 at 05:44:38PM +0530, Mugunthan V N wrote:
>> On Thursday 07 November 2013 01:18 PM, Dan Carpenter wrote:
>>> There is a bug in cpsw_probe() where we do:
>>>
>>> ndev->irq = platform_get_irq(pdev, 0);
>>> if (ndev->irq < 0) {
>>>
>>> The problem is that "ndev->irq" is unsigned so the error handling
>>> doesn't work. I have changed it to a regular int.
>>>
>>> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>> ndev->irq is never used any where in the driver, I think its better to
>> remove this part of code from probe. If every one is ok, I can send a
>> patch to remove the code.
> It seems like cpsw_ndo_poll_controller() uses it.
>
>
That can be changed to pass one of the interrupt numbers from priv as
the irq number is not used in interrupt service routine.
Regards
Mugunthan V N
^ permalink raw reply
* [PATCH net-next] net: flow_dissector: small optimizations in IPv4 dissect
From: Eric Dumazet @ 2013-11-07 16:37 UTC (permalink / raw)
To: David Miller; +Cc: netdev
From: Eric Dumazet <edumazet@google.com>
By moving code around, we avoid :
1) A reload of iph->ihl (bit field, so needs a mask)
2) A conditional test (replaced by a conditional mov on x86)
Fast path loads iph->protocol anyway.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/core/flow_dissector.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index 0242035192f1..d6ef17322500 100644
--- a/net/core/flow_dissector.c
+++ b/net/core/flow_dissector.c
@@ -68,13 +68,13 @@ ip:
iph = skb_header_pointer(skb, nhoff, sizeof(_iph), &_iph);
if (!iph || iph->ihl < 5)
return false;
+ nhoff += iph->ihl * 4;
+ ip_proto = iph->protocol;
if (ip_is_fragment(iph))
ip_proto = 0;
- else
- ip_proto = iph->protocol;
+
iph_to_flow_copy_addrs(flow, iph);
- nhoff += iph->ihl * 4;
break;
}
case __constant_htons(ETH_P_IPV6): {
^ permalink raw reply related
* [PATCH net-next 2/3] ipv6: increase maximum lifetime of flow labels
From: Florent Fourcot @ 2013-11-07 16:53 UTC (permalink / raw)
To: netdev; +Cc: Florent Fourcot
In-Reply-To: <1383843194-22945-1-git-send-email-florent.fourcot@enst-bretagne.fr>
If the last RFC 6437 does not give any constraints
for lifetime of flow labels, the previous RFC 3697
spoke of a minimum of 120 seconds between
reattribution of a flow label.
The maximum linger is currently set to 60 seconds
and does not allow this configuration without
CAP_NET_ADMIN right.
This patch increase the maximum linger to 150
seconds, allowing more flexibility to standard
users.
Signed-off-by: Florent Fourcot <florent.fourcot@enst-bretagne.fr>
---
net/ipv6/ip6_flowlabel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/ip6_flowlabel.c b/net/ipv6/ip6_flowlabel.c
index 4a06ed0..5f10b0d 100644
--- a/net/ipv6/ip6_flowlabel.c
+++ b/net/ipv6/ip6_flowlabel.c
@@ -41,7 +41,7 @@
#define FL_MIN_LINGER 6 /* Minimal linger. It is set to 6sec specified
in old IPv6 RFC. Well, it was reasonable value.
*/
-#define FL_MAX_LINGER 60 /* Maximal linger timeout */
+#define FL_MAX_LINGER 150 /* Maximal linger timeout */
/* FL hash table */
--
1.8.4.rc3
^ permalink raw reply related
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