* 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: [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
* 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: [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
* 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
* [PATCH v2] net: ftmac100: fix scheduling while atomic during PHY link status change
From: Adam Jaremko @ 2011-04-28 17:41 UTC (permalink / raw)
To: Po-Yu Chuang
Cc: Ratbert Po-Yu Chuang(莊博宇), netdev,
David Miller, Eric Dumazet
In-Reply-To: <BANLkTinB1FiHYX1KoO90UepmhQdXZs0eEg@mail.gmail.com>
I think I've sorted my mail client preferences and all should be well now.
Signed-off-by: Adam Jaremko <adam.jaremko@gmail.com>
Acked-by: Po-Yu Chuang <ratbert@faraday-tech.com>
---
drivers/net/ftmac100.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ftmac100.c b/drivers/net/ftmac100.c
index a316619..9bd7746 100644
--- a/drivers/net/ftmac100.c
+++ b/drivers/net/ftmac100.c
@@ -139,11 +139,11 @@ static int ftmac100_reset(struct ftmac100 *priv)
* that hardware reset completed (what the f*ck).
* We still need to wait for a while.
*/
- usleep_range(500, 1000);
+ udelay(500);
return 0;
}
- usleep_range(1000, 10000);
+ udelay(1000);
}
netdev_err(netdev, "software reset failed\n");
@@ -772,7 +772,7 @@ static int ftmac100_mdio_read(struct net_device *netdev, int phy_id, int reg)
if ((phycr & FTMAC100_PHYCR_MIIRD) == 0)
return phycr & FTMAC100_PHYCR_MIIRDATA;
- usleep_range(100, 1000);
+ udelay(100);
}
netdev_err(netdev, "mdio read timed out\n");
@@ -801,7 +801,7 @@ static void ftmac100_mdio_write(struct net_device *netdev, int phy_id, int reg,
if ((phycr & FTMAC100_PHYCR_MIIWR) == 0)
return;
- usleep_range(100, 1000);
+ udelay(100);
}
netdev_err(netdev, "mdio write timed out\n");
--
1.7.4.4
^ permalink raw reply related
* Re: [PATCH net-next] net: Allow ethtool to set interface in loopback mode.
From: Mahesh Bandewar @ 2011-04-28 17:20 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20110427.230807.48512460.davem@davemloft.net>
On Wed, Apr 27, 2011 at 11:08 PM, David Miller <davem@davemloft.net> wrote:
>
> From: Mahesh Bandewar <maheshb@google.com>
> Date: Wed, 20 Apr 2011 17:57:38 -0700
>
> > This patch enables ethtool to set the loopback mode on a given interface.
> > By configuring the interface in loopback mode in conjunction with a policy
> > route / rule, a userland application can stress the egress / ingress path
> > exposing the flows of the change in progress and potentially help developer(s)
> > understand the impact of those changes without even sending a packet out
> > on the network.
> >
> > Following set of commands illustrates one such example -
> > a) ip -4 addr add 192.168.1.1/24 dev eth1
> > b) ip -4 rule add from all iif eth1 lookup 250
> > c) ip -4 route add local 0/0 dev lo proto kernel scope host table 250
> > d) arp -Ds 192.168.1.100 eth1
> > e) arp -Ds 192.168.1.200 eth1
> > f) sysctl -w net.ipv4.ip_nonlocal_bind=1
> > g) sysctl -w net.ipv4.conf.all.accept_local=1
> > # Assuming that the machine has 8 cores
> > h) taskset 000f netserver -L 192.168.1.200
> > i) taskset 00f0 netperf -t TCP_CRR -L 192.168.1.100 -H 192.168.1.200 -l 30
> >
> > Signed-off-by: Mahesh Bandewar <maheshb@google.com>
>
> It's impossible to evaluate this patch without you also showing us some
> users.
>
My apologies. I'll post one such case/patch immediately.
--mahesh..
> I'm not applying this.
^ permalink raw reply
* RE
From: Sgt. Joey Jones. @ 2011-04-28 17:59 UTC (permalink / raw)
Hello Friend,
I hope my e-mail met you well. I need your assistance. My name Is Sgt.Joey Jones,
I am an American soldier serving in the 1st Armored Division in Iraq for the United States,
we have $25,000,000.00 USD. that is in our Possession and we are ready to move it out of
the country.
The money, which is now in the custody of Security Company, is part of the Money we
seized from late Saddam Hussein but we were not declared. Right now I am In the Baghdad
trying to sort out things with the Security Company to ensure a smooth and Unhindered transfer
of the money to you,therefore be assured that the transfer is safe and risk free.
My colleague and I need a good partner someone, we can trust to actualize this Venture, but
we are moving it through diplomatic means to your house directly Or a safe and secured location
of your choice using a shipping company, but Can we trust you? Once the funds get to you, you
are to take your 40% out and keep our own 60%, if you are interested I will furnish you with
more details. Awaiting your response, Contact via this E-mail: sgtjjoey11gmail.com
Yours Buddy And Partner,
Sgt. Joey Jones.
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: dont hold rtnl mutex during netlink dump callbacks
From: Eric Dumazet @ 2011-04-28 15:53 UTC (permalink / raw)
To: Stephen Hemminger
Cc: David Miller, Patrick McHardy, netdev, Remi Denis-Courmont
In-Reply-To: <20110428084337.6b54603e@nehalam>
Le jeudi 28 avril 2011 à 08:43 -0700, Stephen Hemminger a écrit :
> On Thu, 28 Apr 2011 10:56:07 +0200
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> > Four years ago, Patrick made a change to hold rtnl mutex during netlink
> > dump callbacks.
> >
> > I believe it was a wrong move. This slows down concurrent dumps, making
> > good old /proc/net/ files faster than rtnetlink in some situations.
> >
> > This occurred to me because one "ip link show dev ..." was _very_ slow
> > on a workload adding/removing network devices in background.
> >
> > All dump callbacks are able to use RCU locking now, so this patch does
> > roughly a revert of commits :
> >
> > 1c2d670f366 : [RTNETLINK]: Hold rtnl_mutex during netlink dump callbacks
> > 6313c1e0992 : [RTNETLINK]: Remove unnecessary locking in dump callbacks
> >
> > This let writers fight for rtnl mutex and readers going full speed.
> >
> > It also takes care of phonet : phonet_route_get() is now called from rcu
> > read section. I renamed it to phonet_route_get_rcu()
> >
> > Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> > Cc: Patrick McHardy <kaber@trash.net>
> > Cc: Remi Denis-Courmont <remi.denis-courmont@nokia.com>
>
> Acked-by: Stephen Hemminger <shemminger@vyatta.com>
>
Thanks for reviewing Stephen
^ permalink raw reply
* Re: [PATCH net-next-2.6] net: dont hold rtnl mutex during netlink dump callbacks
From: Stephen Hemminger @ 2011-04-28 15:43 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Patrick McHardy, netdev, Remi Denis-Courmont
In-Reply-To: <1303980967.3360.60.camel@edumazet-laptop>
On Thu, 28 Apr 2011 10:56:07 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Four years ago, Patrick made a change to hold rtnl mutex during netlink
> dump callbacks.
>
> I believe it was a wrong move. This slows down concurrent dumps, making
> good old /proc/net/ files faster than rtnetlink in some situations.
>
> This occurred to me because one "ip link show dev ..." was _very_ slow
> on a workload adding/removing network devices in background.
>
> All dump callbacks are able to use RCU locking now, so this patch does
> roughly a revert of commits :
>
> 1c2d670f366 : [RTNETLINK]: Hold rtnl_mutex during netlink dump callbacks
> 6313c1e0992 : [RTNETLINK]: Remove unnecessary locking in dump callbacks
>
> This let writers fight for rtnl mutex and readers going full speed.
>
> It also takes care of phonet : phonet_route_get() is now called from rcu
> read section. I renamed it to phonet_route_get_rcu()
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Patrick McHardy <kaber@trash.net>
> Cc: Remi Denis-Courmont <remi.denis-courmont@nokia.com>
Acked-by: Stephen Hemminger <shemminger@vyatta.com>
--
^ permalink raw reply
* [PATCHv8] usbnet: Resubmit interrupt URB if device is open
From: Paul Stewart @ 2011-04-28 15:43 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: oliver-GvhC2dPhHPQdnm+yROfE0A,
stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, bhutchings-s/n/eUQHGBpZroRs9YW3xA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20110427.230011.59678907.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
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-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---
drivers/net/usb/usbnet.c | 8 ++++++++
include/linux/usb/usbnet.h | 1 +
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 069c1cf..009bba3 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -736,6 +736,7 @@ int usbnet_open (struct net_device *net)
}
}
+ set_bit(EVENT_DEV_OPEN, &dev->flags);
netif_start_queue (net);
netif_info(dev, ifup, dev->net,
"open: enable queueing (rx %d, tx %d) mtu %d %s framing\n",
@@ -1259,6 +1260,9 @@ void usbnet_disconnect (struct usb_interface *intf)
if (dev->driver_info->unbind)
dev->driver_info->unbind (dev, intf);
+ usb_kill_urb(dev->interrupt);
+ usb_free_urb(dev->interrupt);
+
free_netdev(net);
usb_put_dev (xdev);
}
@@ -1498,6 +1502,10 @@ int usbnet_resume (struct usb_interface *intf)
int retval;
if (!--dev->suspend_count) {
+ /* resume interrupt URBs */
+ if (dev->interrupt && test_bit(EVENT_DEV_OPEN, &dev->flags))
+ usb_submit_urb(dev->interrupt, GFP_NOIO);
+
spin_lock_irq(&dev->txq.lock);
while ((res = usb_get_from_anchor(&dev->deferred))) {
diff --git a/include/linux/usb/usbnet.h b/include/linux/usb/usbnet.h
index 0e18550..605b0aa 100644
--- a/include/linux/usb/usbnet.h
+++ b/include/linux/usb/usbnet.h
@@ -68,6 +68,7 @@ struct usbnet {
# define EVENT_RX_PAUSED 5
# define EVENT_DEV_WAKING 6
# define EVENT_DEV_ASLEEP 7
+# define EVENT_DEV_OPEN 8
};
static inline struct usb_driver *driver_of(struct usb_interface *intf)
--
1.7.3.1
--
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 related
* Re: [PATCH net-next-2.6] net: dont hold rtnl mutex during netlink dump callbacks
From: Stephen Hemminger @ 2011-04-28 15:40 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Patrick McHardy, netdev, Remi Denis-Courmont
In-Reply-To: <1303980967.3360.60.camel@edumazet-laptop>
On Thu, 28 Apr 2011 10:56:07 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> @@ -1980,7 +1978,7 @@ static int __net_init rtnetlink_net_init(struct net *net)
> {
> struct sock *sk;
> sk = netlink_kernel_create(net, NETLINK_ROUTE, RTNLGRP_MAX,
> - rtnetlink_rcv, &rtnl_mutex, THIS_MODULE);
> + rtnetlink_rcv, NULL, THIS_MODULE);
Looks like only genetlink is still using the mutex argument.
^ permalink raw reply
* Re: [PATCHv4 2/7] ethtool: Call ethtool's get/set_settings callbacks with cleaned data
From: David Decotigny @ 2011-04-28 15:16 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: David S. Miller, Ben Hutchings, mirq-linux, Alexander Duyck,
Eilon Greenstein, Grant Grundler, e1000-devel, linux-kernel,
netdev
In-Reply-To: <20110428073417.GA2220@redhat.com>
Hi,
Stanislaw, as Ben mentions, it's calling phy_ethtool_sset() which is
certainly meant to be an ETHTOOL_SSET op (from its name and comments)
even though its current implementation doesn't actually care for the
value of the cmd field.
Regards,
--
David Decotigny
On Thu, Apr 28, 2011 at 12:34 AM, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> On Wed, Apr 27, 2011 at 09:32:38PM -0700, David Decotigny wrote:
>> --- a/drivers/net/stmmac/stmmac_ethtool.c
>> +++ b/drivers/net/stmmac/stmmac_ethtool.c
>> @@ -237,13 +237,12 @@ stmmac_set_pauseparam(struct net_device *netdev,
>>
>> if (phy->autoneg) {
>> if (netif_running(netdev)) {
>> - struct ethtool_cmd cmd;
>> + struct ethtool_cmd cmd = { .cmd = ETHTOOL_SSET };
>> /* auto-negotiation automatically restarted */
>> - cmd.cmd = ETHTOOL_NWAY_RST;
>
> Why did you change ETHTOOL_NWAY_RST to ETHTOOL_SSET ?
>
>
^ permalink raw reply
* [PATCH] s390, net: convert into new cpumask api
From: KOSAKI Motohiro @ 2011-04-28 14:59 UTC (permalink / raw)
To: LKML, Martin Schwidefsky, Heiko Carstens, Ursula Braun,
"David S. Miller
Cc: kosaki.motohiro
Adapt new api.
Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Ursula Braun <ursula.braun@de.ibm.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: linux390@de.ibm.com
Cc: linux-s390@vger.kernel.org
Cc: netdev@vger.kernel.org
---
net/iucv/iucv.c | 70 +++++++++++++++++++++++++++---------------------------
1 files changed, 35 insertions(+), 35 deletions(-)
diff --git a/net/iucv/iucv.c b/net/iucv/iucv.c
index 8f156bd..79f2caf 100644
--- a/net/iucv/iucv.c
+++ b/net/iucv/iucv.c
@@ -128,8 +128,8 @@ struct iucv_irq_list {
};
static struct iucv_irq_data *iucv_irq_data[NR_CPUS];
-static cpumask_t iucv_buffer_cpumask = CPU_MASK_NONE;
-static cpumask_t iucv_irq_cpumask = CPU_MASK_NONE;
+static cpumask_t iucv_buffer_cpumask = { CPU_BITS_NONE };
+static cpumask_t iucv_irq_cpumask = { CPU_BITS_NONE };
/*
* Queue of interrupt buffers lock for delivery via the tasklet
@@ -406,7 +406,7 @@ static void iucv_allow_cpu(void *data)
parm->set_mask.ipmask = 0xf8;
iucv_call_b2f0(IUCV_SETCONTROLMASK, parm);
/* Set indication that iucv interrupts are allowed for this cpu. */
- cpu_set(cpu, iucv_irq_cpumask);
+ cpumask_set_cpu(cpu, &iucv_irq_cpumask);
}
/**
@@ -426,7 +426,7 @@ static void iucv_block_cpu(void *data)
iucv_call_b2f0(IUCV_SETMASK, parm);
/* Clear indication that iucv interrupts are allowed for this cpu. */
- cpu_clear(cpu, iucv_irq_cpumask);
+ cpumask_clear_cpu(cpu, &iucv_irq_cpumask);
}
/**
@@ -451,7 +451,7 @@ static void iucv_block_cpu_almost(void *data)
iucv_call_b2f0(IUCV_SETCONTROLMASK, parm);
/* Clear indication that iucv interrupts are allowed for this cpu. */
- cpu_clear(cpu, iucv_irq_cpumask);
+ cpumask_clear_cpu(cpu, &iucv_irq_cpumask);
}
/**
@@ -466,7 +466,7 @@ static void iucv_declare_cpu(void *data)
union iucv_param *parm;
int rc;
- if (cpu_isset(cpu, iucv_buffer_cpumask))
+ if (cpumask_test_cpu(cpu, &iucv_buffer_cpumask))
return;
/* Declare interrupt buffer. */
@@ -499,9 +499,9 @@ static void iucv_declare_cpu(void *data)
}
/* Set indication that an iucv buffer exists for this cpu. */
- cpu_set(cpu, iucv_buffer_cpumask);
+ cpumask_set_cpu(cpu, &iucv_buffer_cpumask);
- if (iucv_nonsmp_handler == 0 || cpus_empty(iucv_irq_cpumask))
+ if (iucv_nonsmp_handler == 0 || cpumask_empty(&iucv_irq_cpumask))
/* Enable iucv interrupts on this cpu. */
iucv_allow_cpu(NULL);
else
@@ -520,7 +520,7 @@ static void iucv_retrieve_cpu(void *data)
int cpu = smp_processor_id();
union iucv_param *parm;
- if (!cpu_isset(cpu, iucv_buffer_cpumask))
+ if (!cpumask_test_cpu(cpu, &iucv_buffer_cpumask))
return;
/* Block iucv interrupts. */
@@ -531,7 +531,7 @@ static void iucv_retrieve_cpu(void *data)
iucv_call_b2f0(IUCV_RETRIEVE_BUFFER, parm);
/* Clear indication that an iucv buffer exists for this cpu. */
- cpu_clear(cpu, iucv_buffer_cpumask);
+ cpumask_clear_cpu(cpu, &iucv_buffer_cpumask);
}
/**
@@ -546,8 +546,8 @@ static void iucv_setmask_mp(void)
get_online_cpus();
for_each_online_cpu(cpu)
/* Enable all cpus with a declared buffer. */
- if (cpu_isset(cpu, iucv_buffer_cpumask) &&
- !cpu_isset(cpu, iucv_irq_cpumask))
+ if (cpumask_test_cpu(cpu, &iucv_buffer_cpumask) &&
+ !cpumask_test_cpu(cpu, &iucv_irq_cpumask))
smp_call_function_single(cpu, iucv_allow_cpu,
NULL, 1);
put_online_cpus();
@@ -564,9 +564,9 @@ static void iucv_setmask_up(void)
int cpu;
/* Disable all cpu but the first in cpu_irq_cpumask. */
- cpumask = iucv_irq_cpumask;
- cpu_clear(first_cpu(iucv_irq_cpumask), cpumask);
- for_each_cpu_mask_nr(cpu, cpumask)
+ cpumask_copy(&cpumask, &iucv_irq_cpumask);
+ cpumask_clear_cpu(cpumask_first(&iucv_irq_cpumask), &cpumask);
+ for_each_cpu(cpu, &cpumask)
smp_call_function_single(cpu, iucv_block_cpu, NULL, 1);
}
@@ -593,7 +593,7 @@ static int iucv_enable(void)
rc = -EIO;
for_each_online_cpu(cpu)
smp_call_function_single(cpu, iucv_declare_cpu, NULL, 1);
- if (cpus_empty(iucv_buffer_cpumask))
+ if (cpumask_empty(&iucv_buffer_cpumask))
/* No cpu could declare an iucv buffer. */
goto out;
put_online_cpus();
@@ -675,14 +675,14 @@ static int __cpuinit iucv_cpu_notify(struct notifier_block *self,
case CPU_DOWN_PREPARE_FROZEN:
if (!iucv_path_table)
break;
- cpumask = iucv_buffer_cpumask;
- cpu_clear(cpu, cpumask);
- if (cpus_empty(cpumask))
+ cpumask_copy(&cpumask, &iucv_buffer_cpumask);
+ cpumask_clear_cpu(cpu, &cpumask);
+ if (cpumask_empty(&cpumask))
/* Can't offline last IUCV enabled cpu. */
return notifier_from_errno(-EINVAL);
smp_call_function_single(cpu, iucv_retrieve_cpu, NULL, 1);
- if (cpus_empty(iucv_irq_cpumask))
- smp_call_function_single(first_cpu(iucv_buffer_cpumask),
+ if (cpumask_empty(&iucv_irq_cpumask))
+ smp_call_function_single(cpumask_first(&iucv_buffer_cpumask),
iucv_allow_cpu, NULL, 1);
break;
}
@@ -866,7 +866,7 @@ int iucv_path_accept(struct iucv_path *path, struct iucv_handler *handler,
int rc;
local_bh_disable();
- if (cpus_empty(iucv_buffer_cpumask)) {
+ if (cpumask_empty(&iucv_buffer_cpumask)) {
rc = -EIO;
goto out;
}
@@ -915,7 +915,7 @@ int iucv_path_connect(struct iucv_path *path, struct iucv_handler *handler,
spin_lock_bh(&iucv_table_lock);
iucv_cleanup_queue();
- if (cpus_empty(iucv_buffer_cpumask)) {
+ if (cpumask_empty(&iucv_buffer_cpumask)) {
rc = -EIO;
goto out;
}
@@ -975,7 +975,7 @@ int iucv_path_quiesce(struct iucv_path *path, u8 userdata[16])
int rc;
local_bh_disable();
- if (cpus_empty(iucv_buffer_cpumask)) {
+ if (cpumask_empty(&iucv_buffer_cpumask)) {
rc = -EIO;
goto out;
}
@@ -1007,7 +1007,7 @@ int iucv_path_resume(struct iucv_path *path, u8 userdata[16])
int rc;
local_bh_disable();
- if (cpus_empty(iucv_buffer_cpumask)) {
+ if (cpumask_empty(&iucv_buffer_cpumask)) {
rc = -EIO;
goto out;
}
@@ -1036,7 +1036,7 @@ int iucv_path_sever(struct iucv_path *path, u8 userdata[16])
int rc;
preempt_disable();
- if (cpus_empty(iucv_buffer_cpumask)) {
+ if (cpumask_empty(&iucv_buffer_cpumask)) {
rc = -EIO;
goto out;
}
@@ -1070,7 +1070,7 @@ int iucv_message_purge(struct iucv_path *path, struct iucv_message *msg,
int rc;
local_bh_disable();
- if (cpus_empty(iucv_buffer_cpumask)) {
+ if (cpumask_empty(&iucv_buffer_cpumask)) {
rc = -EIO;
goto out;
}
@@ -1162,7 +1162,7 @@ int __iucv_message_receive(struct iucv_path *path, struct iucv_message *msg,
if (msg->flags & IUCV_IPRMDATA)
return iucv_message_receive_iprmdata(path, msg, flags,
buffer, size, residual);
- if (cpus_empty(iucv_buffer_cpumask)) {
+ if (cpumask_empty(&iucv_buffer_cpumask)) {
rc = -EIO;
goto out;
}
@@ -1235,7 +1235,7 @@ int iucv_message_reject(struct iucv_path *path, struct iucv_message *msg)
int rc;
local_bh_disable();
- if (cpus_empty(iucv_buffer_cpumask)) {
+ if (cpumask_empty(&iucv_buffer_cpumask)) {
rc = -EIO;
goto out;
}
@@ -1274,7 +1274,7 @@ int iucv_message_reply(struct iucv_path *path, struct iucv_message *msg,
int rc;
local_bh_disable();
- if (cpus_empty(iucv_buffer_cpumask)) {
+ if (cpumask_empty(&iucv_buffer_cpumask)) {
rc = -EIO;
goto out;
}
@@ -1324,7 +1324,7 @@ int __iucv_message_send(struct iucv_path *path, struct iucv_message *msg,
union iucv_param *parm;
int rc;
- if (cpus_empty(iucv_buffer_cpumask)) {
+ if (cpumask_empty(&iucv_buffer_cpumask)) {
rc = -EIO;
goto out;
}
@@ -1411,7 +1411,7 @@ int iucv_message_send2way(struct iucv_path *path, struct iucv_message *msg,
int rc;
local_bh_disable();
- if (cpus_empty(iucv_buffer_cpumask)) {
+ if (cpumask_empty(&iucv_buffer_cpumask)) {
rc = -EIO;
goto out;
}
@@ -1888,7 +1888,7 @@ static int iucv_pm_freeze(struct device *dev)
printk(KERN_WARNING "iucv_pm_freeze\n");
#endif
if (iucv_pm_state != IUCV_PM_FREEZING) {
- for_each_cpu_mask_nr(cpu, iucv_irq_cpumask)
+ for_each_cpu(cpu, &iucv_irq_cpumask)
smp_call_function_single(cpu, iucv_block_cpu_almost,
NULL, 1);
cancel_work_sync(&iucv_work);
@@ -1928,7 +1928,7 @@ static int iucv_pm_thaw(struct device *dev)
if (rc)
goto out;
}
- if (cpus_empty(iucv_irq_cpumask)) {
+ if (cpumask_empty(&iucv_irq_cpumask)) {
if (iucv_nonsmp_handler)
/* enable interrupts on one cpu */
iucv_allow_cpu(NULL);
@@ -1961,7 +1961,7 @@ static int iucv_pm_restore(struct device *dev)
pr_warning("Suspending Linux did not completely close all IUCV "
"connections\n");
iucv_pm_state = IUCV_PM_RESTORING;
- if (cpus_empty(iucv_irq_cpumask)) {
+ if (cpumask_empty(&iucv_irq_cpumask)) {
rc = iucv_query_maxconn();
rc = iucv_enable();
if (rc)
--
1.7.3.1
^ permalink raw reply related
* Re: [PATCH 00/13] Swap-over-NBD without deadlocking
From: Mel Gorman @ 2011-04-28 13:42 UTC (permalink / raw)
To: Pavel Machek
Cc: Linux-MM, Linux-Netdev, LKML, David Miller, Neil Brown,
Peter Zijlstra
In-Reply-To: <20110428133154.GA8572@ucw.cz>
On Thu, Apr 28, 2011 at 03:31:55PM +0200, Pavel Machek wrote:
> Hi!
>
>
> > For testing swap-over-NBD, a machine was booted with 2G of RAM with a
> > swapfile backed by NBD. 16*NUM_CPU processes were started that create
> > anonymous memory mappings and read them linearly in a loop. The total
> > size of the mappings were 4*PHYSICAL_MEMORY to use swap heavily under
> > memory pressure. Without the patches, the machine locks up within
> > minutes and runs to completion with them applied.
> >
> > Comments?
>
> Nice!
>
> It is easy to see why swapping needs these fixes, but... dirty memory
> writeout is used for memory clearing, too. Are same changes neccessary
> to make that safe?
>
Dirty page limiting covers the MAP_SHARED cases and are already
throttled approprately.
> (Perhaps raise 'max dirty %' for testing?)
Stress testing passed for dirty ratios of 40% at least. Maybe it would
cause issues when raised to nearly 100% but I don't think that is a
particularly interesting use case.
--
Mel Gorman
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH rfc 5/5] r8169: provide some firmware information via ethtool.
From: Borislav Petkov @ 2011-04-28 13:34 UTC (permalink / raw)
To: Francois Romieu
Cc: netdev@vger.kernel.org, Ciprian Docan, Fejes József,
Realtek linux nic maintainers, Ben Hutchings
In-Reply-To: <20110427203730.GH19708@electric-eye.fr.zoreil.com>
On Wed, Apr 27, 2011 at 04:37:30PM -0400, Francois Romieu wrote:
> There is no real firmware version yet but the manpage of ethtool
> is rather terse about the driver information.
>
> Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
> Cc: Ciprian Docan <docan@eden.rutgers.edu>
> Cc: Fejes József <fejes@joco.name>
> Cc: Borislav Petkov <borislav.petkov@amd.com>
> Cc: Realtek linux nic maintainers <nic_swsd@realtek.com>
> ---
> drivers/net/r8169.c | 45 +++++++++++++++++++++++++--------------------
> 1 files changed, 25 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
> index 2606a20..76e81ac 100644
> --- a/drivers/net/r8169.c
> +++ b/drivers/net/r8169.c
> @@ -1190,6 +1190,19 @@ static int rtl8169_set_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
> return 0;
> }
>
> +static const char *rtl_lookup_firmware_name(struct rtl8169_private *tp)
> +{
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(rtl_firmware_infos); i++) {
> + const struct rtl_firmware_info *info = rtl_firmware_infos + i;
> +
> + if (info->mac_version == tp->mac_version)
> + return info->fw_name;
> + }
> + return NULL;
> +}
> +
> static void rtl8169_get_drvinfo(struct net_device *dev,
> struct ethtool_drvinfo *info)
> {
> @@ -1198,6 +1211,8 @@ static void rtl8169_get_drvinfo(struct net_device *dev,
> strcpy(info->driver, MODULENAME);
> strcpy(info->version, RTL8169_VERSION);
> strcpy(info->bus_info, pci_name(tp->pci_dev));
> + strncpy(info->fw_version, IS_ERR_OR_NULL(tp->fw) ? "N/A" :
> + rtl_lookup_firmware_name(tp), sizeof(info->fw_version));
> }
>
> static int rtl8169_get_regs_len(struct net_device *dev)
> @@ -3502,33 +3517,23 @@ static void __devexit rtl8169_remove_one(struct pci_dev *pdev)
>
> static void rtl_request_firmware(struct rtl8169_private *tp)
> {
> - int i;
> -
> /* Return early if the firmware is already loaded / cached. */
> - if (!IS_ERR(tp->fw))
> - goto out;
> -
> - for (i = 0; i < ARRAY_SIZE(rtl_firmware_infos); i++) {
> - const struct rtl_firmware_info *info = rtl_firmware_infos + i;
> + if (IS_ERR(tp->fw)) {
> + const char *name;
>
> - if (info->mac_version == tp->mac_version) {
> - const char *name = info->fw_name;
> + name = rtl_lookup_firmware_name(tp);
> + if (name) {
Yep, looks good. Just a minor nitpick:
you could save yourself an indentation level by doing
if (!name)
continue;
so that the netif_warn() string below could stay unbroken for easier
grepping.
> int rc;
>
> rc = request_firmware(&tp->fw, name, &tp->pci_dev->dev);
> - if (rc < 0) {
> - netif_warn(tp, ifup, tp->dev, "unable to load "
> - "firmware patch %s (%d)\n", name, rc);
> - goto out_disable_request_firmware;
> - }
> - goto out;
> + if (rc >= 0)
> + return;
> +
> + netif_warn(tp, ifup, tp->dev, "unable to load "
> + "firmware patch %s (%d)\n", name, rc);
> }
> + tp->fw = NULL;
> }
> -
> -out_disable_request_firmware:
> - tp->fw = NULL;
> -out:
> - return;
> }
>
> static int rtl8169_open(struct net_device *dev)
> --
> 1.7.4.4
>
Thanks.
--
Regards/Gruss,
Boris.
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632
^ permalink raw reply
* Re: [PATCH 00/13] Swap-over-NBD without deadlocking
From: Pavel Machek @ 2011-04-28 13:31 UTC (permalink / raw)
To: Mel Gorman
Cc: Linux-MM, Linux-Netdev, LKML, David Miller, Neil Brown,
Peter Zijlstra
In-Reply-To: <1303803414-5937-1-git-send-email-mgorman@suse.de>
Hi!
> For testing swap-over-NBD, a machine was booted with 2G of RAM with a
> swapfile backed by NBD. 16*NUM_CPU processes were started that create
> anonymous memory mappings and read them linearly in a loop. The total
> size of the mappings were 4*PHYSICAL_MEMORY to use swap heavily under
> memory pressure. Without the patches, the machine locks up within
> minutes and runs to completion with them applied.
>
> Comments?
Nice!
It is easy to see why swapping needs these fixes, but... dirty memory
writeout is used for memory clearing, too. Are same changes neccessary
to make that safe?
(Perhaps raise 'max dirty %' for testing?)
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: 答复: Is 802.3ad mode in bonding useful ?
From: Neil Horman @ 2011-04-28 13:23 UTC (permalink / raw)
To: Xiong Huang; +Cc: WeipingPan, netdev@vger.kernel.org
In-Reply-To: <0FBC7C9C2640634A8B837C2EFFCFF32F0184732D72@SHEXMB-01.global.atheros.com>
On Thu, Apr 28, 2011 at 08:31:33PM +0800, Xiong Huang wrote:
> Is there any plan to support cisco FEC/GEC protocol in bonding ?
>
Not explicitly, no, since roundrobin/xor modes should be compatible already,
and etherchannel can interoperate with 802.3ad bonds if the switches
etherchannel is configured to be in lacp mode:
Neil
> -Xiong
> ________________________________________
> 发件人: netdev-owner@vger.kernel.org [netdev-owner@vger.kernel.org] 代表 Neil Horman [nhorman@tuxdriver.com]
> 发送时间: 2011年4月28日 5:21
> 收件人: WeipingPan
> 抄送: netdev@vger.kernel.org
> 主题: Re: Is 802.3ad mode in bonding useful ?
>
> On Thu, Apr 28, 2011 at 03:33:50PM +0800, WeipingPan wrote:
> > Hi, all,
> >
> > 802.3ad mode in bonding implements 802.3ad standard.
> >
> > I am just wondering 802.3ad mode is useful,
> > since bonding has many modes like balance-rr, active-backup, etc.
> >
> Yes, of course its usefull. For switches which support 802.3ad, this mode
> allows for both peers to understand that the links in the bond are acting as an
> aggregate, which makes it easier to prevent things like inadvertently looped
> back frames, for which the other modes have to have all sorts of hacks to
> prevent.
> Neil
>
> > thanks
> > Weiping Pan
> > --
> > To unsubscribe from this list: send the line "unsubscribe netdev" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/3] bql: Byte queue limits
From: Tom Herbert @ 2011-04-28 12:53 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: davem, netdev
In-Reply-To: <20110426091620.7c576a98@nehalam>
> Although this is implemented as a device attribute, from a layering
> point of view it feels like a queuing strategy. Having two competing
> ways to do something is not always a good idea. Why is this not a
> qdisc parameter or a new qdisc?
>
It's an interesting idea, but I'm not sure that this would fit into
the qdisc model without some major re-architecture. The qdiscs manage
host side above the device, BQL is another layer that would need to be
added beyond the that which is logically below the leaf qdiscs.
Tom
> --
>
^ permalink raw reply
* Re: [PATCHv4 2/7] ethtool: Call ethtool's get/set_settings callbacks with cleaned data
From: Ben Hutchings @ 2011-04-28 12:46 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: David Decotigny, David S. Miller, mirq-linux, Alexander Duyck,
Eilon Greenstein, Grant Grundler, e1000-devel, linux-kernel,
netdev
In-Reply-To: <20110428073417.GA2220@redhat.com>
On Thu, 2011-04-28 at 09:34 +0200, Stanislaw Gruszka wrote:
> On Wed, Apr 27, 2011 at 09:32:38PM -0700, David Decotigny wrote:
> > --- a/drivers/net/stmmac/stmmac_ethtool.c
> > +++ b/drivers/net/stmmac/stmmac_ethtool.c
> > @@ -237,13 +237,12 @@ stmmac_set_pauseparam(struct net_device *netdev,
> >
> > if (phy->autoneg) {
> > if (netif_running(netdev)) {
> > - struct ethtool_cmd cmd;
> > + struct ethtool_cmd cmd = { .cmd = ETHTOOL_SSET };
> > /* auto-negotiation automatically restarted */
> > - cmd.cmd = ETHTOOL_NWAY_RST;
>
> Why did you change ETHTOOL_NWAY_RST to ETHTOOL_SSET ?
Because the function it's calling is an implementation of ETHTOOL_SSET,
not ETHTOOL_NWAY_RST.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH 2.6.38.4] mii: add support of pause frames in mii_get_an
From: Ben Hutchings @ 2011-04-28 12:45 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: artpol, linux-kernel, davem, netdev
In-Reply-To: <20110427214902.0826a4d1@nehalam>
On Wed, 2011-04-27 at 21:49 -0700, Stephen Hemminger wrote:
> On Thu, 28 Apr 2011 10:49:14 +0700
> artpol <artpol84@gmail.com> wrote:
>
> > Add support of pause frames advertise in mii_get_an. This provides all drivers
> > that use mii_ethtool_gset to represent their own and Link partner flow control
> > abilities in ethtool.
> >
> > Signed-off-by: Artem Polyakov <artpol84@gmail.com>
> >
> > ---
> >
> > --- linux-2.6.38.4/drivers/net/mii.c.orig 2011-04-28 08:46:13.000000000 +0700
> > +++ linux-2.6.38.4/drivers/net/mii.c 2011-04-25 23:04:20.694981968 +0700
> > @@ -49,6 +49,10 @@ static u32 mii_get_an(struct mii_if_info
> > result |= ADVERTISED_100baseT_Half;
> > if (advert & ADVERTISE_100FULL)
> > result |= ADVERTISED_100baseT_Full;
> > + if (advert & ADVERTISE_PAUSE_CAP)
> > + result |= ADVERTISED_Pause;
> > + if (advert & ADVERTISE_PAUSE_ASYM)
> > + result |= ADVERTISED_Asym_Pause;
> >
> > return result;
> > }
>
> One common driver problem is that auto negotiation of pause
> is really a separate operation from negotiation of speed.
> It should be possible to force no flow-control but still negotiate
> speed and vice-versa.
If you want to force flow control then turn off pause autoneg.
If you want to force speed then turn off advertising of other speeds.
> The ethtool api breaks this into two operations
> but many drivers munge them together.
There is some interaction between set_pauseparam and set_settings if
pause autoneg is enabled, which is why we have the
mii_advertise_flowctrl() function.
Anyway, this patch covers reporting only.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: Is 802.3ad mode in bonding useful ?
From: Neil Horman @ 2011-04-28 12:21 UTC (permalink / raw)
To: WeipingPan; +Cc: netdev
In-Reply-To: <4DB9185E.4050103@gmail.com>
On Thu, Apr 28, 2011 at 03:33:50PM +0800, WeipingPan wrote:
> Hi, all,
>
> 802.3ad mode in bonding implements 802.3ad standard.
>
> I am just wondering 802.3ad mode is useful,
> since bonding has many modes like balance-rr, active-backup, etc.
>
Yes, of course its usefull. For switches which support 802.3ad, this mode
allows for both peers to understand that the links in the bond are acting as an
aggregate, which makes it easier to prevent things like inadvertently looped
back frames, for which the other modes have to have all sorts of hacks to
prevent.
Neil
> thanks
> Weiping Pan
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH 08/13] netvm: Allow skb allocation to use PFMEMALLOC reserves
From: Mel Gorman @ 2011-04-28 11:18 UTC (permalink / raw)
To: NeilBrown; +Cc: Linux-MM, Linux-Netdev, LKML, David Miller, Peter Zijlstra
In-Reply-To: <20110428204755.2e07147e@notabene.brown>
On Thu, Apr 28, 2011 at 08:47:55PM +1000, NeilBrown wrote:
> On Thu, 28 Apr 2011 11:05:06 +0100 Mel Gorman <mgorman@suse.de> wrote:
>
> > On Thu, Apr 28, 2011 at 04:19:33PM +1000, NeilBrown wrote:
> > > On Wed, 27 Apr 2011 17:08:06 +0100 Mel Gorman <mgorman@suse.de> wrote:
> > >
> > >
> > > > @@ -1578,7 +1589,7 @@ static inline struct sk_buff *netdev_alloc_skb_ip_align(struct net_device *dev,
> > > > */
> > > > static inline struct page *__netdev_alloc_page(struct net_device *dev, gfp_t gfp_mask)
> > > > {
> > > > - return alloc_pages_node(NUMA_NO_NODE, gfp_mask, 0);
> > > > + return alloc_pages_node(NUMA_NO_NODE, gfp_mask | __GFP_MEMALLOC, 0);
> > > > }
> > > >
> > >
> > > I'm puzzling a bit over this change.
> > > __netdev_alloc_page appears to be used to get pages to put in ring buffer
> > > for a network card to DMA received packets into. So it is OK to use
> > > __GFP_MEMALLOC for these allocations providing we mark the resulting skb as
> > > 'pfmemalloc' if a reserved page was used.
> > >
> > > However I don't see where that marking is done.
> > > I think it should be in skb_fill_page_desc, something like:
> > >
> > > if (page->pfmemalloc)
> > > skb->pfmemalloc = true;
> > >
> > > Is this covered somewhere else that I am missing?
> > >
> >
> > You're not missing anything.
> >
> > >From the context of __netdev_alloc_page, we do not know if the skb
> > is suitable for marking pfmemalloc or not (we don't have SKB_ALLOC_RX
> > flag for example that __alloc_skb has). The reserves are potentially
> > being dipped into for an unsuitable packet but it gets dropped in
> > __netif_receive_skb() and the memory is returned. If we mark the skb
> > pfmemalloc as a result of __netdev_alloc_page using a reserve page, the
> > packets would not get dropped as expected.
> >
>
> The only code in __netif_receive_skb that seems to drop packets is
>
> + if (skb_pfmemalloc(skb) && !skb_pfmemalloc_protocol(skb))
> + goto drop;
> +
>
> which requires that the skb have pfmemalloc set before it will be dropped.
>
Yes, I only wanted to drop the packet if we were under pressure
when skb was allocated. If we hit pressure between when skb was
allocated and when __netdev_alloc_page is called, then the PFMEMALLOC
reserves may be used for packet receive unnecessarily but the next skb
allocation that grows slab will have the flag set appropriately. There
is a window during which we use reserves where we did not have to
but it's limited. Again, the throttling if pfmemalloc reserves gets too
depleted comes into play.
> Actually ... I'm expecting to find code that says:
> if (skb_pfmalloc(skb) && !sock_flag(sk, SOCK_MEMALLOC))
> drop_packet();
>
> but I cannot find it. Where is the code that discard pfmalloc packets for
> non-memalloc sockets?
>
> I can see similar code in sk_filter but that doesn't drop the packet, it just
> avoids filtering it.
>
hmm, if sk_filter is returning -ENOMEM then things like
sock_queue_rcv_skb() return error and the skb does not get queued and I
expected it to get dropped. What did I miss?
--
Mel Gorman
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: Maximum no of bytes Ethernet can transfer at a time ??
From: Neil Horman @ 2011-04-28 11:06 UTC (permalink / raw)
To: Ajit; +Cc: netdev
In-Reply-To: <loom.20110428T074300-379@post.gmane.org>
On Thu, Apr 28, 2011 at 05:49:23AM +0000, Ajit wrote:
> Neil Horman <nhorman <at> tuxdriver.com> writes:
>
>
> hii Neil,
>
> I am not using the transport layer neither the Network layer. I have written a
> small protocol which work of a LAN without a router. So ideally there is no need
> of the network layer (I am using physical address for the transfer).
>
You may not be using the trasport layer, but you are still using IP, if you're
using SOCK_RAW sockets as you indicated.
> I have defined a filed called as "offset" and another one called as "id".
> Whenever you send a file, it is divided into various frames depending upon the
> size of the file and send with the same "id" and an offset incremented by 1.
>
> As you said the firewall issues. I don't think that is the problem because I am
> sending the file to myself, but , on eth0 rather than lo, because send on lo
> wont give the expected results.
>
Why not?
> If you still want some explanation then please ask me.
>
Can you just post a link to the code?
Neil
> Thank you.
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH 08/13] netvm: Allow skb allocation to use PFMEMALLOC reserves
From: NeilBrown @ 2011-04-28 10:47 UTC (permalink / raw)
To: Mel Gorman; +Cc: Linux-MM, Linux-Netdev, LKML, David Miller, Peter Zijlstra
In-Reply-To: <20110428100035.GO4658@suse.de>
On Thu, 28 Apr 2011 11:05:06 +0100 Mel Gorman <mgorman@suse.de> wrote:
> On Thu, Apr 28, 2011 at 04:19:33PM +1000, NeilBrown wrote:
> > On Wed, 27 Apr 2011 17:08:06 +0100 Mel Gorman <mgorman@suse.de> wrote:
> >
> >
> > > @@ -1578,7 +1589,7 @@ static inline struct sk_buff *netdev_alloc_skb_ip_align(struct net_device *dev,
> > > */
> > > static inline struct page *__netdev_alloc_page(struct net_device *dev, gfp_t gfp_mask)
> > > {
> > > - return alloc_pages_node(NUMA_NO_NODE, gfp_mask, 0);
> > > + return alloc_pages_node(NUMA_NO_NODE, gfp_mask | __GFP_MEMALLOC, 0);
> > > }
> > >
> >
> > I'm puzzling a bit over this change.
> > __netdev_alloc_page appears to be used to get pages to put in ring buffer
> > for a network card to DMA received packets into. So it is OK to use
> > __GFP_MEMALLOC for these allocations providing we mark the resulting skb as
> > 'pfmemalloc' if a reserved page was used.
> >
> > However I don't see where that marking is done.
> > I think it should be in skb_fill_page_desc, something like:
> >
> > if (page->pfmemalloc)
> > skb->pfmemalloc = true;
> >
> > Is this covered somewhere else that I am missing?
> >
>
> You're not missing anything.
>
> >From the context of __netdev_alloc_page, we do not know if the skb
> is suitable for marking pfmemalloc or not (we don't have SKB_ALLOC_RX
> flag for example that __alloc_skb has). The reserves are potentially
> being dipped into for an unsuitable packet but it gets dropped in
> __netif_receive_skb() and the memory is returned. If we mark the skb
> pfmemalloc as a result of __netdev_alloc_page using a reserve page, the
> packets would not get dropped as expected.
>
The only code in __netif_receive_skb that seems to drop packets is
+ if (skb_pfmemalloc(skb) && !skb_pfmemalloc_protocol(skb))
+ goto drop;
+
which requires that the skb have pfmemalloc set before it will be dropped.
Actually ... I'm expecting to find code that says:
if (skb_pfmalloc(skb) && !sock_flag(sk, SOCK_MEMALLOC))
drop_packet();
but I cannot find it. Where is the code that discard pfmalloc packets for
non-memalloc sockets?
I can see similar code in sk_filter but that doesn't drop the packet, it just
avoids filtering it.
NeilBrown
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ 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