* Re: [PATCH] l2tp: Fix modalias of l2tp_ip
From: David Miller @ 2010-12-08 18:25 UTC (permalink / raw)
To: mmarek; +Cc: jchapman, netdev, linux-kernel
In-Reply-To: <1291639152-26608-1-git-send-email-mmarek@suse.cz>
From: Michal Marek <mmarek@suse.cz>
Date: Mon, 6 Dec 2010 13:39:12 +0100
> Using the SOCK_DGRAM enum results in
> "net-pf-2-proto-SOCK_DGRAM-type-115", so use the numeric value like it
> is done in net/dccp.
>
> Signed-off-by: Michal Marek <mmarek@suse.cz>
Applied, thank you.
^ permalink raw reply
* Re: [patch 1/1] driver/net/benet: fix be_cmd_multicast_set() memcpy bug
From: David Miller @ 2010-12-08 18:27 UTC (permalink / raw)
To: joe.jin
Cc: sathyap, subbus, sarveshwarb, ajitk, netdev, linux-kernel,
greg.marsden, guru.anbalagane
In-Reply-To: <20101206130059.GA19448@joejin-pc.cn.oracle.com>
From: Joe Jin <joe.jin@oracle.com>
Date: Mon, 6 Dec 2010 21:00:59 +0800
> Hi,
>
> Regarding benet be_cmd_multicast_set() function, now using
> netdev_for_each_mc_addr() helper for mac address copy, but
> when copying to req->mac[] did not increase of the index.
>
> Cc: Sathya Perla <sathyap@serverengines.com>
> Cc: Subbu Seetharaman <subbus@serverengines.com>
> Cc: Sarveshwar Bandi <sarveshwarb@serverengines.com>
> Cc: Ajit Khaparde <ajitk@serverengines.com>
> Signed-off-by: Joe Jin <joe.jin@oracle.com>
Applied, thank you.
^ permalink raw reply
* [PATCH] ehea: Fixing LRO configuration
From: leitao @ 2010-12-08 18:31 UTC (permalink / raw)
To: shemminger; +Cc: davem, netdev, Breno Leitao
In order to set LRO on ehea, the user must set a module parameter, which
is not the standard way to do so. This patch adds a way to set LRO using
the ethtool tool.
Signed-off-by: Breno Leitao <leitao@linux.vnet.ibm.com>
diff --git a/drivers/net/ehea/ehea_ethtool.c b/drivers/net/ehea/ehea_ethtool.c
index 75b099c..1f37ee6 100644
--- a/drivers/net/ehea/ehea_ethtool.c
+++ b/drivers/net/ehea/ehea_ethtool.c
@@ -261,6 +261,13 @@ static void ehea_get_ethtool_stats(struct net_device *dev,
}
+static int ehea_set_flags(struct net_device *dev, u32 data)
+{
+ return ethtool_op_set_flags(dev, data, ETH_FLAG_LRO
+ | ETH_FLAG_TXVLAN
+ | ETH_FLAG_RXVLAN);
+}
+
const struct ethtool_ops ehea_ethtool_ops = {
.get_settings = ehea_get_settings,
.get_drvinfo = ehea_get_drvinfo,
@@ -273,6 +280,8 @@ const struct ethtool_ops ehea_ethtool_ops = {
.get_ethtool_stats = ehea_get_ethtool_stats,
.get_rx_csum = ehea_get_rx_csum,
.set_settings = ehea_set_settings,
+ .get_flags = ethtool_op_get_flags,
+ .set_flags = ehea_set_flags,
.nway_reset = ehea_nway_reset, /* Restart autonegotiation */
};
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index a84c389..c7132e8 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -675,7 +675,7 @@ static void ehea_proc_skb(struct ehea_port_res *pr, struct ehea_cqe *cqe,
int vlan_extracted = ((cqe->status & EHEA_CQE_VLAN_TAG_XTRACT) &&
pr->port->vgrp);
- if (use_lro) {
+ if (skb->dev->features && NETIF_F_LRO) {
if (vlan_extracted)
lro_vlan_hwaccel_receive_skb(&pr->lro_mgr, skb,
pr->port->vgrp,
@@ -777,7 +777,7 @@ static int ehea_proc_rwqes(struct net_device *dev,
}
cqe = ehea_poll_rq1(qp, &wqe_index);
}
- if (use_lro)
+ if (dev->features && NETIF_F_LRO)
lro_flush_all(&pr->lro_mgr);
pr->rx_packets += processed;
@@ -3265,6 +3265,9 @@ struct ehea_port *ehea_setup_single_port(struct ehea_adapter *adapter,
| NETIF_F_HW_VLAN_RX | NETIF_F_HW_VLAN_FILTER
| NETIF_F_LLTX;
dev->watchdog_timeo = EHEA_WATCH_DOG_TIMEOUT;
+
+ if (use_lro)
+ dev->features |= NETIF_F_LRO;
INIT_WORK(&port->reset_task, ehea_reset_port);
--
1.7.3.2
^ permalink raw reply related
* Re: [PATCH net-next-2.6] filter: constify sk_run_filter()
From: David Miller @ 2010-12-08 18:34 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1291704609.2769.5.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 07 Dec 2010 07:50:09 +0100
> sk_run_filter() doesnt write on skb, change its prototype to reflect
> this.
>
> Fix two af_packet comments.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: call dev_queue_xmit_nit() after skb_dst_drop()
From: David Miller @ 2010-12-08 18:38 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1291706359.2769.17.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 07 Dec 2010 08:19:19 +0100
> Avoid some atomic ops on dst refcount, calling dev_queue_xmit_nit()
> after skb_dst_drop() in dev_hard_start_xmit().
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: call dev_queue_xmit_nit() after skb_dst_drop()
From: David Miller @ 2010-12-08 18:38 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1291717837.2695.13.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 07 Dec 2010 11:30:37 +0100
> Here is V2 of patch :
>
> [PATCH v2 net-next-2.6] net: call dev_queue_xmit_nit() after skb_dst_drop()
Ahh, ok, I just noticed this.
I will make sure to apply this version instead.
Thanks!
^ permalink raw reply
* Re: (Lack of) specification for RX n-tuple filtering
From: Vladislav Zolotarov @ 2010-12-08 18:39 UTC (permalink / raw)
To: Ben Hutchings
Cc: Dimitris Michailidis, Peter Waskiewicz, netdev@vger.kernel.org,
David Miller
In-Reply-To: <1291828940.2560.17.camel@bwh-desktop>
> > The
> > semantics for a specification of the steam is also quite different. For
> > instance, how do u define a rule to drop all packets with source IP
> > address 192.168.10.200 by means of RXNFC?
>
> Something like this, I think:
>
> struct ethtool_rxnfc insert_rule = {
> .cmd = ETHTOOL_SRXCLSRLINS,
> .flow_type = IP_USER_SPEC,
> .fs = {
> .flow_type = IP_USER_SPEC,
> .h_u.usr_ip4_spec = {
> .ip4src = inet_aton("192.168.10.200"),
> .ip_ver = ETH_RX_NFC_IP4
> },
> .m_u.usr_ip4_spec = {
> .ip4dst = 0xffffffff,
> .l4_4_bytes = 0xffffffff,
> .tos = 0xff,
> .proto = 0xff
> },
> .ring_cookie = RX_CLS_FLOW_DISC,
> .location = 0,
> }
> };
>
Aha. Ok. From the remarks in the upstream ethtool.h I see now that
ethtool_rxnfc has quite wide configuration possibilities (including the
above). I missed it before. ;)
Ben, could u, pls., explain me then what's the difference between
defining the rule as u wrote above on top of -N option (nfc) and
defining the rule doing the same thing on top on -U (n-tuple) option and
when I as a user should prefer one option to another? Are they expected
to be implemented differently from FW/HW perspective?
thanks,
vlad
P.S. I see that ethtool.h from the 2.6.36 tree already has the
ethtool_rxnfc that would allow such a filtering definition however from
the man page of the 2.6.36 version of the ethtool package it's unclear
what should be a command line for such a configuration. Is it supported
with the current ethtool version or maybe I'm missing something in a man
page?
^ permalink raw reply
* Re: pull request: sfc-2.6 2010-12-07
From: David Miller @ 2010-12-08 18:41 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-net-drivers
In-Reply-To: <1291758335.21627.22.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Tue, 07 Dec 2010 21:45:35 +0000
> On Tue, 2010-12-07 at 21:40 +0000, Ben Hutchings wrote:
>> The following changes since commit 46bcf14f44d8f31ecfdc8b6708ec15a3b33316d9:
>>
>> filter: fix sk_filter rcu handling (2010-12-06 09:29:43 -0800)
>>
>> are available in the git repository at:
>> git://git.kernel.org/linux/kernel/git/bwh/sfc-2.6.git sfc-2.6.37
>
> That should of course be:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/bwh/sfc-2.6.git sfc-2.6.37
>
> Ben.
Pulled, thanks a lot Ben.
^ permalink raw reply
* Re: [PATCH] af_packet: eliminate pgv_to_page on some arches
From: David Miller @ 2010-12-08 18:44 UTC (permalink / raw)
To: xiaosuo; +Cc: eric.dumazet, jpirko, nhorman, netdev
In-Reply-To: <1291731976-15793-1-git-send-email-xiaosuo@gmail.com>
From: Changli Gao <xiaosuo@gmail.com>
Date: Tue, 7 Dec 2010 22:26:16 +0800
> Some arches don't need flush_dcache_page(), and don't implement it, so
> we can eliminate pgv_to_page() calls on those arches.
>
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] af_packet: fix freeing pg_vec twice on error path
From: David Miller @ 2010-12-08 18:44 UTC (permalink / raw)
To: xiaosuo; +Cc: eric.dumazet, jpirko, nhorman, netdev
In-Reply-To: <1291734318-17989-1-git-send-email-xiaosuo@gmail.com>
From: Changli Gao <xiaosuo@gmail.com>
Date: Tue, 7 Dec 2010 23:05:18 +0800
> It is introduced in:
> commit 0e3125c755445664f00ad036e4fc2cd32fd52877
> Author: Neil Horman <nhorman@tuxdriver.com>
> Date: Tue Nov 16 10:26:47 2010 -0800
>
> packet: Enhance AF_PACKET implementation to not require high order contiguous memory allocation (v4)
>
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] ehea: Fixing LRO configuration
From: Ben Hutchings @ 2010-12-08 18:44 UTC (permalink / raw)
To: leitao; +Cc: shemminger, davem, netdev
In-Reply-To: <1291833062-27446-1-git-send-email-leitao@linux.vnet.ibm.com>
On Wed, 2010-12-08 at 16:31 -0200, leitao@linux.vnet.ibm.com wrote:
> In order to set LRO on ehea, the user must set a module parameter, which
> is not the standard way to do so. This patch adds a way to set LRO using
> the ethtool tool.
[...]
> diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
> index a84c389..c7132e8 100644
> --- a/drivers/net/ehea/ehea_main.c
> +++ b/drivers/net/ehea/ehea_main.c
> @@ -675,7 +675,7 @@ static void ehea_proc_skb(struct ehea_port_res *pr, struct ehea_cqe *cqe,
> int vlan_extracted = ((cqe->status & EHEA_CQE_VLAN_TAG_XTRACT) &&
> pr->port->vgrp);
>
> - if (use_lro) {
> + if (skb->dev->features && NETIF_F_LRO) {
Should be & not &&.
> if (vlan_extracted)
> lro_vlan_hwaccel_receive_skb(&pr->lro_mgr, skb,
> pr->port->vgrp,
> @@ -777,7 +777,7 @@ static int ehea_proc_rwqes(struct net_device *dev,
> }
> cqe = ehea_poll_rq1(qp, &wqe_index);
> }
> - if (use_lro)
> + if (dev->features && NETIF_F_LRO)
Ditto.
Ben.
> lro_flush_all(&pr->lro_mgr);
>
> pr->rx_packets += processed;
> @@ -3265,6 +3265,9 @@ struct ehea_port *ehea_setup_single_port(struct ehea_adapter *adapter,
> | NETIF_F_HW_VLAN_RX | NETIF_F_HW_VLAN_FILTER
> | NETIF_F_LLTX;
> dev->watchdog_timeo = EHEA_WATCH_DOG_TIMEOUT;
> +
> + if (use_lro)
> + dev->features |= NETIF_F_LRO;
>
> INIT_WORK(&port->reset_task, ehea_reset_port);
>
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] isdn/hisax: fix compiler warning on hisax_pci_tbl
From: David Miller @ 2010-12-08 18:51 UTC (permalink / raw)
To: namhyung; +Cc: isdn, netdev, linux-kernel
In-Reply-To: <1291733346-11573-1-git-send-email-namhyung@gmail.com>
From: Namhyung Kim <namhyung@gmail.com>
Date: Tue, 7 Dec 2010 23:49:06 +0900
> Annotate hisax_pci_tbl as '__used' to fix following warning:
>
> CC drivers/isdn/hisax/config.o
> drivers/isdn/hisax/config.c:1920: warning: ‘hisax_pci_tbl’ defined but not used
>
> Signed-off-by: Namhyung Kim <namhyung@gmail.com>
This only happens because the hisax driver doesn't actually use this table
for probing. Each sub-driver does it's own thing.
What a mess.
Anyways, applied, thank you.
^ permalink raw reply
* [PATCH] ehea: Fixing LRO configuration
From: leitao @ 2010-12-08 18:51 UTC (permalink / raw)
To: bhutchings; +Cc: shemminger, davem, netdev, Breno Leitao
In-Reply-To: <1291833849.2560.26.camel@bwh-desktop>
In order to set LRO on ehea, the user must set a module parameter, which
is not the standard way to do so. This patch adds a way to set LRO using
the ethtool tool.
Signed-off-by: Breno Leitao <leitao@linux.vnet.ibm.com>
diff --git a/drivers/net/ehea/ehea_ethtool.c b/drivers/net/ehea/ehea_ethtool.c
index 75b099c..1f37ee6 100644
--- a/drivers/net/ehea/ehea_ethtool.c
+++ b/drivers/net/ehea/ehea_ethtool.c
@@ -261,6 +261,13 @@ static void ehea_get_ethtool_stats(struct net_device *dev,
}
+static int ehea_set_flags(struct net_device *dev, u32 data)
+{
+ return ethtool_op_set_flags(dev, data, ETH_FLAG_LRO
+ | ETH_FLAG_TXVLAN
+ | ETH_FLAG_RXVLAN);
+}
+
const struct ethtool_ops ehea_ethtool_ops = {
.get_settings = ehea_get_settings,
.get_drvinfo = ehea_get_drvinfo,
@@ -273,6 +280,8 @@ const struct ethtool_ops ehea_ethtool_ops = {
.get_ethtool_stats = ehea_get_ethtool_stats,
.get_rx_csum = ehea_get_rx_csum,
.set_settings = ehea_set_settings,
+ .get_flags = ethtool_op_get_flags,
+ .set_flags = ehea_set_flags,
.nway_reset = ehea_nway_reset, /* Restart autonegotiation */
};
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index a84c389..c7132e8 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -675,7 +675,7 @@ static void ehea_proc_skb(struct ehea_port_res *pr, struct ehea_cqe *cqe,
int vlan_extracted = ((cqe->status & EHEA_CQE_VLAN_TAG_XTRACT) &&
pr->port->vgrp);
- if (use_lro) {
+ if (skb->dev->features & NETIF_F_LRO) {
if (vlan_extracted)
lro_vlan_hwaccel_receive_skb(&pr->lro_mgr, skb,
pr->port->vgrp,
@@ -777,7 +777,7 @@ static int ehea_proc_rwqes(struct net_device *dev,
}
cqe = ehea_poll_rq1(qp, &wqe_index);
}
- if (use_lro)
+ if (dev->features & NETIF_F_LRO)
lro_flush_all(&pr->lro_mgr);
pr->rx_packets += processed;
@@ -3265,6 +3265,9 @@ struct ehea_port *ehea_setup_single_port(struct ehea_adapter *adapter,
| NETIF_F_HW_VLAN_RX | NETIF_F_HW_VLAN_FILTER
| NETIF_F_LLTX;
dev->watchdog_timeo = EHEA_WATCH_DOG_TIMEOUT;
+
+ if (use_lro)
+ dev->features |= NETIF_F_LRO;
INIT_WORK(&port->reset_task, ehea_reset_port);
--
1.7.3.2
^ permalink raw reply related
* Re: [PATCH] X.25: decrement netdev reference counts on unload
From: David Miller @ 2010-12-08 18:55 UTC (permalink / raw)
To: apollon; +Cc: netdev
In-Reply-To: <20101207194330.GA22608@noc.grnet.gr>
From: Apollon Oikonomopoulos <apollon@noc.grnet.gr>
Date: Tue, 7 Dec 2010 21:43:30 +0200
> x25 does not decrement the network device reference counts on module unload.
> Thus unregistering any pre-existing interface after unloading the x25 module
> hangs and results in
>
> unregister_netdevice: waiting for tap0 to become free. Usage count = 1
>
> This patch decrements the reference counts of all interfaces in x25_link_free,
> the way it is already done in x25_link_device_down for NETDEV_DOWN events.
>
> Signed-off-by: Apollon Oikonomopoulos <apollon@noc.grnet.gr>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: (Lack of) specification for RX n-tuple filtering
From: Dimitris Michailidis @ 2010-12-08 18:54 UTC (permalink / raw)
To: Ben Hutchings
Cc: Vladislav Zolotarov, Peter Waskiewicz, netdev@vger.kernel.org,
David Miller
In-Reply-To: <1291828940.2560.17.camel@bwh-desktop>
Ben Hutchings wrote:
> On Wed, 2010-12-08 at 18:24 +0200, Vladislav Zolotarov wrote:
>>>> It's a bit worse than that. Currently one can only append filters, not
>>>> insert at a given position, as ethtool_rx_ntuple doesn't have an index
>>>> field. For devices that use TCAMs, where position matters, it's quite an
>>>> obstacle. It also means one cannot modify an existing filter by specifying
>>>> a new filter for the same index.
>>> It looks like drivers for devices that use TCAMs should implement the
>>> RXNFC interface instead.
>>>
>> Ben, from ethtool manpage it sounds like RXNFC option defines the way
>> the RSS hash should be calculated, while SRXNTUPLE is meant to control
>> the destination Rx queue for a stream specified by a filter/filters.
>
> By 'RXNFC interface' I mean ETHTOOL_{G,S}RXCLS* and not
> ETHTOOL_{G,S}RXFH which wrongly share (part of) the same structure..
>
>> The
>> semantics for a specification of the steam is also quite different. For
>> instance, how do u define a rule to drop all packets with source IP
>> address 192.168.10.200 by means of RXNFC?
>
> Something like this, I think:
>
> struct ethtool_rxnfc insert_rule = {
> .cmd = ETHTOOL_SRXCLSRLINS,
> .flow_type = IP_USER_SPEC,
> .fs = {
> .flow_type = IP_USER_SPEC,
> .h_u.usr_ip4_spec = {
> .ip4src = inet_aton("192.168.10.200"),
> .ip_ver = ETH_RX_NFC_IP4
> },
> .m_u.usr_ip4_spec = {
> .ip4dst = 0xffffffff,
> .l4_4_bytes = 0xffffffff,
> .tos = 0xff,
> .proto = 0xff
> },
> .ring_cookie = RX_CLS_FLOW_DISC,
> .location = 0,
> }
> };
I think the mask would be 0 for don't care fields and 1 for care, so
.m_u.usr_ip4_spec.ip4src = htonl(0xffffffff)
.m_u.usr_ip4_spec.ip4dst = htonl(0)
etc
There's a lot of overlap between SRXCLSRLINS and SRXNTUPLE and neither is a
superset. SRXCLSRLINS has the advantage of specifying position but
SRXNTUPLE includes vlan and a device-specific field that are handy.
Also for reporting rules GRXNTUPLE is more flexible than GRXCLSRULE as it
lets the driver specify the information it reports. In fact I've been
thinking of using SRXCLSRLINS and GRXNTUPLE for cxgb4 but haven't gotten
over the ugliness of that yet.
>
> [...]
>> I also agree with Dimitris: what we have here is an offload of some
>> Netfilter functionality to HW. Regardless the HW implementation (TCAM or
>> not) if it's allowed to configure more than one rule for the same
>> protocol the ordering of filtering rules is important: for instance if u
>> change the order of applying the rules in the example below the result
>> of the filtering for the traffic with both VLAN 4 and destination port
>> 3000 will be different.
>
> Our hardware (and, I suspect, the ixgbe hardware) has hash tables for
> specific types of matching. There is some control of precedence between
> different types of match, but that's all.
>
>> ethtool -U ethX flow-type tcp4 vlan 4 action 0
>> ethtool -U ethX flow-type tcp4 dst-port 3000 action 3
>>
>> By the way it's also unclear from the ethtool man page if it's allowed
>> to configure more than one rule for the same protocol. If it's not then
>> the above example is void... ;)
>
> It's allowed, but precedence is unspecified.
>
>> However, if we want to define a proper
>> filtering interface I think we shouldn't restrict the driver
>> implementation from defining a set of rules for the same protocol,
>> allowing not to though.
>>
>> So, I think that attaching an index to each rule could be a good idea -
>> this would allow us both inserting rules at the desired positions in the
>> filtering rule table and editing the existing rules.
>
> This really sounds like the RXNFC interface.
>
>> It's also unclear what is the relation between RXNFC and SRXNTUPLE. The
>> last in general may override the decision made based on the hash result.
>> So, it sounds like applying rules of SRXNTUPLE should come before
>> applying the RSS logic and only if there was no match RSS should be
>> applied to that frame. Do I get it right?
>
> That's right.
It can be more involved than this. Our HW allows a rule to select a
different part of the RSS table so you get a filter hit and still do RSS
afterwards if you want. Current ethtool interfaces do not support this,
basically it would be a different action for either SRXNTUPLE or SRXCLSRLINS.
>
> Ben.
>
^ permalink raw reply
* Re: (Lack of) specification for RX n-tuple filtering
From: Ben Hutchings @ 2010-12-08 19:02 UTC (permalink / raw)
To: Vladislav Zolotarov
Cc: Dimitris Michailidis, Peter Waskiewicz, netdev@vger.kernel.org,
David Miller
In-Reply-To: <1291833578.17102.69.camel@lb-tlvb-vladz>
On Wed, 2010-12-08 at 20:39 +0200, Vladislav Zolotarov wrote:
> > > The
> > > semantics for a specification of the steam is also quite different. For
> > > instance, how do u define a rule to drop all packets with source IP
> > > address 192.168.10.200 by means of RXNFC?
> >
> > Something like this, I think:
> >
> > struct ethtool_rxnfc insert_rule = {
> > .cmd = ETHTOOL_SRXCLSRLINS,
> > .flow_type = IP_USER_SPEC,
> > .fs = {
> > .flow_type = IP_USER_SPEC,
> > .h_u.usr_ip4_spec = {
> > .ip4src = inet_aton("192.168.10.200"),
> > .ip_ver = ETH_RX_NFC_IP4
> > },
> > .m_u.usr_ip4_spec = {
> > .ip4dst = 0xffffffff,
> > .l4_4_bytes = 0xffffffff,
> > .tos = 0xff,
> > .proto = 0xff
> > },
> > .ring_cookie = RX_CLS_FLOW_DISC,
> > .location = 0,
> > }
> > };
> >
>
> Aha. Ok. From the remarks in the upstream ethtool.h I see now that
> ethtool_rxnfc has quite wide configuration possibilities (including the
> above). I missed it before. ;)
>
> Ben, could u, pls., explain me then what's the difference between
> defining the rule as u wrote above on top of -N option (nfc) and
> defining the rule doing the same thing on top on -U (n-tuple) option and
> when I as a user should prefer one option to another? Are they expected
> to be implemented differently from FW/HW perspective?
The -N option modifies the hash function for all flows of a specific
type (using ETHTOOL_SRXFH) whereas the -U option steers a specific flow
or set of flows (using ETHTOOL_SRXNTUPLE). The implementation of the -U
option could potentially be made to fallback to ETHTOOL_SRXCLSRLINS if
vlan_tag and user_def are not specified.
> thanks,
> vlad
>
> P.S. I see that ethtool.h from the 2.6.36 tree already has the
> ethtool_rxnfc that would allow such a filtering definition however from
> the man page of the 2.6.36 version of the ethtool package it's unclear
> what should be a command line for such a configuration. Is it supported
> with the current ethtool version or maybe I'm missing something in a man
> page?
It's not supported. Santwona Behera implemented the kernel side of this
but so far as I know he never sent any patches for ethtool.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: (Lack of) specification for RX n-tuple filtering
From: Vladislav Zolotarov @ 2010-12-08 19:10 UTC (permalink / raw)
To: Ben Hutchings
Cc: Dimitris Michailidis, Peter Waskiewicz, netdev@vger.kernel.org,
David Miller
In-Reply-To: <1291834931.2560.42.camel@bwh-desktop>
> The implementation of the -U
> option could potentially be made to fallback to ETHTOOL_SRXCLSRLINS if
> vlan_tag and user_def are not specified.
>
Having said that, don't u think that it could be more user friendly to
extend the ETHTOOL_SRXCLSRLINS interface to handle the lan_tag and
user_def and drop the n-tuple interface at all?
thanks,
vlad
^ permalink raw reply
* Re: (Lack of) specification for RX n-tuple filtering
From: Ben Hutchings @ 2010-12-08 19:14 UTC (permalink / raw)
To: Dimitris Michailidis
Cc: Vladislav Zolotarov, Peter Waskiewicz, netdev@vger.kernel.org,
David Miller
In-Reply-To: <4CFFD470.5090407@chelsio.com>
On Wed, 2010-12-08 at 10:54 -0800, Dimitris Michailidis wrote:
> Ben Hutchings wrote:
> > On Wed, 2010-12-08 at 18:24 +0200, Vladislav Zolotarov wrote:
> >>>> It's a bit worse than that. Currently one can only append filters, not
> >>>> insert at a given position, as ethtool_rx_ntuple doesn't have an index
> >>>> field. For devices that use TCAMs, where position matters, it's quite an
> >>>> obstacle. It also means one cannot modify an existing filter by specifying
> >>>> a new filter for the same index.
> >>> It looks like drivers for devices that use TCAMs should implement the
> >>> RXNFC interface instead.
> >>>
> >> Ben, from ethtool manpage it sounds like RXNFC option defines the way
> >> the RSS hash should be calculated, while SRXNTUPLE is meant to control
> >> the destination Rx queue for a stream specified by a filter/filters.
> >
> > By 'RXNFC interface' I mean ETHTOOL_{G,S}RXCLS* and not
> > ETHTOOL_{G,S}RXFH which wrongly share (part of) the same structure..
> >
> >> The
> >> semantics for a specification of the steam is also quite different. For
> >> instance, how do u define a rule to drop all packets with source IP
> >> address 192.168.10.200 by means of RXNFC?
> >
> > Something like this, I think:
> >
> > struct ethtool_rxnfc insert_rule = {
> > .cmd = ETHTOOL_SRXCLSRLINS,
> > .flow_type = IP_USER_SPEC,
> > .fs = {
> > .flow_type = IP_USER_SPEC,
> > .h_u.usr_ip4_spec = {
> > .ip4src = inet_aton("192.168.10.200"),
> > .ip_ver = ETH_RX_NFC_IP4
> > },
> > .m_u.usr_ip4_spec = {
> > .ip4dst = 0xffffffff,
> > .l4_4_bytes = 0xffffffff,
> > .tos = 0xff,
> > .proto = 0xff
> > },
> > .ring_cookie = RX_CLS_FLOW_DISC,
> > .location = 0,
> > }
> > };
>
> I think the mask would be 0 for don't care fields and 1 for care, so
>
> .m_u.usr_ip4_spec.ip4src = htonl(0xffffffff)
> .m_u.usr_ip4_spec.ip4dst = htonl(0)
> etc
That is definitely the opposite of what ixgbe and sfc do for
ethtool_ntuple_rx_flow_spec, and I believe it is the opposite of what
niu does for ethtool_rx_flow_spec.
[...]
> >> It's also unclear what is the relation between RXNFC and SRXNTUPLE. The
> >> last in general may override the decision made based on the hash result.
> >> So, it sounds like applying rules of SRXNTUPLE should come before
> >> applying the RSS logic and only if there was no match RSS should be
> >> applied to that frame. Do I get it right?
> >
> > That's right.
>
> It can be more involved than this. Our HW allows a rule to select a
> different part of the RSS table so you get a filter hit and still do RSS
> afterwards if you want. Current ethtool interfaces do not support this,
> basically it would be a different action for either SRXNTUPLE or SRXCLSRLINS.
So does the rule specify an offset added to the output of the RSS hash
and indirection table, or can it also select a different indirection
table? Our current hardware also has a filter flag for the former
behaviour... There are still plenty of bits to spare in 'action' and
'ring_cookie' so perhaps we could define a flag for this?
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: (Lack of) specification for RX n-tuple filtering
From: Ben Hutchings @ 2010-12-08 19:14 UTC (permalink / raw)
To: Vladislav Zolotarov
Cc: Dimitris Michailidis, Peter Waskiewicz, netdev@vger.kernel.org,
David Miller
In-Reply-To: <1291835453.24019.13.camel@lb-tlvb-vladz>
On Wed, 2010-12-08 at 21:10 +0200, Vladislav Zolotarov wrote:
> > The implementation of the -U
> > option could potentially be made to fallback to ETHTOOL_SRXCLSRLINS if
> > vlan_tag and user_def are not specified.
> >
>
> Having said that, don't u think that it could be more user friendly to
> extend the ETHTOOL_SRXCLSRLINS interface to handle the lan_tag and
> user_def and drop the n-tuple interface at all?
No, we can't remove userland interfaces.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: (Lack of) specification for RX n-tuple filtering
From: Dimitris Michailidis @ 2010-12-08 19:26 UTC (permalink / raw)
To: Ben Hutchings
Cc: Vladislav Zolotarov, Peter Waskiewicz, netdev@vger.kernel.org,
David Miller
In-Reply-To: <1291835644.2560.52.camel@bwh-desktop>
Ben Hutchings wrote:
> On Wed, 2010-12-08 at 10:54 -0800, Dimitris Michailidis wrote:
>> Ben Hutchings wrote:
>>> On Wed, 2010-12-08 at 18:24 +0200, Vladislav Zolotarov wrote:
>>>>>> It's a bit worse than that. Currently one can only append filters, not
>>>>>> insert at a given position, as ethtool_rx_ntuple doesn't have an index
>>>>>> field. For devices that use TCAMs, where position matters, it's quite an
>>>>>> obstacle. It also means one cannot modify an existing filter by specifying
>>>>>> a new filter for the same index.
>>>>> It looks like drivers for devices that use TCAMs should implement the
>>>>> RXNFC interface instead.
>>>>>
>>>> Ben, from ethtool manpage it sounds like RXNFC option defines the way
>>>> the RSS hash should be calculated, while SRXNTUPLE is meant to control
>>>> the destination Rx queue for a stream specified by a filter/filters.
>>> By 'RXNFC interface' I mean ETHTOOL_{G,S}RXCLS* and not
>>> ETHTOOL_{G,S}RXFH which wrongly share (part of) the same structure..
>>>
>>>> The
>>>> semantics for a specification of the steam is also quite different. For
>>>> instance, how do u define a rule to drop all packets with source IP
>>>> address 192.168.10.200 by means of RXNFC?
>>> Something like this, I think:
>>>
>>> struct ethtool_rxnfc insert_rule = {
>>> .cmd = ETHTOOL_SRXCLSRLINS,
>>> .flow_type = IP_USER_SPEC,
>>> .fs = {
>>> .flow_type = IP_USER_SPEC,
>>> .h_u.usr_ip4_spec = {
>>> .ip4src = inet_aton("192.168.10.200"),
>>> .ip_ver = ETH_RX_NFC_IP4
>>> },
>>> .m_u.usr_ip4_spec = {
>>> .ip4dst = 0xffffffff,
>>> .l4_4_bytes = 0xffffffff,
>>> .tos = 0xff,
>>> .proto = 0xff
>>> },
>>> .ring_cookie = RX_CLS_FLOW_DISC,
>>> .location = 0,
>>> }
>>> };
>> I think the mask would be 0 for don't care fields and 1 for care, so
>>
>> .m_u.usr_ip4_spec.ip4src = htonl(0xffffffff)
>> .m_u.usr_ip4_spec.ip4dst = htonl(0)
>> etc
>
> That is definitely the opposite of what ixgbe and sfc do for
> ethtool_ntuple_rx_flow_spec, and I believe it is the opposite of what
> niu does for ethtool_rx_flow_spec.
These are the values as our HW at least wants them. The care bits are 1 in
the mask. It's not a huge deal, the driver can complement the masks.
>
> [...]
>>>> It's also unclear what is the relation between RXNFC and SRXNTUPLE. The
>>>> last in general may override the decision made based on the hash result.
>>>> So, it sounds like applying rules of SRXNTUPLE should come before
>>>> applying the RSS logic and only if there was no match RSS should be
>>>> applied to that frame. Do I get it right?
>>> That's right.
>> It can be more involved than this. Our HW allows a rule to select a
>> different part of the RSS table so you get a filter hit and still do RSS
>> afterwards if you want. Current ethtool interfaces do not support this,
>> basically it would be a different action for either SRXNTUPLE or SRXCLSRLINS.
>
> So does the rule specify an offset added to the output of the RSS hash
> and indirection table, or can it also select a different indirection
> table? Our current hardware also has a filter flag for the former
> behaviour... There are still plenty of bits to spare in 'action' and
> 'ring_cookie' so perhaps we could define a flag for this?
You can partition the indirection table and then a rule can specify that
matching packets should consult region X of the table. The hash value is
not altered, just the part of the overall table it indexes into.
>
> Ben.
>
^ permalink raw reply
* Re: (Lack of) specification for RX n-tuple filtering
From: Ben Hutchings @ 2010-12-08 19:39 UTC (permalink / raw)
To: Vladislav Zolotarov
Cc: Dimitris Michailidis, Peter Waskiewicz, netdev@vger.kernel.org,
David Miller
In-Reply-To: <1291835681.2560.53.camel@bwh-desktop>
On Wed, 2010-12-08 at 19:14 +0000, Ben Hutchings wrote:
> On Wed, 2010-12-08 at 21:10 +0200, Vladislav Zolotarov wrote:
> > > The implementation of the -U
> > > option could potentially be made to fallback to ETHTOOL_SRXCLSRLINS if
> > > vlan_tag and user_def are not specified.
> > >
> >
> > Having said that, don't u think that it could be more user friendly to
> > extend the ETHTOOL_SRXCLSRLINS interface to handle the lan_tag and
> > user_def and drop the n-tuple interface at all?
>
> No, we can't remove userland interfaces.
Having said that, this particular interface is fairly broken...
$ cat test.c
#include <stddef.h>
#include <stdio.h>
#include <linux/ethtool.h>
int main(void)
{
printf("%zd\n", offsetof(struct ethtool_rx_flow_spec, ring_cookie));
return 0;
}
$ cc -m64 -Wall test.c
$ ./a.out
152
$ cc -m32 -Wall test.c
$ ./a.out
148
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* [PATCH v2] net-tcp: Replace time wait bucket msg by counter
From: Tom Herbert @ 2010-12-08 19:42 UTC (permalink / raw)
To: davem, netdev; +Cc: eric.dumazet
Rather than printing the message to the log, use a mib counter to keep
track of the count of occurences of time wait bucket overflow. Reduces
spam in logs.
Signed-off-by: Tom Herbert <therbert@google.com>
---
include/linux/snmp.h | 1 +
net/ipv4/proc.c | 1 +
net/ipv4/tcp_minisocks.c | 2 +-
3 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/include/linux/snmp.h b/include/linux/snmp.h
index ebb0c80..12b2b18 100644
--- a/include/linux/snmp.h
+++ b/include/linux/snmp.h
@@ -230,6 +230,7 @@ enum
LINUX_MIB_TCPMINTTLDROP, /* RFC 5082 */
LINUX_MIB_TCPDEFERACCEPTDROP,
LINUX_MIB_IPRPFILTER, /* IP Reverse Path Filter (rp_filter) */
+ LINUX_MIB_TCPTIMEWAITOVERFLOW, /* TCPTimeWaitOverflow */
__LINUX_MIB_MAX
};
diff --git a/net/ipv4/proc.c b/net/ipv4/proc.c
index 1b48eb1..b14ec7d 100644
--- a/net/ipv4/proc.c
+++ b/net/ipv4/proc.c
@@ -253,6 +253,7 @@ static const struct snmp_mib snmp4_net_list[] = {
SNMP_MIB_ITEM("TCPMinTTLDrop", LINUX_MIB_TCPMINTTLDROP),
SNMP_MIB_ITEM("TCPDeferAcceptDrop", LINUX_MIB_TCPDEFERACCEPTDROP),
SNMP_MIB_ITEM("IPReversePathFilter", LINUX_MIB_IPRPFILTER),
+ SNMP_MIB_ITEM("TCPTimeWaitOverflow", LINUX_MIB_TCPTIMEWAITOVERFLOW),
SNMP_MIB_SENTINEL
};
diff --git a/net/ipv4/tcp_minisocks.c b/net/ipv4/tcp_minisocks.c
index 43cf901..a66735f 100644
--- a/net/ipv4/tcp_minisocks.c
+++ b/net/ipv4/tcp_minisocks.c
@@ -347,7 +347,7 @@ void tcp_time_wait(struct sock *sk, int state, int timeo)
* socket up. We've got bigger problems than
* non-graceful socket closings.
*/
- LIMIT_NETDEBUG(KERN_INFO "TCP: time wait bucket table overflow\n");
+ NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_TCPTIMEWAITOVERFLOW);
}
tcp_update_metrics(sk);
--
1.7.3.1
^ permalink raw reply related
* Re: [PATCH] atm: correct sysfs 'device' link creation and parent relationships
From: David Miller @ 2010-12-08 20:15 UTC (permalink / raw)
To: kay.sievers-tD+1rO4QERM
Cc: dcbw-H+wXaHxf7aLQT0dZR+AlfA, netdev-u79uwXL29TY76Z2rM5mHXA,
duncan.sands-GANU6spQydw, linux-usb-u79uwXL29TY76Z2rM5mHXA,
chas-vT06rRrALxcmhCb6mdbn6A
In-Reply-To: <20101208.101121.71114237.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
From: David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Date: Wed, 08 Dec 2010 10:11:21 -0800 (PST)
> From: Kay Sievers <kay.sievers-tD+1rO4QERM@public.gmane.org>
> Date: Tue, 7 Dec 2010 08:35:53 +0100
>
>> On Sun, Dec 5, 2010 at 23:17, Dan Williams <dcbw-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>>> The ATM subsystem was incorrectly creating the 'device' link for ATM
>>> nodes in sysfs. This led to incorrect device/parent relationships
>>> exposed by sysfs and udev. Instead of rolling the 'device' link by hand
>>> in the generic ATM code, pass each ATM driver's bus device down to the
>>> sysfs code and let sysfs do this stuff correctly.
>>
>> Looks good to me.
>
> I've applied this to net-2.6, thanks Dan.
Actually I'm reverting, it breaks the build.
Did you even grep for "atm_dev_register()" after changning the number
of arguments, or were you depending upon build failures to guide you?
Please never do the latter, as it always leads to things like this.
drivers/atm/fore200e.c:2577:7: error: too few arguments to function 'atm_dev_register'
drivers/atm/iphase.c:3175:2: error: too few arguments to function 'atm_dev_register'
...
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] net-tcp: Replace time wait bucket msg by counter
From: David Miller @ 2010-12-08 20:16 UTC (permalink / raw)
To: therbert; +Cc: netdev, eric.dumazet
In-Reply-To: <alpine.DEB.2.00.1012081139180.2652@pokey.mtv.corp.google.com>
From: Tom Herbert <therbert@google.com>
Date: Wed, 8 Dec 2010 11:42:38 -0800 (PST)
> Rather than printing the message to the log, use a mib counter to keep
> track of the count of occurences of time wait bucket overflow. Reduces
> spam in logs.
>
> Signed-off-by: Tom Herbert <therbert@google.com>
Applied, thanks Tom.
^ permalink raw reply
* Re: [PATCH] ehea: Fixing LRO configuration
From: David Miller @ 2010-12-08 20:19 UTC (permalink / raw)
To: leitao; +Cc: bhutchings, shemminger, netdev
In-Reply-To: <1291834280-30787-1-git-send-email-leitao@linux.vnet.ibm.com>
From: leitao@linux.vnet.ibm.com
Date: Wed, 8 Dec 2010 16:51:20 -0200
> In order to set LRO on ehea, the user must set a module parameter, which
> is not the standard way to do so. This patch adds a way to set LRO using
> the ethtool tool.
>
> Signed-off-by: Breno Leitao <leitao@linux.vnet.ibm.com>
Applied, thanks Breno.
^ 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