* Re: [PATCH 08/16] virtio_net: drop config_enable
From: Michael S. Tsirkin @ 2014-10-07 6:49 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-kernel, virtualization
In-Reply-To: <20141006.150238.2180269239953265506.davem@davemloft.net>
On Mon, Oct 06, 2014 at 03:02:38PM -0400, David Miller wrote:
> From: "Michael S. Tsirkin" <mst@redhat.com>
> Date: Sun, 5 Oct 2014 19:07:13 +0300
>
> > Now that virtio core ensures config changes don't arrive during probing,
> > drop config_enable flag in virtio net.
> > On removal, flush is now sufficient to guarantee that no change work is
> > queued.
> >
> > This help simplify the driver, and will allow setting DRIVER_OK earlier
> > without losing config change notifications.
> >
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>
> It's hard for people on the networking side to review these changes
> since you haven't CC:'d them on any of the postings necessary to
> understand the context of the net/ and drivers/net/ changes.
>
> Please at a minimum CC: everyone on your header [PATCH 0/N] posting
> so we know at least at a high level what is going on, and why.
>
> Thanks.
It's a bit tricky for large patchsets - if I add everyone to 0/N
then vger isn't happy with Cc list that is too large.
What is your advice here? Cc just mailing lists on 0/N?
FWIW this patchset is inteded for the virtio tree.
--
MST
^ permalink raw reply
* Re: [PATCH] net: bcmgenet: fix increase rx_read_ptr
From: Jaedon Shin @ 2014-10-07 6:40 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev
In-Reply-To: <5432C73E.90805@gmail.com>
This patch fixes the previous commit b629be5c8399d7c423b92135eb43a86c924d1cbc ("net: bcmgenet: check harder for out of memory conditions").
The previous commit has a problem that gets invalid dma_length_status by increased rx_read_ptr. And it should be increased after all goto refill.
> On Oct 7, 2014, at 1:45 AM, Florian Fainelli <f.fainelli@gmail.com> wrote:
>
> On 10/05/2014 08:05 PM, Jaedon Shin wrote:
>> The rx_read_ptr must increase after using it.
>
> Your commit message is too terse, you need to explain why you think the
> current code is bad, and how your patch is fixing it.
>
> One possible thing that I see is that we might be off by one in how we
> use the enet_cb versus how we read the HW packet descriptor.
>
>>
>> Signed-off-by: Jaedon Shin <jaedon.shin@gmail.com>
>> ---
>> drivers/net/ethernet/broadcom/genet/bcmgenet.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
>> index 5cc9cae..b47db5e 100644
>> --- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
>> +++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
>> @@ -1282,9 +1282,6 @@ static unsigned int bcmgenet_desc_rx(struct bcmgenet_priv *priv,
>>
>> rxpktprocessed++;
>>
>> - priv->rx_read_ptr++;
>> - priv->rx_read_ptr &= (priv->num_rx_bds - 1);
>> -
>> /* We do not have a backing SKB, so we do not have a
>> * corresponding DMA mapping for this incoming packet since
>> * bcmgenet_rx_refill always either has both skb and mapping or
>> @@ -1399,6 +1396,9 @@ refill:
>> err = bcmgenet_rx_refill(priv, cb);
>> if (err)
>> netif_err(priv, rx_err, dev, "Rx refill failed\n");
>> +
>> + priv->rx_read_ptr++;
>> + priv->rx_read_ptr &= (priv->num_rx_bds - 1);
>> }
>>
>> return rxpktprocessed;
>>
>
^ permalink raw reply
* RE: [PATCH v2 net-next] r8169:add support for RTL8168EP
From: Hau @ 2014-10-07 5:45 UTC (permalink / raw)
To: Francois Romieu
Cc: netdev@vger.kernel.org, nic_swsd, linux-kernel@vger.kernel.org
In-Reply-To: <20141006221250.GA10936@electric-eye.fr.zoreil.com>
> -----Original Message-----
> From: Francois Romieu [mailto:romieu@fr.zoreil.com]
> Sent: Tuesday, October 07, 2014 6:13 AM
> To: Hau
> Cc: netdev@vger.kernel.org; nic_swsd; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v2 net-next] r8169:add support for RTL8168EP
>
> Hau <hau@realtek.com> :
> [...]
> > Do you mean I should collect similar hardware parameters setting into
> > one function ? or I should set hardware parameters according to
> > hardware feature support version?
>
> static void r8168dp_ocp_write(...)
> [...]
>
> static void r8168ep_ocp_write(...)
> [...]
>
> static void ocp_write(...)
> {
> switch (...
> case ...
> r8168dp_ocp_write
>
> case ...
> r8168ep_ocp_write
> [...]
>
> static void rtl8168dp_driver_start(...)
> [...]
>
> static void rtl8168ep_driver_start(...)
> [...]
>
> etc.
>
> Nothing more. At some point the helpers themselves may turn into data
> struct members. Things don't need to be immediately right - if ever.
> However you really want to avoid unrelated changes in your patches:
> shuffling code and changing features at the same time hurts reviews, late
> regression hunts, backports, etc.
>
> --
> Ueimor
>
Thanks, I will do that on later patch.
^ permalink raw reply
* [PATCH net-next] r8152: use mutex for hw settings
From: Hayes Wang @ 2014-10-07 5:36 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, linux-usb, Hayes Wang
Use mutex to avoid that the serial hw settings would be interrupted
by other settings. Although there is no problem now, it makes the
driver more safe.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/usb/r8152.c | 69 +++++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 67 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 6532620..4f99c43 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -26,7 +26,7 @@
#include <linux/mdio.h>
/* Version Information */
-#define DRIVER_VERSION "v1.06.1 (2014/10/01)"
+#define DRIVER_VERSION "v1.07.0 (2014/10/07)"
#define DRIVER_AUTHOR "Realtek linux nic maintainers <nic_swsd@realtek.com>"
#define DRIVER_DESC "Realtek RTL8152/RTL8153 Based USB Ethernet Adapters"
#define MODULENAME "r8152"
@@ -566,6 +566,7 @@ struct r8152 {
spinlock_t rx_lock, tx_lock;
struct delayed_work schedule;
struct mii_if_info mii;
+ struct mutex control; /* use for hw setting */
struct rtl_ops {
void (*init)(struct r8152 *);
@@ -984,12 +985,16 @@ static int rtl8152_set_mac_address(struct net_device *netdev, void *p)
if (!is_valid_ether_addr(addr->sa_data))
return -EADDRNOTAVAIL;
+ mutex_lock(&tp->control);
+
memcpy(netdev->dev_addr, addr->sa_data, netdev->addr_len);
ocp_write_byte(tp, MCU_TYPE_PLA, PLA_CRWECR, CRWECR_CONFIG);
pla_ocp_write(tp, PLA_IDR, BYTE_EN_SIX_BYTES, 8, addr->sa_data);
ocp_write_byte(tp, MCU_TYPE_PLA, PLA_CRWECR, CRWECR_NORAML);
+ mutex_unlock(&tp->control);
+
return 0;
}
@@ -2139,6 +2144,8 @@ static int rtl8152_set_features(struct net_device *dev,
netdev_features_t changed = features ^ dev->features;
struct r8152 *tp = netdev_priv(dev);
+ mutex_lock(&tp->control);
+
if (changed & NETIF_F_HW_VLAN_CTAG_RX) {
if (features & NETIF_F_HW_VLAN_CTAG_RX)
rtl_rx_vlan_en(tp, true);
@@ -2146,6 +2153,8 @@ static int rtl8152_set_features(struct net_device *dev,
rtl_rx_vlan_en(tp, false);
}
+ mutex_unlock(&tp->control);
+
return 0;
}
@@ -2844,6 +2853,11 @@ static void rtl_work_func_t(struct work_struct *work)
if (test_bit(RTL8152_UNPLUG, &tp->flags))
goto out1;
+ if (!mutex_trylock(&tp->control)) {
+ schedule_delayed_work(&tp->schedule, 0);
+ goto out1;
+ }
+
if (test_bit(RTL8152_LINK_CHG, &tp->flags))
set_carrier(tp);
@@ -2859,6 +2873,8 @@ static void rtl_work_func_t(struct work_struct *work)
if (test_bit(PHY_RESET, &tp->flags))
rtl_phy_reset(tp);
+ mutex_unlock(&tp->control);
+
out1:
usb_autopm_put_interface(tp->intf);
}
@@ -2878,6 +2894,8 @@ static int rtl8152_open(struct net_device *netdev)
goto out;
}
+ mutex_lock(&tp->control);
+
/* The WORK_ENABLE may be set when autoresume occurs */
if (test_bit(WORK_ENABLE, &tp->flags)) {
clear_bit(WORK_ENABLE, &tp->flags);
@@ -2906,6 +2924,8 @@ static int rtl8152_open(struct net_device *netdev)
free_all_mem(tp);
}
+ mutex_unlock(&tp->control);
+
usb_autopm_put_interface(tp->intf);
out:
@@ -2926,6 +2946,8 @@ static int rtl8152_close(struct net_device *netdev)
if (res < 0) {
rtl_drop_queued_tx(tp);
} else {
+ mutex_lock(&tp->control);
+
/* The autosuspend may have been enabled and wouldn't
* be disable when autoresume occurs, because the
* netif_running() would be false.
@@ -2938,6 +2960,9 @@ static int rtl8152_close(struct net_device *netdev)
tasklet_disable(&tp->tl);
tp->rtl_ops.down(tp);
tasklet_enable(&tp->tl);
+
+ mutex_unlock(&tp->control);
+
usb_autopm_put_interface(tp->intf);
}
@@ -3162,6 +3187,8 @@ static int rtl8152_suspend(struct usb_interface *intf, pm_message_t message)
{
struct r8152 *tp = usb_get_intfdata(intf);
+ mutex_lock(&tp->control);
+
if (PMSG_IS_AUTO(message))
set_bit(SELECTIVE_SUSPEND, &tp->flags);
else
@@ -3181,6 +3208,8 @@ static int rtl8152_suspend(struct usb_interface *intf, pm_message_t message)
tasklet_enable(&tp->tl);
}
+ mutex_unlock(&tp->control);
+
return 0;
}
@@ -3188,6 +3217,8 @@ static int rtl8152_resume(struct usb_interface *intf)
{
struct r8152 *tp = usb_get_intfdata(intf);
+ mutex_lock(&tp->control);
+
if (!test_bit(SELECTIVE_SUSPEND, &tp->flags)) {
tp->rtl_ops.init(tp);
netif_device_attach(tp->netdev);
@@ -3213,6 +3244,8 @@ static int rtl8152_resume(struct usb_interface *intf)
usb_submit_urb(tp->intr_urb, GFP_KERNEL);
}
+ mutex_unlock(&tp->control);
+
return 0;
}
@@ -3223,9 +3256,13 @@ static void rtl8152_get_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
if (usb_autopm_get_interface(tp->intf) < 0)
return;
+ mutex_lock(&tp->control);
+
wol->supported = WAKE_ANY;
wol->wolopts = __rtl_get_wol(tp);
+ mutex_unlock(&tp->control);
+
usb_autopm_put_interface(tp->intf);
}
@@ -3238,9 +3275,13 @@ static int rtl8152_set_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
if (ret < 0)
goto out_set_wol;
+ mutex_lock(&tp->control);
+
__rtl_set_wol(tp, wol->wolopts);
tp->saved_wolopts = wol->wolopts & WAKE_ANY;
+ mutex_unlock(&tp->control);
+
usb_autopm_put_interface(tp->intf);
out_set_wol:
@@ -3275,11 +3316,18 @@ static
int rtl8152_get_settings(struct net_device *netdev, struct ethtool_cmd *cmd)
{
struct r8152 *tp = netdev_priv(netdev);
+ int ret;
if (!tp->mii.mdio_read)
return -EOPNOTSUPP;
- return mii_ethtool_gset(&tp->mii, cmd);
+ mutex_lock(&tp->control);
+
+ ret = mii_ethtool_gset(&tp->mii, cmd);
+
+ mutex_unlock(&tp->control);
+
+ return ret;
}
static int rtl8152_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
@@ -3291,8 +3339,12 @@ static int rtl8152_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
if (ret < 0)
goto out;
+ mutex_lock(&tp->control);
+
ret = rtl8152_set_speed(tp, cmd->autoneg, cmd->speed, cmd->duplex);
+ mutex_unlock(&tp->control);
+
usb_autopm_put_interface(tp->intf);
out:
@@ -3452,8 +3504,12 @@ rtl_ethtool_get_eee(struct net_device *net, struct ethtool_eee *edata)
if (ret < 0)
goto out;
+ mutex_lock(&tp->control);
+
ret = tp->rtl_ops.eee_get(tp, edata);
+ mutex_unlock(&tp->control);
+
usb_autopm_put_interface(tp->intf);
out:
@@ -3470,10 +3526,14 @@ rtl_ethtool_set_eee(struct net_device *net, struct ethtool_eee *edata)
if (ret < 0)
goto out;
+ mutex_lock(&tp->control);
+
ret = tp->rtl_ops.eee_set(tp, edata);
if (!ret)
ret = mii_nway_restart(&tp->mii);
+ mutex_unlock(&tp->control);
+
usb_autopm_put_interface(tp->intf);
out:
@@ -3515,7 +3575,9 @@ static int rtl8152_ioctl(struct net_device *netdev, struct ifreq *rq, int cmd)
break;
case SIOCGMIIREG:
+ mutex_lock(&tp->control);
data->val_out = r8152_mdio_read(tp, data->reg_num);
+ mutex_unlock(&tp->control);
break;
case SIOCSMIIREG:
@@ -3523,7 +3585,9 @@ static int rtl8152_ioctl(struct net_device *netdev, struct ifreq *rq, int cmd)
res = -EPERM;
break;
}
+ mutex_lock(&tp->control);
r8152_mdio_write(tp, data->reg_num, data->val_in);
+ mutex_unlock(&tp->control);
break;
default:
@@ -3716,6 +3780,7 @@ static int rtl8152_probe(struct usb_interface *intf,
goto out;
tasklet_init(&tp->tl, bottom_half, (unsigned long)tp);
+ mutex_init(&tp->control);
INIT_DELAYED_WORK(&tp->schedule, rtl_work_func_t);
netdev->netdev_ops = &rtl8152_netdev_ops;
--
1.9.3
^ permalink raw reply related
* Re: pull request: wireless-next 2014-10-03
From: David Miller @ 2014-10-07 4:47 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20141005.213853.488066614144870837.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Sun, 05 Oct 2014 21:38:53 -0400 (EDT)
> From: David Miller <davem@davemloft.net>
> Date: Sun, 05 Oct 2014 21:35:11 -0400 (EDT)
>
>> From: "John W. Linville" <linville@tuxdriver.com>
>> Date: Fri, 3 Oct 2014 14:01:52 -0400
>>
>>> Please pull tihs batch of updates intended for the 3.18 stream!
>>
>> Pulled, thanks for the stellar pull request text, as always.
>
> John, what's the deal with the following? Will it be resolved by the
> driver being removed from the staging tree?
>
> WARNING: drivers/staging/rtl8192ee/r8192ee: 'rtl_evm_dbm_jaguar' exported twice. Previous export was in drivers/net/wireless/rtlwifi/rtlwifi.ko
John, ping?
^ permalink raw reply
* Re: [net-next PATCH v1 1/3] net: sched: af_packet support for direct ring access
From: John Fastabend @ 2014-10-07 4:25 UTC (permalink / raw)
To: David Miller, john.fastabend
Cc: dborkman, fw, gerlitz.or, hannes, netdev, john.ronciak, amirv,
eric.dumazet, danny.zhou
In-Reply-To: <20141006.174243.1946917197540493301.davem@davemloft.net>
On 10/06/2014 02:42 PM, David Miller wrote:
> From: John Fastabend <john.fastabend@gmail.com>
> Date: Sun, 05 Oct 2014 17:06:31 -0700
>
>> This patch adds a net_device ops to split off a set of driver queues
>> from the driver and map the queues into user space via mmap. This
>> allows the queues to be directly manipulated from user space. For
>> raw packet interface this removes any overhead from the kernel network
>> stack.
>
> About the facility in general, I am generally in favor, as I expressed
> at the networking track in Chiacgo.
>
> But you missed the mark wrt. describing the descriptors.
>
> I do not want you to give device IDs.
>
> I want the code to be %100 agnostic to device or vendor IDs.
>
OK. I'll work on this and have a v2 after net-next opens again.
Thanks!
> Really "describe" the descriptor. Not just how large is it (32-bits,
> 64-bits, etc.), but also: 1) is it little or big endian 2) where is
> the length field 3) where is control bit "foo" located, etc.
>
> That's what I want to see in "struct tpacket_dev_info", rather than
> device IDs and "versions".
> --
> 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: [net-next PATCH v1 1/3] net: sched: af_packet support for direct ring access
From: Willem de Bruijn @ 2014-10-07 4:24 UTC (permalink / raw)
To: John Fastabend
Cc: Daniel Borkmann, Florian Westphal, gerlitz.or,
Hannes Frederic Sowa, Network Development, john.ronciak,
Amir Vadai, Eric Dumazet, danny.zhou
In-Reply-To: <20141006000629.32055.2295.stgit@nitbit.x32>
> Supporting some way to steer traffic to a queue
> is the _only_ hardware requirement to support the interface,
I would not impose his constraint. There may be legitimate use
cases for taking over all queues of a device. For instance, when
this is a secondary nic that does not carry any control traffic.
> Typically in an af_packet interface a packet_type handler is
> registered and used to filter traffic to the socket and do other
> things such as fan out traffic to multiple sockets. In this case the
> networking stack is being bypassed so this code is not run. So the
> hardware must push the correct traffic to the queues obtained from
> the ndo callback ndo_split_queue_pairs().
Why does the interface work at the level of queue_pairs instead of
individual queues?
> /* Get the layout of ring space offset, page_sz, cnt */
> getsockopt(fd, SOL_PACKET, PACKET_DEV_QPAIR_MAP_REGION_INFO,
> &info, &optlen);
>
> /* request some queues from the driver */
> setsockopt(fd, SOL_PACKET, PACKET_RXTX_QPAIRS_SPLIT,
> &qpairs_info, sizeof(qpairs_info));
>
> /* if we let the driver pick us queues learn which queues
> * we were given
> */
> getsockopt(fd, SOL_PACKET, PACKET_RXTX_QPAIRS_SPLIT,
> &qpairs_info, sizeof(qpairs_info));
If ethtool -U is used to steer traffic to a specific descriptor queue,
then the setsockopt can pass the exact id of that queue and there
is no need for a getsockopt follow-up.
> /* And mmap queue pairs to user space */
> mmap(NULL, info.tp_dev_bar_sz, PROT_READ | PROT_WRITE,
> MAP_SHARED, fd, 0);
How will packet data be mapped and how will userspace translate
from paddr to vaddr? Is the goal to maintain long lived mappings
and instruct drivers to allocate from this restricted range (to
avoid per-packet system calls and vma operations)?
For throughput-oriented workloads, the syscall overhead
involved in kicking the nic (on tx, or for increasing the ring
consumer index on rx) can be amortized. And the operation
can perhaps piggy-back on interrupts or other events
(as long as interrupts are not disabled for full userspace
polling). Latency would be harder to satisfy while maintaining
some kernel policy enforcement. An extreme solution
uses an asynchronously busy polling kernel worker thread
(at high cycle cost, so acceptable for few workloads).
When keeping the kernel in the loop, it is possible to do
some basic sanity checking and transparently translate between
vaddr and paddr, even when exposing the hardware descriptors
directly. Though at this point it may be just as cheap to expose
an idealized virtualized descriptor format and copy fields between
that and device descriptors.
One assumption underlying exposing the hardware descriptors
is that they are quire similar between devices. How true is this
in the context of formats that span multiple descriptors?
> + * int (*ndo_split_queue_pairs) (struct net_device *dev,
> + * unsigned int qpairs_start_from,
> + * unsigned int qpairs_num,
> + * struct sock *sk)
> + * Called to request a set of queues from the driver to be
> + * handed to the callee for management. After this returns the
> + * driver will not use the queues.
Are these queues also taken out of ethtool management, or is
this equivalent to taking removing them from the rss set with
ethtool -X?
^ permalink raw reply
* Re: [Patch net-next] net_sched: fix unused variables in __gnet_stats_copy_basic_cpu()
From: David Miller @ 2014-10-07 4:12 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, john.fastabend
In-Reply-To: <1412640093-11388-1-git-send-email-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Mon, 6 Oct 2014 17:01:33 -0700
> Probably not a big deal, but we'd better just use the
> one we get in retry loop.
>
> Fixes: commit 22e0f8b9322cb1a48b1357e8 ("net: sched: make bstats per cpu and estimator RCU safe")
> Reported-by: Joe Perches <joe@perches.com>
> Cc: John Fastabend <john.fastabend@gmail.com>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Applied.
^ permalink raw reply
* Re: [net-next] openvswitch: fix a compilation error when CONFIG_INET is not setW!
From: David Miller @ 2014-10-07 4:11 UTC (permalink / raw)
To: azhou; +Cc: netdev
In-Reply-To: <1412633714-25048-1-git-send-email-azhou@nicira.com>
From: Andy Zhou <azhou@nicira.com>
Date: Mon, 6 Oct 2014 15:15:14 -0700
> Fix a openvswitch compilation error when CONFIG_INET is not set:
>
> =====================================================
> In file included from include/net/geneve.h:4:0,
> from net/openvswitch/flow_netlink.c:45:
> include/net/udp_tunnel.h: In function 'udp_tunnel_handle_offloads':
> >> include/net/udp_tunnel.h:100:2: error: implicit declaration of function 'iptunnel_handle_offloads' [-Werror=implicit-function-declaration]
> >> return iptunnel_handle_offloads(skb, udp_csum, type);
> >> ^
> >> >> include/net/udp_tunnel.h:100:2: warning: return makes pointer from integer without a cast
> >> >> cc1: some warnings being treated as errors
>
> =====================================================
>
> Reported-by: kbuild test robot <fengguang.wu@intel.com>
> Signed-off-by: Andy Zhou <azhou@nicira.com>
Applied.
^ permalink raw reply
* Re: [net-next 2/2] openvswitch: fix a sparse warning
From: David Miller @ 2014-10-07 4:11 UTC (permalink / raw)
To: azhou; +Cc: netdev
In-Reply-To: <1412626971-30271-2-git-send-email-azhou@nicira.com>
From: Andy Zhou <azhou@nicira.com>
Date: Mon, 6 Oct 2014 13:22:51 -0700
> Fix a sparse warning introduced by commit:
> f5796684069e0c71c65bce6a6d4766114aec1396 (openvswitch: Add support for
> Geneve tunneling.) caught by kbuild test robot:
>
> reproduce:
> # apt-get install sparse
> # git checkout f5796684069e0c71c65bce6a6d4766114aec1396
> # make ARCH=x86_64 allmodconfig
> # make C=1 CF=-D__CHECK_ENDIAN__
> #
> #
> # sparse warnings: (new ones prefixed by >>)
> #
> # >> net/openvswitch/vport-geneve.c:109:15: sparse: incorrect type in assignment (different base types)
> # net/openvswitch/vport-geneve.c:109:15: expected restricted __be16 [usertype] sport
> # net/openvswitch/vport-geneve.c:109:15: got int
> # >> net/openvswitch/vport-geneve.c:110:56: sparse: incorrect type in argument 3 (different base types)
> # net/openvswitch/vport-geneve.c:110:56: expected unsigned short [unsigned] [usertype] value
> # net/openvswitch/vport-geneve.c:110:56: got restricted __be16 [usertype] sport
>
> Reported-by: kbuild test robot <fengguang.wu@intel.com>
> Signed-off-by: Andy Zhou <azhou@nicira.com>
Applied.
^ permalink raw reply
* Re: [net-next 1/2] net: fix a sparse warning
From: David Miller @ 2014-10-07 4:11 UTC (permalink / raw)
To: azhou; +Cc: netdev
In-Reply-To: <1412626971-30271-1-git-send-email-azhou@nicira.com>
From: Andy Zhou <azhou@nicira.com>
Date: Mon, 6 Oct 2014 13:22:50 -0700
> Fix a sparse warning introduced by Commit
> 0b5e8b8eeae40bae6ad7c7e91c97c3c0d0e57882 (net: Add Geneve tunneling
> protocol driver) caught by kbuild test robot:
>
> # apt-get install sparse
> # git checkout 0b5e8b8eeae40bae6ad7c7e91c97c3c0d0e57882
> # make ARCH=x86_64 allmodconfig
> # make C=1 CF=-D__CHECK_ENDIAN__
> #
> #
> # sparse warnings: (new ones prefixed by >>)
> #
> # >> net/ipv4/geneve.c:230:42: sparse: incorrect type in assignment (different base types)
> # net/ipv4/geneve.c:230:42: expected restricted __be32 [addressable] [assigned] [usertype] s_addr
> # net/ipv4/geneve.c:230:42: got unsigned long [unsigned] <noident>
> #
>
> Reported-by: kbuild test robot <fengguang.wu@intel.com>
> Signed-off-by: Andy Zhou <azhou@nicira.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 net-next] net: phy: adjust fixed_phy_register() return value
From: David Miller @ 2014-10-07 4:07 UTC (permalink / raw)
To: pgynther; +Cc: netdev, f.fainelli, thomas.petazzoni
In-Reply-To: <20141006183830.D4E82100BC1@puck.mtv.corp.google.com>
From: Petri Gynther <pgynther@google.com>
Date: Mon, 6 Oct 2014 11:38:30 -0700 (PDT)
> Adjust fixed_phy_register() to return struct phy_device *, so that
> it becomes easy to use fixed PHYs without device tree support:
>
> phydev = fixed_phy_register(PHY_POLL, &fixed_phy_status, NULL);
> fixed_phy_set_link_update(phydev, fixed_phy_link_update);
> phy_connect_direct(netdev, phydev, handler_fn, phy_interface);
>
> This change is a prerequisite for modifying bcmgenet driver to work
> without a device tree on Broadcom's MIPS-based 7xxx platforms.
>
> Signed-off-by: Petri Gynther <pgynther@google.com>
If the caller gets this 'phy' pointer and does something with it,
something seems amiss.
We don't hold an extra reference to the 'phy' object for the caller,
so another thread of control can unregister it and kill that last
reference and therefore free it up.
I think to be legitimate, you have to hold an extra reference on
'phy' for the caller. And now that means that code paths that
don't need to do anything with 'phy' now will need to release
that reference.
^ permalink raw reply
* Re: [PATCH net] bna: page allocation during interrupts to use a mempool.
From: Eric Dumazet @ 2014-10-07 4:04 UTC (permalink / raw)
To: Eric Wheeler; +Cc: Shahed Shaikh, Stephen Hemminger, netdev, Rasesh Mody
In-Reply-To: <alpine.DEB.2.00.1410061956410.7392@ware.dreamhost.com>
On Mon, 2014-10-06 at 20:05 -0700, Eric Wheeler wrote:
> The patch in question implements a simple mempool for the interrupt page
> allocs---which definitely fixes the problem even if a better solution
> might exist. I have no problem giving up a small amount of memory to
> guarantee page allocs in the interrupt handler.
You have no such guarantee.
Once page is consumed by some networking frame, this frame can be
sitting in some socket receive queue. page cant be reused by the driver.
If you receive (small) burst of 100 frames, your 32 mempool will be
depleted anyway.
Even if you use a mempool with 10000 elements, there is no guarantee, it
really depends on the number of sockets and their SO_RCVBUF limits.
If your NIC depends of having order-2 pages available for its operation,
then I am afraid it cannot possibly work.
Memory will be eventually fragmented and order-2 allocations fail.
Run your patch with 100 concurrent TCP flows, add some losses to force
usage of out or order queue, you'll get errors quite fast.
^ permalink raw reply
* Re: [PATCH v2 net-next 0/5] ipv6: cleanup after rt6_genid removal
From: David Miller @ 2014-10-07 4:03 UTC (permalink / raw)
To: hannes; +Cc: netdev, hideaki, kafai, cwang
In-Reply-To: <cover.1412618014.git.hannes@stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Mon, 6 Oct 2014 19:58:33 +0200
> Leftover patches after rt6_genid removal after 705f1c869d577c ("ipv6:
> remove rt6i_genid").
>
> Major two changes are:
> * keep fib6_sernum per namespace to reduce number of flushes in case
> system has high number of namespaces
> * make fn_sernum updates cheaper
>
> v2: Incorporated feedback from Cong Wang, thanks a lot!
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net] bna: allow transmit tagged frames
From: David Miller @ 2014-10-07 4:02 UTC (permalink / raw)
To: ivecera; +Cc: netdev, rasesh.mody
In-Reply-To: <1412614957-18549-1-git-send-email-ivecera@redhat.com>
From: Ivan Vecera <ivecera@redhat.com>
Date: Mon, 6 Oct 2014 19:02:37 +0200
> When Tx VLAN offloading is disabled frames with size ~ MTU are not
> transmitted as the driver does not account 4 bytes of VLAN header added
> by stack. It should use VLAN_ETH_HLEN instead of ETH_HLEN.
>
> The second problem is with newer BNA chips (BNA 1860). These chips filter
> out any VLAN tagged frames in Tx path. This is a problem when Tx VLAN
> offloading is disabled and frames are tagged by stack. Older chips like
> 1010/1020 are not affected as they probably don't do such filtering.
>
> Cc: Rasesh Mody <rasesh.mody@qlogic.com>
> Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] net: bcmgenet: fix Tx ring priority programming
From: David Miller @ 2014-10-07 3:59 UTC (permalink / raw)
To: pgynther; +Cc: netdev, f.fainelli
In-Reply-To: <20141007005001.61C1D100BC1@puck.mtv.corp.google.com>
From: Petri Gynther <pgynther@google.com>
Date: Mon, 6 Oct 2014 17:50:01 -0700 (PDT)
> @@ -1731,11 +1744,12 @@ static void bcmgenet_init_multiq(struct net_device *dev)
> reg |= ring_cfg;
> bcmgenet_tdma_writel(priv, reg, DMA_RING_CFG);
>
> - /* Use configured rings priority and set ring #16 priority */
> - reg = bcmgenet_tdma_readl(priv, DMA_RING_PRIORITY);
> - reg |= ((GENET_Q0_PRIORITY + priv->hw_params->tx_queues) << 20);
> - reg |= dma_priority;
> - bcmgenet_tdma_writel(priv, reg, DMA_PRIORITY);
> + /* Set ring 16 priority and program the hardware registers */
> + dma_priority[2] |=
> + ((GENET_Q0_PRIORITY + priv->hw_params->tx_queues) << 20);
Please use "<< (16 - 12) * DMA_RING_BUF_PRIORITY_SHIFT" otherwise this
constant is magic.
You might, optionally, add macros for the subtraction adjustment each
priority register uses (0, 6, 12, respectively).
^ permalink raw reply
* Re: [PATCH net] bna: page allocation during interrupts to use a mempool.
From: Eric Dumazet @ 2014-10-07 3:15 UTC (permalink / raw)
To: Eric Wheeler; +Cc: Shahed Shaikh, Stephen Hemminger, netdev, Rasesh Mody
In-Reply-To: <alpine.DEB.2.00.1410061956410.7392@ware.dreamhost.com>
On Mon, 2014-10-06 at 20:05 -0700, Eric Wheeler wrote:
> On Mon, 6 Oct 2014, Eric Dumazet wrote:
> > On Mon, 2014-10-06 at 18:57 -0700, Eric Wheeler wrote:
> >> This patch fixes an order:2 memory allocation error backtrace by
> >> guaranteeing that memory is available during simultaneous high memory
> >> pressure and packet rates when using 9k jumbo frames.
> >
> > This is highly suspect to me.
> > Most likely yet another truesize lie.
> > At a first glance, bnad_cq_setup_skb_frags() is buggy here :
> > skb->truesize += totlen;
>
> skb->truesize wasn't part of my patch, can you explain in more detail what
> you suggest a better fix might be? If you write a quick patch I can test
> it.
>
> The patch in question implements a simple mempool for the interrupt page
> allocs---which definitely fixes the problem even if a better solution
> might exist. I have no problem giving up a small amount of memory to
> guarantee page allocs in the interrupt handler.
>
> It would be great to see this patch pushed through since it does fix the
> problem---at least until we can come up with a better fix. I'm happy to
> test if you can send a patch.
It seems many drivers make this assumption that a frame of 1000 bytes
consumes 1000 bytes of memory.
Reality is that driver allocated more memory, because it can not predict
how many bytes are going to be received from the network.
By lying on skb->truesize (underestimating real memory cost), this
prevents networking stack making appropriate memory checks.
Here, it seems clear to me the following fix is needed, at very minimum.
And it might be that something better is needed : MTU=9000 might force
the driver to allocate 16384 bytes per frame, not 9018
So it is possible that unmap->vector.len needs to be changed to the real
size of memory region (for example : PAGE_SIZE << 2)
diff --git a/drivers/net/ethernet/brocade/bna/bnad.c b/drivers/net/ethernet/brocade/bna/bnad.c
index ffc92a41d75be550d27698af6ca3e600d9a146fe..ce867219e2ceaf33b17595b67bae99e964d5a6b6 100644
--- a/drivers/net/ethernet/brocade/bna/bnad.c
+++ b/drivers/net/ethernet/brocade/bna/bnad.c
@@ -550,6 +550,7 @@ bnad_cq_setup_skb_frags(struct bna_rcb *rcb, struct sk_buff *skb,
dma_unmap_addr(&unmap->vector, dma_addr),
unmap->vector.len, DMA_FROM_DEVICE);
+ skb->truesize += unmap->vector.len;
len = (vec == nvecs) ?
last_fraglen : unmap->vector.len;
totlen += len;
@@ -563,7 +564,6 @@ bnad_cq_setup_skb_frags(struct bna_rcb *rcb, struct sk_buff *skb,
skb->len += totlen;
skb->data_len += totlen;
- skb->truesize += totlen;
}
static inline void
^ permalink raw reply related
* Interested in your product
From: Emel Group @ 2014-10-07 2:52 UTC (permalink / raw)
Dear Sir,
My company is interested in your products. We are a big import company
based in Nigeria and we will like to import your products to Nigeria
in large quantities as we have decided to venture into the products
market. Nigeria is the biggest market in Africa and the destination of
every foreign product. My company can create very large market share
for your products as we have done for other products under our
company. Your collaboration in this venture is required for successful
business partnership.
View our updated company website below to know more about us.
Website hyperlink: http://ccya.tw/view/emelgroup.html
Yours faithfully.
Ben Hillary.
For: Emel Group Nig. Ltd.
^ permalink raw reply
* RE: r8168 is needed to enter P-state: Package State 6(pc6)onHaswellhardware
From: Hayes Wang @ 2014-10-07 2:50 UTC (permalink / raw)
To: Francois Romieu; +Cc: Ceriel Jacobs, nic_swsd, netdev@vger.kernel.org
In-Reply-To: <20141006221307.GB10936@electric-eye.fr.zoreil.com>
Francois Romieu [mailto:romieu@fr.zoreil.com]
> Sent: Tuesday, October 07, 2014 6:13 AM
[...]
> Realtek's r8168 driver defaults to CONFIG_ASPM=1 but I guess
> some users
> need to disable it and there's no known pattern / blacklist, right ?
When enabling the ASPM, it would influence the thrpughput. It is hard to
choose performance or power saving. Therefore, we reserve the config
to let the user determines it.
Best Regards,
Hayes
^ permalink raw reply
* Re: [PATCH net] bna: page allocation during interrupts to use a mempool.
From: Eric Wheeler @ 2014-10-07 3:05 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Shahed Shaikh, Stephen Hemminger, netdev, Rasesh Mody
In-Reply-To: <1412646735.11091.93.camel@edumazet-glaptop2.roam.corp.google.com>
On Mon, 6 Oct 2014, Eric Dumazet wrote:
> On Mon, 2014-10-06 at 18:57 -0700, Eric Wheeler wrote:
>> This patch fixes an order:2 memory allocation error backtrace by
>> guaranteeing that memory is available during simultaneous high memory
>> pressure and packet rates when using 9k jumbo frames.
>
> This is highly suspect to me.
> Most likely yet another truesize lie.
> At a first glance, bnad_cq_setup_skb_frags() is buggy here :
> skb->truesize += totlen;
skb->truesize wasn't part of my patch, can you explain in more detail what
you suggest a better fix might be? If you write a quick patch I can test
it.
The patch in question implements a simple mempool for the interrupt page
allocs---which definitely fixes the problem even if a better solution
might exist. I have no problem giving up a small amount of memory to
guarantee page allocs in the interrupt handler.
It would be great to see this patch pushed through since it does fix the
problem---at least until we can come up with a better fix. I'm happy to
test if you can send a patch.
-Eric
>
> With this kind of lies, system can OOM very fast.
>
>
>
> --
> 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
* Fast Response .
From: yuxiaoli @ 2014-10-07 1:38 UTC (permalink / raw)
Hello my name is Austin, i have an important message for you, please get back to me as
soon as possible , here is my email : aus.12345@hotmail.com
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
^ permalink raw reply
* Re: [PATCH net] bna: page allocation during interrupts to use a mempool.
From: Eric Dumazet @ 2014-10-07 1:52 UTC (permalink / raw)
To: Eric Wheeler
Cc: Shahed Shaikh, Stephen Hemminger, netdev, rmody@brocade.com,
Rasesh Mody
In-Reply-To: <alpine.DEB.2.00.1410061850120.5129@ware.dreamhost.com>
On Mon, 2014-10-06 at 18:57 -0700, Eric Wheeler wrote:
> This patch fixes an order:2 memory allocation error backtrace by
> guaranteeing that memory is available during simultaneous high memory
> pressure and packet rates when using 9k jumbo frames.
>
> Tests between two systems (one patched, one not) succeeded with ~1TB of
> data transferred over DRBD. As expected, the unpatched host gave
> warn_alloc_failed's, and the patched host worked correctly. This patch
> increases kernel memory usage by 32 order-2 allocation when this module is
> loaded (512k on x86) which should be negligible on hosts that use 10GbE
> cards.
This is highly suspect to me.
Most likely yet another truesize lie.
At a first glance, bnad_cq_setup_skb_frags() is buggy here :
skb->truesize += totlen;
With this kind of lies, system can OOM very fast.
^ permalink raw reply
* [PATCH net] bna: page allocation during interrupts to use a mempool.
From: Eric Wheeler @ 2014-10-07 1:57 UTC (permalink / raw)
To: Shahed Shaikh; +Cc: Stephen Hemminger, netdev, rmody@brocade.com, Rasesh Mody
In-Reply-To: <262CB373A6D1F14F9B81E82F74F77D5A4704FAE7@avmb2.qlogic.org>
This patch fixes an order:2 memory allocation error backtrace by
guaranteeing that memory is available during simultaneous high memory
pressure and packet rates when using 9k jumbo frames.
Tests between two systems (one patched, one not) succeeded with ~1TB of
data transferred over DRBD. As expected, the unpatched host gave
warn_alloc_failed's, and the patched host worked correctly. This patch
increases kernel memory usage by 32 order-2 allocation when this module is
loaded (512k on x86) which should be negligible on hosts that use 10GbE
cards.
Fixes:
[<ffffffff8113b17b>] warn_alloc_failed+0xeb/0x150
[<ffffffff8113e2f0>] __alloc_pages_slowpath+0x4a0/0x7e0
[<ffffffff8113e8e2>] __alloc_pages_nodemask+0x2b2/0x2c0
[<ffffffff81181232>] alloc_pages_current+0xb2/0x170
[<ffffffffa0239cb4>] bnad_rxq_refill_page+0x154/0x1e0 [bna]
[<ffffffffa023c282>] bnad_cq_process+0x462/0x840 [bna]
[<ffffffffa023c6af>] bnad_napi_poll_rx+0x4f/0xc0 [bna]
[<ffffffff814dcf4c>] net_rx_action+0xfc/0x280
[<ffffffff8105ba83>] __do_softirq+0xf3/0x2c0
[<ffffffff8105bd5d>] irq_exit+0xbd/0xd0
[<ffffffff815ae697>] do_IRQ+0x67/0x110
[<ffffffff815a39ad>] common_interrupt+0x6d/0x6d
<EOI>
[<ffffffff81486275>] ? cpuidle_enter_state+0x55/0xd0
[<ffffffff8148626b>] ? cpuidle_enter_state+0x4b/0xd0
[<ffffffff814863b7>] cpuidle_idle_call+0xc7/0x160
[<ffffffff8100d73e>] arch_cpu_idle+0xe/0x30
[<ffffffff810b187e>] cpu_idle_loop+0x9e/0x250
[<ffffffff810b1aa0>] cpu_startup_entry+0x70/0x80
[<ffffffff810350d2>] start_secondary+0xd2/0xe0
Signed-off-by: Eric Wheeler <netdev@lists.ewheeler.net>
---
drivers/net/ethernet/brocade/bna/bnad.c | 27 ++++++++++++++++++++++++---
1 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/brocade/bna/bnad.c b/drivers/net/ethernet/brocade/bna/bnad.c
index 3a77f9e..8906ad1 100644
--- a/drivers/net/ethernet/brocade/bna/bnad.c
+++ b/drivers/net/ethernet/brocade/bna/bnad.c
@@ -26,6 +26,7 @@
#include <linux/ip.h>
#include <linux/prefetch.h>
#include <linux/module.h>
+#include <linux/mempool.h>
#include "bnad.h"
#include "bna.h"
@@ -58,6 +59,8 @@ static struct mutex bnad_list_mutex;
static LIST_HEAD(bnad_list);
static const u8 bnad_bcast_addr[] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
+static mempool_t *rxq_mempool_o2 = NULL;
+
/*
* Local MACROS
*/
@@ -321,7 +324,7 @@ bnad_rxq_cleanup_page(struct bnad *bnad, struct bnad_rx_unmap *unmap)
dma_unmap_page(&bnad->pcidev->dev,
dma_unmap_addr(&unmap->vector, dma_addr),
unmap->vector.len, DMA_FROM_DEVICE);
- put_page(unmap->page);
+ mempool_free(unmap->page, rxq_mempool_o2);
unmap->page = NULL;
dma_unmap_addr_set(&unmap->vector, dma_addr, 0);
unmap->vector.len = 0;
@@ -380,8 +383,11 @@ bnad_rxq_refill_page(struct bnad *bnad, struct bna_rcb *rcb, u32 nalloc)
unmap = &unmap_q->unmap[prod];
if (unmap_q->reuse_pi < 0) {
- page = alloc_pages(GFP_ATOMIC | __GFP_COMP,
- unmap_q->alloc_order);
+ if (unmap_q->alloc_order == 2)
+ page = mempool_alloc(rxq_mempool_o2, GFP_ATOMIC | __GFP_COMP);
+ else
+ page = alloc_pages(GFP_ATOMIC | __GFP_COMP,
+ unmap_q->alloc_order);
page_offset = 0;
} else {
prev = &unmap_q->unmap[unmap_q->reuse_pi];
@@ -3861,6 +3867,16 @@ static struct pci_driver bnad_pci_driver = {
.remove = bnad_pci_remove,
};
+void *bnad_rxq_mempool_alloc_o2(gfp_t gfp_mask, void *pool_data)
+{
+ return (void*) alloc_pages(gfp_mask, 2);
+}
+
+void bnad_rxq_mempool_free_o2(void *page, void *pool_data)
+{
+ put_page((struct page*)page);
+}
+
static int __init
bnad_module_init(void)
{
@@ -3878,6 +3894,10 @@ bnad_module_init(void)
return err;
}
+ rxq_mempool_o2 = mempool_create(32, /* how many do we really need? */
+ bnad_rxq_mempool_alloc_o2,
+ bnad_rxq_mempool_free_o2, NULL);
+
return 0;
}
@@ -3886,6 +3906,7 @@ bnad_module_exit(void)
{
pci_unregister_driver(&bnad_pci_driver);
release_firmware(bfi_fw);
+ mempool_destroy(rxq_mempool_o2);
}
module_init(bnad_module_init);
--
1.7.1
^ permalink raw reply related
* [PATCH net-next] net: bcmgenet: fix Tx ring priority programming
From: Petri Gynther @ 2014-10-07 0:50 UTC (permalink / raw)
To: netdev; +Cc: davem, f.fainelli
GENET MAC has three Tx ring priority registers:
- GENET_x_TDMA_PRIORITY0 for queues 0-5
- GENET_x_TDMA_PRIORITY1 for queues 6-11
- GENET_x_TDMA_PRIORITY2 for queues 12-16
Fix bcmgenet_init_multiq() to program them correctly.
Signed-off-by: Petri Gynther <pgynther@google.com>
---
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 46 +++++++++++++++++---------
1 file changed, 30 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
index e0a6238..151d5b2 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
@@ -191,8 +191,9 @@ enum dma_reg {
DMA_STATUS,
DMA_SCB_BURST_SIZE,
DMA_ARB_CTRL,
- DMA_PRIORITY,
- DMA_RING_PRIORITY,
+ DMA_PRIORITY_0,
+ DMA_PRIORITY_1,
+ DMA_PRIORITY_2,
};
static const u8 bcmgenet_dma_regs_v3plus[] = {
@@ -201,8 +202,9 @@ static const u8 bcmgenet_dma_regs_v3plus[] = {
[DMA_STATUS] = 0x08,
[DMA_SCB_BURST_SIZE] = 0x0C,
[DMA_ARB_CTRL] = 0x2C,
- [DMA_PRIORITY] = 0x30,
- [DMA_RING_PRIORITY] = 0x38,
+ [DMA_PRIORITY_0] = 0x30,
+ [DMA_PRIORITY_1] = 0x34,
+ [DMA_PRIORITY_2] = 0x38,
};
static const u8 bcmgenet_dma_regs_v2[] = {
@@ -211,8 +213,9 @@ static const u8 bcmgenet_dma_regs_v2[] = {
[DMA_STATUS] = 0x08,
[DMA_SCB_BURST_SIZE] = 0x0C,
[DMA_ARB_CTRL] = 0x30,
- [DMA_PRIORITY] = 0x34,
- [DMA_RING_PRIORITY] = 0x3C,
+ [DMA_PRIORITY_0] = 0x34,
+ [DMA_PRIORITY_1] = 0x38,
+ [DMA_PRIORITY_2] = 0x3C,
};
static const u8 bcmgenet_dma_regs_v1[] = {
@@ -220,8 +223,9 @@ static const u8 bcmgenet_dma_regs_v1[] = {
[DMA_STATUS] = 0x04,
[DMA_SCB_BURST_SIZE] = 0x0C,
[DMA_ARB_CTRL] = 0x30,
- [DMA_PRIORITY] = 0x34,
- [DMA_RING_PRIORITY] = 0x3C,
+ [DMA_PRIORITY_0] = 0x34,
+ [DMA_PRIORITY_1] = 0x38,
+ [DMA_PRIORITY_2] = 0x3C,
};
/* Set at runtime once bcmgenet version is known */
@@ -1696,7 +1700,8 @@ static void bcmgenet_init_multiq(struct net_device *dev)
{
struct bcmgenet_priv *priv = netdev_priv(dev);
unsigned int i, dma_enable;
- u32 reg, dma_ctrl, ring_cfg = 0, dma_priority = 0;
+ u32 reg, dma_ctrl, ring_cfg = 0;
+ u32 dma_priority[3] = {0, 0, 0};
if (!netif_is_multiqueue(dev)) {
netdev_warn(dev, "called with non multi queue aware HW\n");
@@ -1721,9 +1726,17 @@ static void bcmgenet_init_multiq(struct net_device *dev)
/* Configure ring as descriptor ring and setup priority */
ring_cfg |= 1 << i;
- dma_priority |= ((GENET_Q0_PRIORITY + i) <<
- (GENET_MAX_MQ_CNT + 1) * i);
dma_ctrl |= 1 << (i + DMA_RING_BUF_EN_SHIFT);
+
+ if (i < 6)
+ dma_priority[0] |= ((GENET_Q0_PRIORITY + i) <<
+ (i * DMA_RING_BUF_PRIORITY_SHIFT));
+ else if (i < 12)
+ dma_priority[1] |= ((GENET_Q0_PRIORITY + i) <<
+ ((i - 6) * DMA_RING_BUF_PRIORITY_SHIFT));
+ else
+ dma_priority[2] |= ((GENET_Q0_PRIORITY + i) <<
+ ((i - 12) * DMA_RING_BUF_PRIORITY_SHIFT));
}
/* Enable rings */
@@ -1731,11 +1744,12 @@ static void bcmgenet_init_multiq(struct net_device *dev)
reg |= ring_cfg;
bcmgenet_tdma_writel(priv, reg, DMA_RING_CFG);
- /* Use configured rings priority and set ring #16 priority */
- reg = bcmgenet_tdma_readl(priv, DMA_RING_PRIORITY);
- reg |= ((GENET_Q0_PRIORITY + priv->hw_params->tx_queues) << 20);
- reg |= dma_priority;
- bcmgenet_tdma_writel(priv, reg, DMA_PRIORITY);
+ /* Set ring 16 priority and program the hardware registers */
+ dma_priority[2] |=
+ ((GENET_Q0_PRIORITY + priv->hw_params->tx_queues) << 20);
+ bcmgenet_tdma_writel(priv, dma_priority[0], DMA_PRIORITY_0);
+ bcmgenet_tdma_writel(priv, dma_priority[1], DMA_PRIORITY_1);
+ bcmgenet_tdma_writel(priv, dma_priority[2], DMA_PRIORITY_2);
/* Configure ring as descriptor ring and re-enable DMA if enabled */
reg = bcmgenet_tdma_readl(priv, DMA_CTRL);
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* Re: [PATCH iproute2 1/5] iplink: Fix setting of -1 as ifindex
From: Cong Wang @ 2014-10-07 0:42 UTC (permalink / raw)
To: Tom Herbert; +Cc: David Miller, Stephen Hemminger, netdev
In-Reply-To: <1412351718-22921-2-git-send-email-therbert@google.com>
On Fri, Oct 3, 2014 at 8:55 AM, Tom Herbert <therbert@google.com> wrote:
> Commit 3c682146aeff157ec3540 ("iplink: forbid negative ifindex and
> modifying ifindex") initializes index to -1 in iplink_modify. When
> creating a link, req.i.ifi_index is then set to -1 if the link option is
> not used. In the kernel this is then used to set dev->ifindex. For
> dev->ifindex, zero is considered to be unset and -1 is treated as
> a set index, so when a second tunnel is create the new device conflicts
> with the old one (both have ifindex of -1) so -EBUSY is returned.
>
> This patch set zero in req.i.ifi_index is index is unset (still -1).
There was a patch before yours:
https://patchwork.ozlabs.org/patch/395404/
^ 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