* Re: [RFC PATCH 1/1] bna: Generic Netlink Interface to collect FW trace
From: Debashis Dutt @ 2011-04-28 17:51 UTC (permalink / raw)
To: David Miller; +Cc: shemminger, rmody, netdev, huangj, amathur, ddutt
In-Reply-To: <20110426.191707.71110914.davem@davemloft.net>
On Tue, Apr 26, 2011 at 7:17 PM, David Miller <davem@davemloft.net> wrote:
> From: Debashis Dutt <debdut@gmail.com>
> Date: Tue, 26 Apr 2011 19:16:29 -0700
>
>> However, since the generic netlink is a more generic interface, we could use
>> this infrastructure in the driver for commands which are not part of
>> other standard tools.
>
> You aren't the only device in the world that might want to provide
> a facility to fetch firmware traces.
>
> This isn't really a niche thing specific to your device at all.
>
David,
Agreed.
In that case should we use debugfs for collecting f/w trace,
but use generic netlink for other h/w specific commands?
Thanks
--Debashis
^ permalink raw reply
* Re: [RFC PATCH 1/1] bna: Generic Netlink Interface to collect FW trace
From: David Miller @ 2011-04-28 19:19 UTC (permalink / raw)
To: debdut; +Cc: shemminger, rmody, netdev, huangj, amathur, ddutt
In-Reply-To: <BANLkTimOuF+HtLxsmTGVpC7ahU_NFy_L2g@mail.gmail.com>
From: Debashis Dutt <debdut@gmail.com>
Date: Thu, 28 Apr 2011 10:51:27 -0700
> In that case should we use debugfs for collecting f/w trace,
> but use generic netlink for other h/w specific commands?
Sure.
^ permalink raw reply
* mail
From: John Salman @ 2011-04-28 19:18 UTC (permalink / raw)
I need you to assist me get some funds out from London.I am a relative of
Hosini MUbarack, former president of Egpyt. These funds will be confiscated if
we do not move it out from London. PLease get back to me if we are willing/able
to assist.You will be given a share of the funds
john
^ permalink raw reply
* Re: [PATCHv8] usbnet: Resubmit interrupt URB if device is open
From: David Miller @ 2011-04-28 19:56 UTC (permalink / raw)
To: pstew; +Cc: netdev, oliver, stern, bhutchings, linux-usb
In-Reply-To: <20110428155227.A7B412031F@glenhelen.mtv.corp.google.com>
From: Paul Stewart <pstew@chromium.org>
Date: Thu, 28 Apr 2011 08:43:37 -0700
> Resubmit interrupt URB if device is open. Use a flag set in
> usbnet_open() to determine this state. Also kill and free
> interrupt URB in usbnet_disconnect().
>
> [Rebased off git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git]
>
> Signed-off-by: Paul Stewart <pstew@chromium.org>
Applied, thank you.
^ permalink raw reply
* Re: [ethtool PATCH 5/6] v4 Add RX packet classification interface
From: Alexander Duyck @ 2011-04-28 20:15 UTC (permalink / raw)
To: Ben Hutchings
Cc: davem@davemloft.net, Kirsher, Jeffrey T, netdev@vger.kernel.org
In-Reply-To: <1303927934.2875.82.camel@bwh-desktop>
On 4/27/2011 11:12 AM, Ben Hutchings wrote:
> On Thu, 2011-04-21 at 13:40 -0700, Alexander Duyck wrote:
[...]
>> + /* verify only one field is setting data field */
>> + if ((fsp->flow_type& FLOW_EXT)&&
>> + (fsp->m_ext.data[0] || fsp->m_ext.data[1])&&
>> + fsp->m_ext.vlan_etype)
>> + return -1;
>> +
>> + /* initialize entire ntuple to all 0xFF */
>> + memset(ntuple, ~0, sizeof(*ntuple));
>
> The comment needs to explain *why* the value is ~0 rather than 0. I
> assume the idea is to set the masks to ~0 if they are not initialised
> below.
This has to do with future compatibility and general setup. By setting
all of the values to ~0 the rule is essentially set to mask everything
and has a default action of drop.
>> + /* set non-filter values */
>> + ntuple->flow_type = fsp->flow_type;
>> + ntuple->action = fsp->ring_cookie;
>> +
>> + /* copy header portion over */
>> + memcpy(&ntuple->h_u,&fsp->h_u, sizeof(fsp->h_u));
>
> This deserves a comment that the two h_u fields are different unions,
> but are defined identically except for padding at the end.
I've added a comment similar to that to the code.
>> + /* copy mask portion over and invert */
>> + memcpy(&ntuple->m_u,&fsp->m_u, sizeof(fsp->m_u));
>> + for (i = 0; i< sizeof(fsp->m_u); i++)
>> + ntuple->m_u.hdata[i] ^= 0xFF;
>> +
>> + /* copy extended fields */
>> + if (fsp->flow_type& FLOW_EXT) {
>> + ntuple->vlan_tag =
>> + ntohs(fsp->h_ext.vlan_tci);
>> + ntuple->vlan_tag_mask =
>> + ~ntohs(fsp->m_ext.vlan_tci);
>> + if (fsp->m_ext.vlan_etype) {
>> + ntuple->data =
>> + ntohl(fsp->h_ext.vlan_etype);
>> + ntuple->data_mask =
>> + ~(u64)ntohl(fsp->m_ext.vlan_etype);
>> + } else {
>> + ntuple->data =
>> + (u64)ntohl(fsp->h_ext.data[0]);
>> + ntuple->data |=
>> + (u64)ntohl(fsp->h_ext.data[1])<< 32;
>> + ntuple->data_mask =
>> + (u64)ntohl(~fsp->m_ext.data[0]);
>> + ntuple->data_mask |=
>> + (u64)ntohl(~fsp->m_ext.data[1])<< 32;
>> + }
>> + }
>
> I think it would be clearer to add:
>
> else {
> ntuple->vlan_tag_mask = ~(u16)0;
> ntuple->data_mask = ~(u64)0;
> }
>
> rather than use memset() above.
I thought about doing that, but the advantage of the memset is that it
covers all of the fields. So in the unlikely event that someone were to
add fields in the future to the h_u/m_u sections of the driver this way
we can guarantee all of the fields that we didn't set are masked.
>> + return 0;
>> +}
>> +
>> static int do_srxntuple(int fd, struct ifreq *ifr)
>> {
>> + struct ethtool_rx_ntuple ntuplecmd;
>> + struct ethtool_value eval;
>> int err;
>>
>> - if (sntuple_changed) {
>> - struct ethtool_rx_ntuple ntuplecmd;
>> + /* verify if Ntuple is supported on the HW */
>
> This comment is inaccurate.
Yeah, it belonged a few lines lower I think it was left over from some
earlier work that was there and when I reordered things to do the
conversion to ntuple first the comment didn't get moved.
>> + err = flow_spec_to_ntuple(&rx_rule_fs,&ntuplecmd.fs);
>> + if (err)
>> + return -1;
>> +
>> + /*
>> + * Check to see if the flag is set for N-tuple, this allows
>> + * us to avoid the possible EINVAL response for the N-tuple
>> + * flag not being set on the device
>> + */
>> + eval.cmd = ETHTOOL_GFLAGS;
>> + ifr->ifr_data = (caddr_t)&eval;
>> + err = ioctl(fd, SIOCETHTOOL, ifr);
>> + if (err || !(eval.data& ETH_FLAG_NTUPLE))
>> + return -1;
>>
>> - ntuplecmd.cmd = ETHTOOL_SRXNTUPLE;
>> - memcpy(&ntuplecmd.fs,&ntuple_fs,
>> - sizeof(struct ethtool_rx_ntuple_flow_spec));
>> + /* send rule via N-tuple */
>> + ntuplecmd.cmd = ETHTOOL_SRXNTUPLE;
>> + ifr->ifr_data = (caddr_t)&ntuplecmd;
>> + err = ioctl(fd, SIOCETHTOOL, ifr);
>>
>> - ifr->ifr_data = (caddr_t)&ntuplecmd;
>> - err = ioctl(fd, SIOCETHTOOL, ifr);
>> - if (err< 0)
>> - perror("Cannot add new RX n-tuple filter");
>> + /*
>> + * Display error only if reponse is something other than op not
>> + * supported. It is possible that the interface uses the network
>> + * flow classifier interface instead of N-tuple.
>> + */
>> + if (err&& errno != EOPNOTSUPP)
>> + perror("Cannot add new rule via N-tuple");
>> +
>> + return err;
>> +}
>> +
>> +static int do_srxclsrule(int fd, struct ifreq *ifr)
>> +{
>> + int err;
>> +
>> + if (rx_class_rule_added) {
>> + /* attempt to add rule via N-tuple specifier */
>> + err = do_srxntuple(fd, ifr);
>> + if (!err)
>> + return 0;
>> +
>> + /* attempt to add rule via network flow classifier */
>> + err = rxclass_rule_ins(fd, ifr,&rx_rule_fs);
>> + if (err< 0) {
>> + fprintf(stderr, "Cannot insert"
>> + " classification rule\n");
>> + return 1;
>> + }
>
> Is this the right order to try them? I'm not sure.
The reason why I chose to do it this way was because it is actually
fewer steps to try doing an ntuple than it is to do a network flow
classifier rule. To fail ntuple I only really need to check the flag,
whereas for network flow classifier I end up having to go through the
path that does init for any rule add which is significantly more overhead.
All of the other changes you suggested for this patch I think I have
implemented for the next version. I'm working on finishing up the
updates now. But I think it will take me a day or to in order to
sufficient testing so I can be confident all the bugs are worked out
after the changes. I'll probably be able to email out the update
patches on Friday.
Thanks,
Alex
^ permalink raw reply
* Re: [PATCH] inet: add RCU protection to inet->opt
From: David Miller @ 2011-04-28 20:20 UTC (permalink / raw)
To: eric.dumazet; +Cc: herbert, netdev
In-Reply-To: <1303415137.2784.23.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 21 Apr 2011 21:45:37 +0200
> [PATCH] inet: add RCU protection to inet->opt
Applied, although I had to add the following build fix to the
final commit:
diff --git a/net/l2tp/l2tp_ip.c b/net/l2tp/l2tp_ip.c
index cc67367..962a607 100644
--- a/net/l2tp/l2tp_ip.c
+++ b/net/l2tp/l2tp_ip.c
@@ -416,7 +416,6 @@ static int l2tp_ip_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *m
int rc;
struct l2tp_ip_sock *lsa = l2tp_ip_sk(sk);
struct inet_sock *inet = inet_sk(sk);
- struct ip_options *opt = inet->opt;
struct rtable *rt = NULL;
int connected = 0;
__be32 daddr;
@@ -471,9 +470,14 @@ static int l2tp_ip_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *m
rt = (struct rtable *) __sk_dst_check(sk, 0);
if (rt == NULL) {
+ struct ip_options_rcu *inet_opt;
+
+ inet_opt = rcu_dereference_protected(inet->inet_opt,
+ sock_owned_by_user(sk));
+
/* Use correct destination address if we have options. */
- if (opt && opt->srr)
- daddr = opt->faddr;
+ if (inet_opt && inet_opt->opt.srr)
+ daddr = inet_opt->opt.faddr;
/* If this fails, retransmit mechanism of transport layer will
* keep trying until route appears or the connection times
^ permalink raw reply related
* Re: [PATCH net-next-2.6] veth: remove unneeded ifname code from veth_newlink()
From: David Miller @ 2011-04-28 20:27 UTC (permalink / raw)
To: mirqus; +Cc: jpirko, netdev, xemul
In-Reply-To: <BANLkTikUAGWhNnCrebQpVttorqVxfD6KWw@mail.gmail.com>
From: Michał Mirosław <mirqus@gmail.com>
Date: Fri, 22 Apr 2011 11:49:40 +0200
> W dniu 22 kwietnia 2011 11:43 użytkownik Michał Mirosław
> <mirqus@gmail.com> napisał:
>> 2011/1/24 Jiri Pirko <jpirko@redhat.com>:
>>> The code is not needed because tb[IFLA_IFNAME] is already
>>> processed in rtnl_newlink(). Remove this redundancy.
>> Hi. This patch broke creation of veth devices. Reverting it fixes the issue.
>>
>> Symptoms:
>>
>> icybox:~# ip link add type veth
>> RTNETLINK answers: File exists
>> icybox:~# ip link add type veth peer veth1
>> icybox:~# ip addr
>> [...]
>> 56: D: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
>> link/ether e6:57:58:52:03:50 brd ff:ff:ff:ff:ff:ff
>> 57: veth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
>> link/ether c2:c2:a2:d5:d5:3a brd ff:ff:ff:ff:ff:ff
>
> Hmm. I was too quick. Reverting it fixes only first problem - "ip link
> add type veth" adds new veth pair now, but "ip link add type veth peer
> veth1" gives the same result as above.
Jiri please look into this regression.
^ permalink raw reply
* Re: [PATCH net-next 1/3] net:use help function of skb_checksum_start_offset to calculate offset
From: David Miller @ 2011-04-28 20:29 UTC (permalink / raw)
To: shanwei; +Cc: netdev, cmetcalf
In-Reply-To: <4DB1617D.30600@cn.fujitsu.com>
From: Shan Wei <shanwei@cn.fujitsu.com>
Date: Fri, 22 Apr 2011 19:07:41 +0800
> Although these are equivalent, but the skb_checksum_start_offset() is more readable.
>
> Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 2/3] net: fullly using NETIF_F_GSO_SOFTWARE macros and NETIF_F_SOFT_FEATURES
From: David Miller @ 2011-04-28 20:30 UTC (permalink / raw)
To: shanwei; +Cc: netdev, kaber, rusty, mst, eric.dumazet, krkumar2, mirq-linux,
joe
In-Reply-To: <4DB16181.9010306@cn.fujitsu.com>
From: Shan Wei <shanwei@cn.fujitsu.com>
Date: Fri, 22 Apr 2011 19:07:45 +0800
>
> Fullly using NETIF_F_GSO_SOFTWARE and NETIF_F_SOFT_FEATURES.
> And some code style tuning. Just compile test.
>
> Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
You've received feedback on this patch and patch #3. Please
address it.
^ permalink raw reply
* Re: [PATCH] net: allow user to change NETIF_F_HIGHDMA
From: David Miller @ 2011-04-28 20:33 UTC (permalink / raw)
To: mirq-linux; +Cc: netdev
In-Reply-To: <20110422163116.37DE613909@rere.qmqm.pl>
From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date: Fri, 22 Apr 2011 18:31:16 +0200 (CEST)
> NETIF_F_HIGHDMA is like any other TX offloads, so allow user to toggle it.
> This is needed later for bridge and bonding convertsion to hw_features.
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Applied.
^ permalink raw reply
* Re: [PATCH] net: fix netdev_increment_features()
From: David Miller @ 2011-04-28 20:33 UTC (permalink / raw)
To: mirq-linux; +Cc: netdev, bhutchings, fubar, andy, shemminger, bridge
In-Reply-To: <20110422163116.3C5C3138DD@rere.qmqm.pl>
From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date: Fri, 22 Apr 2011 18:31:16 +0200 (CEST)
> Simplify and fix netdev_increment_features() to conform to what is
> stated in netdevice.h comments about NETIF_F_ONE_FOR_ALL.
> Include FCoE segmentation and VLAN-challedged flags in computation.
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Applied.
^ permalink raw reply
* Re: [PATCH] bridge: convert br_features_recompute() to ndo_fix_features
From: David Miller @ 2011-04-28 20:33 UTC (permalink / raw)
To: mirq-linux; +Cc: netdev, shemminger, bridge
In-Reply-To: <20110422163116.5BAE713A64@rere.qmqm.pl>
From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date: Fri, 22 Apr 2011 18:31:16 +0200 (CEST)
> Note: netdev_update_features() needs only rtnl_lock as br->port_list
> is only changed while holding it.
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Applied.
^ permalink raw reply
* Re: [PATCH] dsa/mv88e6131: fix unknown multicast/broadcast forwarding on mv88e6085
From: David Miller @ 2011-04-28 20:36 UTC (permalink / raw)
To: buytenh; +Cc: jacmet, netdev
In-Reply-To: <20110426145740.GL1897@wantstofly.org>
From: Lennert Buytenhek <buytenh@wantstofly.org>
Date: Tue, 26 Apr 2011 16:57:40 +0200
> On Tue, Apr 26, 2011 at 01:45:41PM +0200, Peter Korsgaard wrote:
>
>> The 88e6085 has a few differences from the other devices in the port
>> control registers, causing unknown multicast/broadcast packets to get
>> dropped when using the standard port setup.
>>
>> At the same time update kconfig to clarify that the mv88e6085 is now
>> supported.
>>
>> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
>
> Assuming that you've tested this.. :)
>
> Acked-by: Lennert Buytenhek <buytenh@wantstofly.org>
Applied, thanks everyone.
^ permalink raw reply
* Re: [ethtool PATCH 6/6] Update documentation for -u/-U operations
From: Alexander Duyck @ 2011-04-28 20:40 UTC (permalink / raw)
To: Ben Hutchings
Cc: davem@davemloft.net, Kirsher, Jeffrey T, netdev@vger.kernel.org
In-Reply-To: <1303928629.2875.91.camel@bwh-desktop>
On 4/27/2011 11:23 AM, Ben Hutchings wrote:
> On Thu, 2011-04-21 at 13:40 -0700, Alexander Duyck wrote:
>> This patch updates the documentation for the -u/-U operations to include
>> the recent changes made to support addition/deletion/display of network
>> flow classifier rules.
>
> This should be included in the same patch.
I'll combine the two patches for the next release if that is what is
preferred. I was just trying to keep the overall size down by splitting
them since this is documentation only.
>> Signed-off-by: Alexander Duyck<alexander.h.duyck@intel.com>
>> ---
>>
>> ethtool.8.in | 185 +++++++++++++++++++++++++++++-----------------------------
>> ethtool.c | 32 ++++++----
>> 2 files changed, 111 insertions(+), 106 deletions(-)
>>
>> diff --git a/ethtool.8.in b/ethtool.8.in
>> index 12a1d1d..8908351 100644
>> --- a/ethtool.8.in
>> +++ b/ethtool.8.in
>> @@ -42,10 +42,20 @@
>> [\\fB\\$1\\fP\ \\fIN\\fP]
>> ..
>> .\"
>> +.\" .BM - same as above but has a mask field for format "[value N [value-mask N]]"
>> +.\"
>> +.de BM
>> +[\\fB\\$1\\fP\ \\fIN\\fP\ [\\fB\\$1\-mask\\fP\ \\fIN\\fP]]
>
> You've changed the code to accept 'm' as an alternative to
> <field> '-mask', so this should be changed accordingly.
What would be the preferred way of stating that? For now I just
replaced the \\$1\-mask with m. However I am assuming that probably
isn't the best approach either. Should I state somewhere that m can be
replaced with "field name"-mask?
> [...]
>> @@ -236,9 +252,9 @@ ethtool \- query or control network driver and hardware settings
>> .HP
>> .B ethtool \-N
>> .I ethX
>> -.RB [ rx\-flow\-hash \ \*(FL
>> -.RB \ \*(HO]
>> +.RB [ rx-flow-hash \ \*(FL \ \*(HO]
>> .HP
>> +
>
> This looks like an unintentional reversion of part of commit
> db6c0cee6cd956767e1c39109fe81104cc4694cb.
Yeah, my bad. I will have it updated for the next patch. I only really
meant to combine this into one line, I didn't intend to drop the "\-"
formatting fixes you added.
>> .B ethtool \-x|\-\-show\-rxfh\-indir
>> .I ethX
>> .HP
>> @@ -257,54 +273,28 @@ ethtool \- query or control network driver and hardware settings
>> .HP
>> .B ethtool \-u|\-\-show\-ntuple
>> .I ethX
>> -.TP
>> +.BN class-rule
>> +.HP
>> +
>> .BI ethtool\ \-U|\-\-config\-ntuple \ ethX
>> -.RB {
>> -.A3 flow\-type tcp4 udp4 sctp4
>> -.RB [ src\-ip
>> -.IR addr
>> -.RB [ src\-ip\-mask
>> -.IR mask ]]
>> -.RB [ dst\-ip
>> -.IR addr
>> -.RB [ dst\-ip\-mask
>> -.IR mask ]]
>> -.RB [ src\-port
>> -.IR port
>> -.RB [ src\-port\-mask
>> -.IR mask ]]
>> -.RB [ dst\-port
>> -.IR port
>> -.RB [ dst\-port\-mask
>> -.IR mask ]]
>> -.br
>> -.RB | \ flow\-type\ ether
>> -.RB [ src
>> -.IR mac\-addr
>> -.RB [ src\-mask
>> -.IR mask ]]
>> -.RB [ dst
>> -.IR mac\-addr
>> -.RB [ dst\-mask
>> -.IR mask ]]
>> -.RB [ proto
>> -.IR N
>> -.RB [ proto\-mask
>> -.IR mask ]]\ }
>> -.br
>> -.RB [ vlan
>> -.IR VLAN\-tag
>> -.RB [ vlan\-mask
>> -.IR mask ]]
>> -.RB [ user\-def
>> -.IR data
>> -.RB [ user\-def\-mask
>> -.IR mask ]]
>> -.RI action \ N
>> -.
>> -.\" Adjust lines (i.e. full justification) and hyphenate.
>> -.ad
>> -.hy
>
> As do the last 3 deleted lines here.
I put them back so they should be left in place for the next version.
>> +.BN class-rule-del
>> +.RB [\ flow-type \ \*(NC
>> +.RB [ src \ \*(MA\ [ src-mask \ \*(MA]]
>> +.RB [ dst \ \*(MA\ [ dst-mask \ \*(MA]]
>> +.BM proto
>> +.RB [ src-ip \ \*(PA\ [ src-ip-mask \ \*(PA]]
>> +.RB [ dst-ip \ \*(PA\ [ dst-ip-mask \ \*(PA]]
>> +.BM tos
>> +.BM l4proto
>> +.BM src-port
>> +.BM dst-port
>> +.BM spi
>> +.BM vlan-etype
>> +.BM vlan
>> +.BM user-def
>> +.BN action
>> +.BN loc
>> +.RB ]
>
> But these options aren't all applicable to all flow-types.
This is the part that gets messy and I am not sure what the best
approach is. I have more comments on that below. For now what I am
planning to implement to address this is that in the "DESCRIPTION"
section below I add a statement to each specifier that has restrictions
by stating "Valid for flow-types X, Y, and Z."
> [...]
>> diff --git a/ethtool.c b/ethtool.c
>> index 421fe20..e65979d 100644
>> --- a/ethtool.c
>> +++ b/ethtool.c
>> @@ -243,20 +243,26 @@ static struct option {
>> " equal N | weight W0 W1 ...\n" },
>> { "-U", "--config-ntuple", MODE_SCLSRULE, "Configure Rx ntuple filters "
>> "and actions",
>> - " { flow-type tcp4|udp4|sctp4\n"
>> - " [ src-ip ADDR [src-ip-mask MASK] ]\n"
>> - " [ dst-ip ADDR [dst-ip-mask MASK] ]\n"
>> - " [ src-port PORT [src-port-mask MASK] ]\n"
>> - " [ dst-port PORT [dst-port-mask MASK] ]\n"
>> - " | flow-type ether\n"
>> - " [ src MAC-ADDR [src-mask MASK] ]\n"
>> - " [ dst MAC-ADDR [dst-mask MASK] ]\n"
>> - " [ proto N [proto-mask MASK] ] }\n"
>> - " [ vlan VLAN-TAG [vlan-mask MASK] ]\n"
>> - " [ user-def DATA [user-def-mask MASK] ]\n"
>> - " action N\n" },
>> + " [ class-rule-del %d ] |\n"
>> + " [ flow-type ether|ip4|tcp4|udp4|sctp4|ah4|esp4\n"
>> + " [ src %x:%x:%x:%x:%x:%x [src-mask %x:%x:%x:%x:%x:%x] ]\n"
>> + " [ dst %x:%x:%x:%x:%x:%x [dst-mask %x:%x:%x:%x:%x:%x] ]\n"
>> + " [ proto %d [proto-mask MASK] ]\n"
>> + " [ src-ip %d.%d.%d.%d [src-ip-mask %d.%d.%d.%d] ]\n"
>> + " [ dst-ip %d.%d.%d.%d [dst-ip-mask %d.%d.%d.%d] ]\n"
>> + " [ tos %d [tos-mask %x] ]\n"
>> + " [ l4proto %d [l4proto-mask MASK] ]\n"
>> + " [ src-port %d [src-port-mask %x] ]\n"
>> + " [ dst-port %d [dst-port-mask %x] ]\n"
>> + " [ spi %d [spi-mask %x] ]\n"
>> + " [ vlan-etype %x [vlan-etype-mask %x] ]\n"
>> + " [ vlan %x [vlan-mask %x] ]\n"
>> + " [ user-def %x [user-def-mask %x] ]\n"
>> + " [ action %d ]\n"
>> + " [ loc %d]]\n" },
> [...]
>
> Again, it's not clear which options apply to which flow-types, and the
> 'm' shortcut is not documented.
The 'm' part I agree with 100%, however the flow types are going to
become kinda hairy using that approach. You basically end up with
something like this:
flow-type ether
[ src %x:%x:%x:%x:%x:%x [src-mask %x:%x:%x:%x:%x:%x]]
[ dst %x:%x:%x:%x:%x:%x [dst-mask %x:%x:%x:%x:%x:%x]]
[ proto %d [proto-mask %x]]
[ vlan-etype %x [vlan-etype-mask %x]]
[ vlan %x [vlan-mask %x]]
[ user-def %x [user-def-mask %x]]
[ action %d ]
[ loc %d]
flow-type ip4
[ src-ip %d.%d.%d.%d [src-ip-mask %d.%d.%d.%d]]
[ dst-ip %d.%d.%d.%d [dst-ip-mask %d.%d.%d.%d]]
[ tos %d [tos-mask %x]]
[ l4proto %d [l4proto-mask %x]]
[ src-port %d [src-port-mask %x]]
[ dst-port %d [dst-port-mask %x]]
[ spi %d [spi-mask %x]]
[ vlan-etype %x [vlan-etype-mask %x]]
[ vlan %x [vlan-mask %x]]
[ user-def %x [user-def-mask %x]]
[ action %d ]
[ loc %d]
flow-type tcp4|udp4|sctp4
[ src-ip %d.%d.%d.%d [src-ip-mask %d.%d.%d.%d]]
[ dst-ip %d.%d.%d.%d [dst-ip-mask %d.%d.%d.%d]]
[ tos %d [tos-mask %x]]
[ src-port %d [src-port-mask %x]]
[ dst-port %d [dst-port-mask %x]]
[ vlan-etype %x [vlan-etype-mask %x]]
[ vlan %x [vlan-mask %x]]
[ user-def %x [user-def-mask %x]]
[ action %d ]
[ loc %d]
flow-type ah4|esp4
[ src-ip %d.%d.%d.%d [src-ip-mask %d.%d.%d.%d]]
[ dst-ip %d.%d.%d.%d [dst-ip-mask %d.%d.%d.%d]]
[ tos %d [tos-mask %x]]
[ spi %d [spi-mask %x]]
[ vlan-etype %x [vlan-etype-mask %x]]
[ vlan %x [vlan-mask %x]]
[ user-def %x [user-def-mask %x]]
[ action %d ]
[ loc %d]
As you can see it will be a bit oversized to go through and specify
which flow-type options support what fields. If that is what you want I
can implement it that way but for now I would prefer calling out the
flow-type limitations of the fields in the "DESCRIPTION" portion of the
man page.
>
> Ben.
>
Thanks,
Alex
^ permalink raw reply
* Re: [PATCH] tg3: Convert u32 flag,flg2,flg3 uses to bitmap
From: David Miller @ 2011-04-28 20:42 UTC (permalink / raw)
To: mcarlson; +Cc: joe, mchan, eric.dumazet, netdev
In-Reply-To: <20110427162821.GA9762@mcarlson.broadcom.com>
From: "Matt Carlson" <mcarlson@broadcom.com>
Date: Wed, 27 Apr 2011 09:28:21 -0700
> On Tue, Apr 26, 2011 at 11:12:10AM -0700, Joe Perches wrote:
>> Using a bitmap instead of separate u32 flags allows a consistent, simpler
>> and more extensible mechanism to determine capabilities.
>>
>> Convert bitmasks to enum.
>> Add tg3_flag, tg3_flag_clear and tg3_flag_set.
>> Convert the flag & bitmask tests.
>>
>> Signed-off-by: Joe Perches <joe@perches.com>
>
> I looked through it and didn't see any problems. I've queued
> Michael Chan's suggestion into my queue.
>
> Acked-by: Matt Carlson <mcarlson@broadcom.com>
I've applied Joe's change to net-next-2.6, thanks everyone.
^ permalink raw reply
* Re: [NEXT PATCH 1/3] qlcnic: fix memory leak in qlcnic_blink_led.
From: David Miller @ 2011-04-28 20:44 UTC (permalink / raw)
To: amit.salecha
Cc: netdev, ameen.rahman, anirban.chakraborty, sucheta.chakraborty
In-Reply-To: <1303951426-4341-2-git-send-email-amit.salecha@qlogic.com>
From: Amit Kumar Salecha <amit.salecha@qlogic.com>
Date: Wed, 27 Apr 2011 17:43:44 -0700
> From: Sucheta Chakraborty <sucheta.chakraborty@qlogic.com>
>
> o Memory allocated in ETHTOOL_ACTIVE mode, is not getting freed. So,
> in ETHTOOL_ID_INACTIVE mode, return after freeing allocated memory.
> o Using set bit instead of blink_down field, as it is also required
> in internal Loopback test and etc.
>
> Signed-off-by: Sucheta Chakraborty <sucheta.chakraborty@qlogic.com>
> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
Applied.
^ permalink raw reply
* Re: [NEXT PATCH 2/3] qlcnic: support rcv ring configuration through ethtool
From: David Miller @ 2011-04-28 20:44 UTC (permalink / raw)
To: amit.salecha
Cc: netdev, ameen.rahman, anirban.chakraborty, sucheta.chakraborty
In-Reply-To: <1303951426-4341-3-git-send-email-amit.salecha@qlogic.com>
From: Amit Kumar Salecha <amit.salecha@qlogic.com>
Date: Wed, 27 Apr 2011 17:43:45 -0700
> From: Sucheta Chakraborty <sucheta.chakraborty@qlogic.com>
>
> o Support ethtool command ETHTOOL_GCHANNELS and ETHTOOL_SCHANNELS.
> o Number of rcv rings configuration depend upon number of msix vector.
>
> Signed-off-by: Sucheta Chakraborty <sucheta.chakraborty@qlogic.com>
> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
Please address Ben's feedback and resubmit this.
^ permalink raw reply
* Re: [NEXT PATCH 3/3] qlcnic: Support for GBE port settings
From: David Miller @ 2011-04-28 20:44 UTC (permalink / raw)
To: amit.salecha; +Cc: netdev, ameen.rahman, anirban.chakraborty, sony.chacko
In-Reply-To: <1303951426-4341-4-git-send-email-amit.salecha@qlogic.com>
From: Amit Kumar Salecha <amit.salecha@qlogic.com>
Date: Wed, 27 Apr 2011 17:43:46 -0700
> From: Sony Chacko <sony.chacko@qlogic.com>
>
> Enable setting speed and auto negotiation parameters for GbE ports.
> Hardware do not support half duplex setting currently.
>
> o Update driver version to 5.0.17.
>
> Signed-off-by: Sony Chacko <sony.chacko@qlogic.com>
> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
Please resubmit this when you redo patch #2.
^ permalink raw reply
* Re: linux-next: ibmveth runtime errors
From: David Miller @ 2011-04-28 20:46 UTC (permalink / raw)
To: sfr; +Cc: mirq-linux, linuxppc-dev, netdev, santil, linux-next,
linux-kernel
In-Reply-To: <20110428121124.39c036ff.sfr@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 28 Apr 2011 12:11:24 +1000
> From: =?UTF-8?q?Micha=C5=82=20Miros=C5=82aw?= <mirq-linux@rere.qmqm.pl>
> Date: Thu, 28 Apr 2011 11:59:15 +1000
> Subject: [PATCH] net: ibmveth: force reconfiguring checksum settings on
> startup
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> Commit b9367bf3ee6d ("net: ibmveth: convert to hw_features") accidentally
> removed call to ibmveth_set_csum_offload() in ibmveth_probe(). Put the
> call back where it was, but with additional error checking provided
> by ibmveth_set_features().
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> [sfr: dev -> netdev]
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH] inet: add RCU protection to inet->opt
From: Eric Dumazet @ 2011-04-28 20:49 UTC (permalink / raw)
To: David Miller; +Cc: herbert, netdev
In-Reply-To: <20110428.132032.115947683.davem@davemloft.net>
Le jeudi 28 avril 2011 à 13:20 -0700, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Thu, 21 Apr 2011 21:45:37 +0200
>
> > [PATCH] inet: add RCU protection to inet->opt
>
> Applied, although I had to add the following build fix to the
> final commit:
>
> diff --git a/net/l2tp/l2tp_ip.c b/net/l2tp/l2tp_ip.c
> index cc67367..962a607 100644
> --- a/net/l2tp/l2tp_ip.c
> +++ b/net/l2tp/l2tp_ip.c
> @@ -416,7 +416,6 @@ static int l2tp_ip_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *m
> int rc;
> struct l2tp_ip_sock *lsa = l2tp_ip_sk(sk);
> struct inet_sock *inet = inet_sk(sk);
> - struct ip_options *opt = inet->opt;
> struct rtable *rt = NULL;
> int connected = 0;
> __be32 daddr;
> @@ -471,9 +470,14 @@ static int l2tp_ip_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *m
> rt = (struct rtable *) __sk_dst_check(sk, 0);
>
> if (rt == NULL) {
> + struct ip_options_rcu *inet_opt;
> +
> + inet_opt = rcu_dereference_protected(inet->inet_opt,
> + sock_owned_by_user(sk));
> +
> /* Use correct destination address if we have options. */
> - if (opt && opt->srr)
> - daddr = opt->faddr;
> + if (inet_opt && inet_opt->opt.srr)
> + daddr = inet_opt->opt.faddr;
>
> /* If this fails, retransmit mechanism of transport layer will
> * keep trying until route appears or the connection times
Gah... I wonder how I missed it.
Are you sure socket is locked at this point ? ( by a priori call to
lock_sock())
Thanks !
^ permalink raw reply
* Re: [PATCH] inet: add RCU protection to inet->opt
From: David Miller @ 2011-04-28 20:52 UTC (permalink / raw)
To: eric.dumazet; +Cc: herbert, netdev
In-Reply-To: <1304023759.2954.8.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 28 Apr 2011 22:49:19 +0200
> Are you sure socket is locked at this point ? ( by a priori call to
> lock_sock())
Ugh, it's not, I'll commit this fix which is safe because we're only
peeking at inet_opt to fetch the faddr value then we never reference
it again:
diff --git a/net/l2tp/l2tp_ip.c b/net/l2tp/l2tp_ip.c
index 962a607..e13c166 100644
--- a/net/l2tp/l2tp_ip.c
+++ b/net/l2tp/l2tp_ip.c
@@ -472,13 +472,15 @@ static int l2tp_ip_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *m
if (rt == NULL) {
struct ip_options_rcu *inet_opt;
- inet_opt = rcu_dereference_protected(inet->inet_opt,
- sock_owned_by_user(sk));
+ rcu_read_lock();
+ inet_opt = rcu_dereference(inet->inet_opt);
/* Use correct destination address if we have options. */
if (inet_opt && inet_opt->opt.srr)
daddr = inet_opt->opt.faddr;
+ rcu_read_unlock();
+
/* If this fails, retransmit mechanism of transport layer will
* keep trying until route appears or the connection times
* itself out.
^ permalink raw reply related
* Re: [PATCH] inet: add RCU protection to inet->opt
From: Eric Dumazet @ 2011-04-28 20:55 UTC (permalink / raw)
To: David Miller; +Cc: herbert, netdev
In-Reply-To: <20110428.135226.242113407.davem@davemloft.net>
Le jeudi 28 avril 2011 à 13:52 -0700, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Thu, 28 Apr 2011 22:49:19 +0200
>
> > Are you sure socket is locked at this point ? ( by a priori call to
> > lock_sock())
>
> Ugh, it's not, I'll commit this fix which is safe because we're only
> peeking at inet_opt to fetch the faddr value then we never reference
> it again:
>
> diff --git a/net/l2tp/l2tp_ip.c b/net/l2tp/l2tp_ip.c
> index 962a607..e13c166 100644
> --- a/net/l2tp/l2tp_ip.c
> +++ b/net/l2tp/l2tp_ip.c
> @@ -472,13 +472,15 @@ static int l2tp_ip_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *m
> if (rt == NULL) {
> struct ip_options_rcu *inet_opt;
>
> - inet_opt = rcu_dereference_protected(inet->inet_opt,
> - sock_owned_by_user(sk));
> + rcu_read_lock();
> + inet_opt = rcu_dereference(inet->inet_opt);
>
> /* Use correct destination address if we have options. */
> if (inet_opt && inet_opt->opt.srr)
> daddr = inet_opt->opt.faddr;
>
> + rcu_read_unlock();
> +
> /* If this fails, retransmit mechanism of transport layer will
> * keep trying until route appears or the connection times
> * itself out.
Thats perfect, thanks !
^ permalink raw reply
* [PATCH] tg3: Fix failure to enable WoL by default when possible
From: Rafael J. Wysocki @ 2011-04-28 21:02 UTC (permalink / raw)
To: netdev; +Cc: LKML, Matt Carlson, Michael Chan, David Miller
From: Rafael J. Wysocki <rjw@sisk.pl>
tg3 is supposed to enable WoL by default on adapters which support
that, but it fails to do so unless the adapter's
/sys/devices/.../power/wakeup file contains 'enabled' during the
initialization of the adapter. Fix that by making tg3 use
device_set_wakeup_enable() to enable wakeup automatically whenever
WoL should be enabled by default.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
drivers/net/tg3.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
Index: linux-2.6/drivers/net/tg3.c
===================================================================
--- linux-2.6.orig/drivers/net/tg3.c
+++ linux-2.6/drivers/net/tg3.c
@@ -12327,8 +12327,10 @@ static void __devinit tg3_get_eeprom_hw_
if (val & VCPU_CFGSHDW_ASPM_DBNC)
tp->tg3_flags |= TG3_FLAG_ASPM_WORKAROUND;
if ((val & VCPU_CFGSHDW_WOL_ENABLE) &&
- (val & VCPU_CFGSHDW_WOL_MAGPKT))
+ (val & VCPU_CFGSHDW_WOL_MAGPKT)) {
tp->tg3_flags |= TG3_FLAG_WOL_ENABLE;
+ device_set_wakeup_enable(&tp->pdev->dev, true);
+ }
goto done;
}
@@ -12461,8 +12463,10 @@ static void __devinit tg3_get_eeprom_hw_
tp->tg3_flags &= ~TG3_FLAG_WOL_CAP;
if ((tp->tg3_flags & TG3_FLAG_WOL_CAP) &&
- (nic_cfg & NIC_SRAM_DATA_CFG_WOL_ENABLE))
+ (nic_cfg & NIC_SRAM_DATA_CFG_WOL_ENABLE)) {
tp->tg3_flags |= TG3_FLAG_WOL_ENABLE;
+ device_set_wakeup_enable(&tp->pdev->dev, true);
+ }
if (cfg2 & (1 << 17))
tp->phy_flags |= TG3_PHYFLG_CAPACITIVE_COUPLING;
^ permalink raw reply
* RE: [NEXT PATCH 2/3] qlcnic: support rcv ring configuration through ethtool
From: Amit Salecha @ 2011-04-28 21:05 UTC (permalink / raw)
To: Ben Hutchings
Cc: David Miller, netdev, Ameen Rahman, Anirban Chakraborty,
Sucheta Chakraborty
In-Reply-To: <1303948962.2875.178.camel@bwh-desktop>
> From: Ben Hutchings [mailto:bhutchings@solarflare.com]
> Sent: Wednesday, April 27, 2011 5:03 PM
> To: Amit Salecha
> Cc: David Miller; netdev; Ameen Rahman; Anirban Chakraborty; Sucheta
> Chakraborty
> Subject: Re: [NEXT PATCH 2/3] qlcnic: support rcv ring configuration
> through ethtool
>
> > + if (channel->other_count || channel->combined_count)
> > + return -EOPNOTSUPP;
>
> Should be -EINVAL.
>
> > + if (channel->tx_count &&
> > + (channel->tx_count != QLCNIC_MIN_NUM_TX_DESC_RINGS)) {
> > + netdev_info(dev, "valid value for tx_count 0x%x\n",
> > + QLCNIC_MIN_NUM_TX_DESC_RINGS);
> > + return -EINVAL;
> > + }
> [...]
>
> If tx_count cannot be changed, why does qlcnic_get_channels() set
> tx_count and max_tx to different values?
>
Internally both are same values. But I will resubmit the patch to reduce this ambiguity.
> Also I don't think you should treat tx_count == 0 as a special case; it
> should be rejected as invalid.
>
Will fix this.
^ permalink raw reply
* Re: [PATCHv3 3/7] ethtool: Use the full 32 bit speed range in ethtool's set_settings
From: David Dillow @ 2011-04-28 21:14 UTC (permalink / raw)
To: David Decotigny; +Cc: David S. Miller, Ben Hutchings, linux-kernel, netdev
In-Reply-To: <1303954043-17440-4-git-send-email-decot@google.com>
On Wed, 2011-04-27 at 18:27 -0700, David Decotigny wrote:
> This makes sure the ethtool's set_settings() callback of network
> drivers don't ignore the 16 most significant bits when ethtool calls
> their set_settings().
>
> All drivers compiled with make allyesconfig on x86_64 have been
> updated.
>
> Tested: make allyesconfig compiles + e1000e and bnx2x work
> Signed-off-by: David Decotigny <decot@google.com>
For what it's worth, the typhoon changes are
Acked-by: David Dillow <dave@thedillows.org>
^ 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