* Re: [PATCH RFC] net: decrease the length of backlog queue immediately after it's detached from sk
From: Eric Dumazet @ 2016-04-11 12:13 UTC (permalink / raw)
To: Yang Yingliang; +Cc: netdev, davem, Ding Tianhong
In-Reply-To: <570B9126.9080806@huawei.com>
On Mon, 2016-04-11 at 19:57 +0800, Yang Yingliang wrote:
>
> On 2016/4/8 22:44, Eric Dumazet wrote:
> > On Fri, 2016-04-08 at 19:18 +0800, Yang Yingliang wrote:
> >
> >> I expand tcp_adv_win_scale and tcp_rmem. It has no effect.
> >
> > Try :
> >
> > echo -2 >/proc/sys/net/ipv4/tcp_adv_win_scale
> >
> > And restart your flows.
> >
> cat /proc/sys/net/ipv4/tcp_rmem
> 10240 2097152 10485760
What about leaving the default values ?
$ cat /proc/sys/net/ipv4/tcp_rmem
4096 87380 6291456
>
> echo 102400 20971520 104857600 > /proc/sys/net/ipv4/tcp_rmem
> echo -2 >/proc/sys/net/ipv4/tcp_adv_win_scale
>
> It seems has not effect.
>
I have no idea what you did on the sender side to allow it to send more
than 1.5 MB then.
^ permalink raw reply
* Re: [PATCH net-next 09/11] fjes: Enhance changing MTU related work
From: Jiri Pirko @ 2016-04-11 12:03 UTC (permalink / raw)
To: Taku Izumi; +Cc: davem, netdev
In-Reply-To: <1460362246-15380-1-git-send-email-izumi.taku@jp.fujitsu.com>
Mon, Apr 11, 2016 at 10:10:46AM CEST, izumi.taku@jp.fujitsu.com wrote:
>This patch enhances the fjes_change_mtu() method
>by introducing new flag named FJES_RX_MTU_CHANGING_DONE
>in rx_status. At the same time, default MTU value is
>changed into 65510 bytes.
>
>Signed-off-by: Taku Izumi <izumi.taku@jp.fujitsu.com>
<snip>
>@@ -793,19 +798,54 @@ static int fjes_change_mtu(struct net_device *netdev, int new_mtu)
> if (new_mtu == netdev->mtu)
> return 0;
>
>- if (running)
>- fjes_close(netdev);
>+ ret = 0;
>+ break;
>+ }
>+ }
>+
>+ if (ret)
>+ return ret;
>
>- netdev->mtu = new_mtu;
>+ if (running) {
>+ for (epidx = 0; epidx < hw->max_epid; epidx++) {
>+ if (epidx == hw->my_epid)
>+ continue;
>+ hw->ep_shm_info[epidx].tx.info->v1i.rx_status &=
>+ ~FJES_RX_MTU_CHANGING_DONE;
>+ }
>+ netif_tx_stop_all_queues(netdev);
>+ netif_carrier_off(netdev);
>+ cancel_work_sync(&adapter->tx_stall_task);
>+ napi_disable(&adapter->napi);
>
>- if (running)
>- ret = fjes_open(netdev);
>+ msleep(1000);
Will it be enough? I would rather sleep 2000ms here, just to be sure :)
^ permalink raw reply
* Re: [PATCH net-next 04/11] fjes: Add debugfs entry for statistics
From: Jiri Pirko @ 2016-04-11 12:01 UTC (permalink / raw)
To: Taku Izumi; +Cc: davem, netdev
In-Reply-To: <1460362216-15165-1-git-send-email-izumi.taku@jp.fujitsu.com>
Mon, Apr 11, 2016 at 10:10:16AM CEST, izumi.taku@jp.fujitsu.com wrote:
>This patch introduces debugfs entry named "statistics"
>for statistics information.
>You can get net_stats information by reading
>/sys/kernel/debug/fjes/fjes.N/statistics file.
>This is useful for debugging.
>
>Signed-off-by: Taku Izumi <izumi.taku@jp.fujitsu.com>
>---
> drivers/net/fjes/fjes_debugfs.c | 72 +++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 72 insertions(+)
>
>diff --git a/drivers/net/fjes/fjes_debugfs.c b/drivers/net/fjes/fjes_debugfs.c
>index d2fd892..b0807c2 100644
>--- a/drivers/net/fjes/fjes_debugfs.c
>+++ b/drivers/net/fjes/fjes_debugfs.c
>@@ -31,6 +31,72 @@
>
> static struct dentry *fjes_debug_root;
>
>+static int fjes_dbg_stats_show(struct seq_file *m, void *v)
>+{
>+ struct fjes_adapter *adapter = m->private;
>+ struct fjes_hw *hw = &adapter->hw;
>+ int max_epid = hw->max_epid;
>+ int my_epid = hw->my_epid;
>+ int epidx;
>+
>+ seq_printf(m, "%41s", " ");
>+ for (epidx = 0; epidx < max_epid; epidx++)
>+ seq_printf(m, "%10s%d",
>+ my_epid == epidx ? "(self)EP#" : "EP#", epidx);
>+ seq_printf(m, "\n");
>+
>+#define FJES_DEBUGFS_NET_STATS_ENTRY(X) do { \
>+ seq_printf(m, "%-41s", #X); \
>+ for (epidx = 0; epidx < max_epid; epidx++) { \
>+ if (epidx == my_epid) \
>+ seq_printf(m, " -"); \
>+ else \
>+ seq_printf(m, " %10llu", \
>+ hw->ep_shm_info[epidx].net_stats.X); \
>+ } \
>+ seq_printf(m, "\n"); \
>+} while (0)
>+
>+ FJES_DEBUGFS_NET_STATS_ENTRY(rx_packets);
>+ FJES_DEBUGFS_NET_STATS_ENTRY(tx_packets);
>+ FJES_DEBUGFS_NET_STATS_ENTRY(rx_bytes);
>+ FJES_DEBUGFS_NET_STATS_ENTRY(tx_bytes);
>+ FJES_DEBUGFS_NET_STATS_ENTRY(rx_errors);
>+ FJES_DEBUGFS_NET_STATS_ENTRY(tx_errors);
>+ FJES_DEBUGFS_NET_STATS_ENTRY(rx_dropped);
>+ FJES_DEBUGFS_NET_STATS_ENTRY(tx_dropped);
>+ FJES_DEBUGFS_NET_STATS_ENTRY(multicast);
>+ FJES_DEBUGFS_NET_STATS_ENTRY(collisions);
>+ FJES_DEBUGFS_NET_STATS_ENTRY(rx_length_errors);
>+ FJES_DEBUGFS_NET_STATS_ENTRY(rx_over_errors);
>+ FJES_DEBUGFS_NET_STATS_ENTRY(rx_crc_errors);
>+ FJES_DEBUGFS_NET_STATS_ENTRY(rx_frame_errors);
>+ FJES_DEBUGFS_NET_STATS_ENTRY(rx_fifo_errors);
>+ FJES_DEBUGFS_NET_STATS_ENTRY(rx_missed_errors);
>+ FJES_DEBUGFS_NET_STATS_ENTRY(tx_aborted_errors);
>+ FJES_DEBUGFS_NET_STATS_ENTRY(tx_carrier_errors);
>+ FJES_DEBUGFS_NET_STATS_ENTRY(tx_fifo_errors);
>+ FJES_DEBUGFS_NET_STATS_ENTRY(tx_heartbeat_errors);
>+ FJES_DEBUGFS_NET_STATS_ENTRY(tx_window_errors);
>+ FJES_DEBUGFS_NET_STATS_ENTRY(rx_compressed);
>+ FJES_DEBUGFS_NET_STATS_ENTRY(tx_compressed);
This patch is certainly wrong. You should use existing well defined
stats API to expose this and not custom debufs blob.
^ permalink raw reply
* Re: [PATCH net-next 01/11] fjes: Add trace-gathering facility
From: Jiri Pirko @ 2016-04-11 11:59 UTC (permalink / raw)
To: Taku Izumi; +Cc: davem, netdev
In-Reply-To: <1460362197-15033-1-git-send-email-izumi.taku@jp.fujitsu.com>
Mon, Apr 11, 2016 at 10:09:57AM CEST, izumi.taku@jp.fujitsu.com wrote:
>This patch introduces trace-gathering facility via ioctl.
>This data is useful for debugging this module and firmware.
>
>Signed-off-by: Taku Izumi <izumi.taku@jp.fujitsu.com>
<snip>
>@@ -61,6 +62,7 @@ fjes_get_stats64(struct net_device *, struct rtnl_link_stats64 *);
> static int fjes_change_mtu(struct net_device *, int);
> static int fjes_vlan_rx_add_vid(struct net_device *, __be16 proto, u16);
> static int fjes_vlan_rx_kill_vid(struct net_device *, __be16 proto, u16);
>+static int fjes_ioctl(struct net_device *, struct ifreq *, int cmd);
> static void fjes_tx_retry(struct net_device *);
>
> static int fjes_acpi_add(struct acpi_device *);
>@@ -242,6 +244,7 @@ static const struct net_device_ops fjes_netdev_ops = {
> .ndo_tx_timeout = fjes_tx_retry,
> .ndo_vlan_rx_add_vid = fjes_vlan_rx_add_vid,
> .ndo_vlan_rx_kill_vid = fjes_vlan_rx_kill_vid,
>+ .ndo_do_ioctl = fjes_ioctl,
> };
<snip>
>+
>+static int fjes_ioctl(struct net_device *netdev, struct ifreq *rq, int cmd)
>+{
>+ switch (cmd) {
>+ case FJES_IOCTL_TRACE_START:
>+ return fjes_ioctl_trace_start(netdev, rq);
>+ case FJES_IOCTL_TRACE_STOP:
>+ return fjes_ioctl_trace_stop(netdev, rq);
>+ case FJES_IOCTL_TRACE_GETCFG:
>+ return fjes_ioctl_trace_getcfg(netdev, rq);
>+ default:
>+ return -EOPNOTSUPP;
>+ }
>+}
This ioctl tracing patch looks scarry to me. I don't think you should
add any functionality to ioctl today.
^ permalink raw reply
* Re: [PATCH RFC] net: decrease the length of backlog queue immediately after it's detached from sk
From: Yang Yingliang @ 2016-04-11 11:57 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, davem, Ding Tianhong
In-Reply-To: <1460126665.6473.437.camel@edumazet-glaptop3.roam.corp.google.com>
On 2016/4/8 22:44, Eric Dumazet wrote:
> On Fri, 2016-04-08 at 19:18 +0800, Yang Yingliang wrote:
>
>> I expand tcp_adv_win_scale and tcp_rmem. It has no effect.
>
> Try :
>
> echo -2 >/proc/sys/net/ipv4/tcp_adv_win_scale
>
> And restart your flows.
>
cat /proc/sys/net/ipv4/tcp_rmem
10240 2097152 10485760
echo 102400 20971520 104857600 > /proc/sys/net/ipv4/tcp_rmem
echo -2 >/proc/sys/net/ipv4/tcp_adv_win_scale
It seems has not effect.
^ permalink raw reply
* Re: [PATCH net-next 02/11] fjes: Add setting/getting register value feature via ioctl
From: Jiri Pirko @ 2016-04-11 11:56 UTC (permalink / raw)
To: Taku Izumi; +Cc: davem, netdev
In-Reply-To: <1460362204-15078-1-git-send-email-izumi.taku@jp.fujitsu.com>
Mon, Apr 11, 2016 at 10:10:04AM CEST, izumi.taku@jp.fujitsu.com wrote:
>This patch introduces setting/getting register value feature
>via ioctl. This feature is useful for debugging.
>
>Signed-off-by: Taku Izumi <izumi.taku@jp.fujitsu.com>
>---
> drivers/net/fjes/fjes_ioctl.h | 7 +++++++
> drivers/net/fjes/fjes_main.c | 39 +++++++++++++++++++++++++++++++++++++++
> 2 files changed, 46 insertions(+)
>
>diff --git a/drivers/net/fjes/fjes_ioctl.h b/drivers/net/fjes/fjes_ioctl.h
>index 35adfda..61619f7 100644
>--- a/drivers/net/fjes/fjes_ioctl.h
>+++ b/drivers/net/fjes/fjes_ioctl.h
>@@ -25,6 +25,8 @@
> #define FJES_IOCTL_TRACE_START (SIOCDEVPRIVATE + 1)
> #define FJES_IOCTL_TRACE_STOP (SIOCDEVPRIVATE + 2)
> #define FJES_IOCTL_TRACE_GETCFG (SIOCDEVPRIVATE + 3)
>+#define FJES_IOCTL_DEV_GETREG (SIOCDEVPRIVATE + 4)
>+#define FJES_IOCTL_DEV_SETREG (SIOCDEVPRIVATE + 5)
This patch certainly looks wrong to me. Exposing read and mainly write
access to registers using ioctl? I don't think so...
>
> struct fjes_ioctl_trace_start_req_val {
> u32 mode;
>@@ -70,6 +72,11 @@ struct fjes_ioctl_trace_param {
> union fjes_ioctl_trace_res_val res;
> };
>
>+struct fjes_ioctl_dev_reg_param {
>+ u32 offset;
>+ u32 val;
>+};
>+
> #define FJES_IOCTL_TRACE_START_ERR_NORMAL (0x0000)
> #define FJES_IOCTL_TRACE_START_ERR_BUSY (0x0001)
> #define FJES_IOCTL_TRACE_START_ERR_PARAM (0x0100)
>diff --git a/drivers/net/fjes/fjes_main.c b/drivers/net/fjes/fjes_main.c
>index bc6e31d..40cf65d 100644
>--- a/drivers/net/fjes/fjes_main.c
>+++ b/drivers/net/fjes/fjes_main.c
>@@ -977,6 +977,40 @@ static int fjes_ioctl_trace_getcfg(struct net_device *netdev, struct ifreq *rq)
> return 0;
> }
>
>+static int fjes_ioctl_reg_read(struct net_device *netdev, struct ifreq *rq)
>+{
>+ struct fjes_adapter *adapter = netdev_priv(netdev);
>+ struct fjes_ioctl_dev_reg_param reg;
>+ struct fjes_hw *hw = &adapter->hw;
>+
>+ if (copy_from_user(®, rq->ifr_data, sizeof(reg)))
>+ return -EFAULT;
>+
>+ reg.val = rd32(reg.offset);
>+
>+ if (copy_to_user(rq->ifr_data, ®, sizeof(reg)))
>+ return -EFAULT;
>+
>+ return 0;
>+}
>+
>+static int fjes_ioctl_reg_write(struct net_device *netdev, struct ifreq *rq)
>+{
>+ struct fjes_adapter *adapter = netdev_priv(netdev);
>+ struct fjes_ioctl_dev_reg_param reg;
>+ struct fjes_hw *hw = &adapter->hw;
>+
>+ if (copy_from_user(®, rq->ifr_data, sizeof(reg)))
>+ return -EFAULT;
>+
>+ wr32(reg.offset, reg.val);
>+
>+ if (copy_to_user(rq->ifr_data, ®, sizeof(reg)))
>+ return -EFAULT;
>+
>+ return 0;
>+}
>+
> static int fjes_ioctl(struct net_device *netdev, struct ifreq *rq, int cmd)
> {
> switch (cmd) {
>@@ -986,7 +1020,12 @@ static int fjes_ioctl(struct net_device *netdev, struct ifreq *rq, int cmd)
> return fjes_ioctl_trace_stop(netdev, rq);
> case FJES_IOCTL_TRACE_GETCFG:
> return fjes_ioctl_trace_getcfg(netdev, rq);
>+ case FJES_IOCTL_DEV_GETREG:
>+ return fjes_ioctl_reg_read(netdev, rq);
>+ case FJES_IOCTL_DEV_SETREG:
>+ return fjes_ioctl_reg_write(netdev, rq);
> default:
>+
> return -EOPNOTSUPP;
> }
> }
>--
>2.4.3
>
^ permalink raw reply
* Re: AF_VSOCK status
From: Antoine Martin @ 2016-04-11 11:53 UTC (permalink / raw)
To: Stefan Hajnoczi; +Cc: netdev
In-Reply-To: <20160406092609.GA17538@stefanha-x1.localdomain>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
(snip)
> The patches are on the list (latest version sent last week):
> http://comments.gmane.org/gmane.linux.kernel.virtualization/27455
>
> They are only "Request For Comments" because the VIRTIO
> specification changes have not been approved yet. Once the spec
> is approved then the patches can be seriously considered for
> merging.
>
> There will definitely be a v6 with Claudio Imbrenda's locking
> fixes.
If that's any help, feel free to CC me and we'll test it.
(not sure how long I will stay subscribed to this high traffic list)
>> We now have a vsock transport merged into xpra, which works very
>> well with the kernel and qemu versions found here:
>> http://qemu-project.org/Features/VirtioVsock Congratulations on
>> making this easy to use! Is the upcoming revised interface
>> likely to cause incompatibilities with existing binaries?
>
> Userspace applications should not notice a difference.
Great.
>> It seems impossible for the host to connect to a guest: the
>> guest has to initiate the connection. Is this a feature / known
>> limitation or am I missing something? For some of our use cases,
>> it would be more practical to connect in the other direction.
>
> host->guest connections have always been allowed. I just checked
> that it works with the latest code in my repo:
>
> guest# nc-vsock -l 1234 host# nc-vsock 3 1234
Sorry about that, it does work fine, I must have tested it wrong.
With our latest code:
* host connecting to a guest session:
guest# xpra start --bind-vsock=auto:1234 --start-child=xterm
host# xpra attach vsock:$THECID:1234
* guest out to the host (no need for knowing the CID):
host# xpra start --bind-vsock=auto:1234 --start-child=xterm
guest# xpra attach vsock:host:1234
>> In terms of raw performance, I am getting about 10Gbps on an
>> Intel Skylake i7 (the data stream arrives from the OS socket
>> recv syscall split into 256KB chunks), that's good but not much
>> faster than virtio-net and since the packets are avoiding all
>> sorts of OS layer overheads I was hoping to get a little bit
>> closer to the ~200Gbps memory bandwidth that this CPU+RAM are
>> capable of. Am I dreaming or just doing it wrong?
>
> virtio-vsock is not yet optimized but the priority is not to make
> something faster than virtio-net. virtio-vsock is not for
> applications who are trying to squeeze out every last drop of
> performance. Instead the goal is to have a transport for
> guest<->hypervisor services that need to be zero-configuration.
Understood. It does that and this is a big win for us already, it's
also faster than virtio-net it seems, so this was not a complaint.
>> How hard would it be to introduce a virtio mmap-like transport
>> of some sort so that the guest and host could share some memory
>> region? I assume this would give us the best possible
>> performance when transferring large amounts of data? (we already
>> have a local mmap transport we could adapt)
>
> Shared memory is beyond the scope of virtio-vsock and it's
> unlikely to be added.
I wasn't thinking of adding this to virtio-vsock, this would be a
separate backend.
> There are a few existing ways to achieve that without involving
> virtio-vsock: vhost-user or ivshmem.
Yes, I've looked at those and they seem a bit overkill for what we
want to achieve. We don't want sharing with multiple guests, or
interrupts.
All we want is a chunk of host memory to be accessible from the guest..
Thanks
Antoine
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEARECAAYFAlcLkBsACgkQGK2zHPGK1ruJ0wCfbNkc5L0ewUBuI7DgTyuwGRBz
aZoAn2pEbrVAkLoCMOunCYQ1FoaDIETr
=qrz1
-----END PGP SIGNATURE-----
^ permalink raw reply
* RE: AP firmware for TI wl1251 wifi chip (wl1251-fw-ap.bin)
From: Machani, Yaniv @ 2016-04-11 11:49 UTC (permalink / raw)
To: Pali Rohár, Pavel Machek
Cc: Chalmers, Kevin, Kalle Valo, Davis, Andrew, Mishol, Guy,
Arik Nemtsov, Gery Kahn, Felipe Balbi, David Woodhouse,
Aaro Koskinen, Ben Hutchings, David Gnedt, Ivaylo Dimitrov,
Sebastian Reichel, Tony Lindgren, Menon, Nishanth,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20160411114118.GT8413@pali>
On Mon, Apr 11, 2016 at 14:41:18, Pali Rohár wrote:
> Mishol, Guy; Arik Nemtsov; Gery Kahn; Felipe Balbi; David Woodhouse;
> Aaro Koskinen; Ben Hutchings; David Gnedt; Ivaylo Dimitrov; Sebastian
> Reichel; Tony Lindgren; Menon, Nishanth;
> linux-wireless@vger.kernel.org; netdev@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: AP firmware for TI wl1251 wifi chip (wl1251-fw-ap.bin)
>
> On Sunday 10 April 2016 13:51:41 Pavel Machek wrote:
> > Is it "hardware can't do AP", "firmware can't do AP" or "current
> > drivers do not support AP"?
>
As both Firmware and HW are not in a stage where they can be modified, there is no support for AP mode in both.
Regards,
Yaniv Machani
^ permalink raw reply
* Re: AP firmware for TI wl1251 wifi chip (wl1251-fw-ap.bin)
From: Pali Rohár @ 2016-04-11 11:41 UTC (permalink / raw)
To: Pavel Machek
Cc: Machani, Yaniv, Chalmers, Kevin, Kalle Valo, Davis, Andrew,
Mishol, Guy, Arik Nemtsov, Gery Kahn, Felipe Balbi,
David Woodhouse, Aaro Koskinen, Ben Hutchings, David Gnedt,
Ivaylo Dimitrov, Sebastian Reichel, Tony Lindgren,
Menon, Nishanth, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20160410115141.GD30188@xo-6d-61-c0.localdomain>
On Sunday 10 April 2016 13:51:41 Pavel Machek wrote:
> Is it "hardware can't do AP", "firmware can't do AP" or "current drivers
> do not support AP"?
We know that current linux TI wl1251.ko driver does not support AP. And
I'm still do not know if "hardware can do AP" or not. Also I'm not sure...
maybe current firmware can be "forced" for implementing AP mode.
David Gnedt implemented packet injection for wl1251.ko via JOIN firmware
command. And he wrote me that aircrack utils contains one application
which implementing full AP station in userspace just via packet
injection radiotap (which is supported by wl1251).
So maybe using other firmware (filter) commands together with current
packet injection implementation could be possible to create AP mode
(usable for standard hostapd daemon)? Just thinking...
Anyway, other TI wilink devices have different firmware for AP mode...
--
Pali Rohár
pali.rohar@gmail.com
^ permalink raw reply
* Re: [PATCH v1] net: cdc_ncm: update datagram size after changing mtu
From: Robert Dobrowolski @ 2016-04-11 12:00 UTC (permalink / raw)
To: Bjørn Mork
Cc: Robert Dobrowolski, linux-usb, rafal.f.redzimski, stable, oliver,
netdev, linux-kernel
In-Reply-To: <87h9fex0ql.fsf@nemi.mork.no>
> Robert Dobrowolski <robert.dobrowolski@linux.intel.com> writes:
>
>> From: Rafal Redzimski <rafal.f.redzimski@intel.com>
>>
>> Current implementation updates the mtu size and notify cdc_ncm
>> device using USB_CDC_SET_MAX_DATAGRAM_SIZE request about datagram
>> size change instead of changing rx_urb_size.
>>
>> Whenever mtu is being changed, datagram size should also be
>> updated.
>
> Definitely! Thanks for this. But looking at the code I believe you
> need to fix the calculation of maxmtu too. It is currently:
>
> int maxmtu = ctx->max_datagram_size - cdc_ncm_eth_hlen(dev);
>
> And cdc_ncm_set_dgram_size() updates ctx->max_datagram_size with the new
> mtu, meaning that you can only reduce the mtu. We should probably use
> cdc_ncm_max_dgram_size() instead here.
>
> And cdc_ncm_set_dgram_size() takes the datagram size with header as
> input (ref the above maxmtu calucalution), so it probably needs to
> called as
>
> cdc_ncm_set_dgram_size(dev, new_mtu + cdc_ncm_eth_hlen(dev));
>
> to get it right. I think. None of this is tested on an actual device
> yet... Care to test if I'm right, and do a v2 if necessry?
>
>> Cc: <stable@vger.kernel.org>
>
> This should be dropped for net. Ask David to queue it for stable
> instead. I usually do that by using a subject prefix like
>
> [PATCH net,stable v1] ...
>
>
>
>
> Bjørn
>
ok, thanks for feedback I will send v2 patch
^ permalink raw reply
* veth produces martians after pushing veth into ns
From: Shaun Crampton @ 2016-04-11 10:46 UTC (permalink / raw)
To: netdev@vger.kernel.org
Hi,
I'd appreciate if you could CC me on any responses.
I'm trying to push a veth into a namespace and then give it an IP address
and a default route. The procedure that I have works fine at low scale,
but once I have ~100 veths on a moderately-loaded system, I start seeing
1s delays before processes in a namespace with a new veth can send
traffic. The delays correspond with martian packet logs in the kernel log
so it's like the IP or route update hasn't taken effect yet and it's
trying to send packets with the wrong source.
My procedure looks like this:
# Outside the container, create a veth.
ip link add <vethname> type veth
ip link set <vethname> up
sleep 1 # This bypasses the (probably unrelated) 1s link-status timer in
the kernel.
# Push veth into container.
ip link set <vethname> netns <nsname>
# Inside the container, rename the veth, add IP addr and default route.
ip netns exec <nsname> ip link set <vethname> eth0
ip netns exec <nsname> ip link set <vethname> up
ip netns exec <nsname> ip addr add <ipaddr>
ip netns exec <nsname> ip route replace <hostaddr> dev eth0
ip netns exec <nsname> ip route replace default via <hostaddr> dev eth0
# Actually start the target program in the namespace.
ip netns exec <nsname> <executable to run>
Process tries to send UDP packets to a remote IP, first packet is dropped
with a martian warning on the host. The source address for the martian is
the host's IP address so it appears that there's a window where the
namespace thinks it has the wrong IP, even though the ip route commands
completed before I exec the test program in the namespace. After
(exactly) 1s, packets start flowing with correct source address.
Given that this only happens under load, I suspect that there's some async
processing going on that hasn't finished when the "ip route" commands
return. Or, perhaps the veth has a routing or ARP cache that I need to
clear when I push it into the namespace.
I tried adding these calls after the "ip route replace"s:
ip netns exec <nsname> ip addr
ip netns exec <nsname> ip route
They both show the expected new IP/routes. Adding those commands seems to
improve the success rate (presumably because it effectively adds a small
sleep before the exec).
Can anyone suggest a good way to make sure that my script blocks until the
IPs and routes really are in place and active (or any caches I should be
clearing to avoid this issue)?
I'm running this kernel:
Linux smc-host-0015 3.19.0-28-generic #30-Ubuntu SMP Mon Aug 31 15:52:51
UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
Thanks,
-Shaun
^ permalink raw reply
* Re: [RFC v5 0/5] Add virtio transport for AF_VSOCK
From: Stefan Hajnoczi @ 2016-04-11 10:45 UTC (permalink / raw)
To: Ian Campbell
Cc: marius vlad, Stefan Hajnoczi, kvm, Michael S. Tsirkin, netdev,
virtualization, Claudio Imbrenda, Matt Benjamin, Greg Kurz,
Christoffer Dall
In-Reply-To: <1460129705.1749.25.camel@docker.com>
[-- Attachment #1.1: Type: text/plain, Size: 2801 bytes --]
On Fri, Apr 08, 2016 at 04:35:05PM +0100, Ian Campbell wrote:
> On Fri, 2016-04-01 at 15:23 +0100, Stefan Hajnoczi wrote:
> > This series is based on Michael Tsirkin's vhost branch (v4.5-rc6).
> >
> > I'm about to process Claudio Imbrenda's locking fixes for virtio-vsock but
> > first I want to share the latest version of the code. Several people are
> > playing with vsock now so sharing the latest code should avoid duplicate work.
>
> Thanks for this, I've been using it in my project and it mostly seems
> fine.
>
> One wrinkle I came across, which I'm not sure if it is by design or a
> problem is that I can see this sequence coming from the guest (with
> other activity in between):
>
> 1) OP_SHUTDOWN w/ flags == SHUTDOWN_RX
> 2) OP_SHUTDOWN w/ flags == SHUTDOWN_TX
> 3) OP_SHUTDOWN w/ flags == SHUTDOWN_TX|SHUTDOWN_RX
>
> I orignally had my backend close things down at #2, however this meant
> that when #3 arrived it was for a non-existent socket (or, worse, an
> active one if the ports got reused). I checked v5 of the spec
> proposal[0] which says:
> If these bits are set and there are no more virtqueue buffers
> pending the socket is disconnected.
>
> but I'm not entirely sure if this behaviour contradicts this or not
> (the bits have both been set at #2, but not at the same time).
>
> BTW, how does one tell if there are no more virtqueue buffers pending
> or not while processing the op?
#2 is odd. The shutdown bits are sticky so they cannot be cleared once
set. I would have expected just #1 and #3. The behavior you observe
look like a bug.
The spec text does not convey the meaning of OP_SHUTDOWN well.
OP_SHUTDOWN SHUTDOWN_TX|SHUTDOWN_RX means no further rx/tx is possible
for this connection. "there are no more virtqueue buffers pending the
socket" really means that this isn't an immediate close from the
perspective of the application. If the application still has unread rx
buffers then the socket stays readable until the rx data has been fully
read.
> Another thing I noticed, which is really more to do with the generic
> AF_VSOCK bits than anything to do with your patches is that there is no
> limitations on which vsock ports a non-privileged user can bind to and
> relatedly that there is no netns support so e.g. users in unproivileged
> containers can bind to any vsock port and talk to the host, which might
> be undesirable. For my use for now I just went with the big hammer
> approach of denying access from anything other than init_net
> namespace[1] while I consider what the right answer is.
From the vhost point of view each netns should have its own AF_VSOCK
namespace. This way two containers could act as "the host" (CID 2) for
their respective guests.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* [PATCH] net: fjes: Use resource_size
From: Vaishali Thakkar @ 2016-04-11 10:28 UTC (permalink / raw)
To: izumi.taku; +Cc: davem, netdev, linux-kernel, Vaishali Thakkar
Use the function resource_size instead of explicit computation.
Problem found using Coccinelle.
Signed-off-by: Vaishali Thakkar <vaishali.thakkar@oracle.com>
---
drivers/net/fjes/fjes_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/fjes/fjes_main.c b/drivers/net/fjes/fjes_main.c
index 0ddb54f..061b4af 100644
--- a/drivers/net/fjes/fjes_main.c
+++ b/drivers/net/fjes/fjes_main.c
@@ -1129,7 +1129,7 @@ static int fjes_probe(struct platform_device *plat_dev)
res = platform_get_resource(plat_dev, IORESOURCE_MEM, 0);
hw->hw_res.start = res->start;
- hw->hw_res.size = res->end - res->start + 1;
+ hw->hw_res.size = resource_size(res);
hw->hw_res.irq = platform_get_irq(plat_dev, 0);
err = fjes_hw_init(&adapter->hw);
if (err)
--
2.1.4
^ permalink raw reply related
* Re: Inconsistent use of size argument in kzalloc and memcpy in 'drivers/net/ethernet/toshiba/ps3_gelic_wireless.c'
From: Dan Carpenter @ 2016-04-11 10:26 UTC (permalink / raw)
To: Christophe JAILLET; +Cc: geoff, netdev, linuxppc-dev, kernel-janitors
In-Reply-To: <570B75A4.5070904@wanadoo.fr>
On Mon, Apr 11, 2016 at 12:00:04PM +0200, Christophe JAILLET wrote:
> Hi,
>
> while looking at potential clean-up, I ended on the following code
> which looks spurious to me.
>
> We allocate 'be16_to_cpu(scan_info->size)' bytes, but then copy
> 'scan_info->size'.
> This is not consistent.
>
Good catch. be16_to_cpu(scan_info->size) is correct. It's surprising
that this bug wasn't caught in testing...
regards,
dan carpenter
^ permalink raw reply
* Re: Inconsistent use of size argument in kzalloc and memcpy in 'drivers/net/ethernet/toshiba/ps3_gelic_wireless.c'
From: walter harms @ 2016-04-11 10:04 UTC (permalink / raw)
To: Christophe JAILLET; +Cc: geoff, netdev, linuxppc-dev, kernel-janitors
In-Reply-To: <570B75A4.5070904@wanadoo.fr>
this is a case for kmemdup().
target->hwinfo=kmemdup(scan_info,be16_to_cpu(scan_info->size), GFP_KERNEL);
re,
wh
Am 11.04.2016 12:00, schrieb Christophe JAILLET:
> Hi,
>
> while looking at potential clean-up, I ended on the following code which
> looks spurious to me.
>
> We allocate 'be16_to_cpu(scan_info->size)' bytes, but then copy
> 'scan_info->size'.
> This is not consistent.
>
>
> I don't know which one is the correct one.
>
>
> CJ
>
> --- drivers/net/ethernet/toshiba/ps3_gelic_wireless.c
> +++ /tmp/cocci-output-24201-0dddbd-ps3_gelic_wireless.c
> @@ -1616,13 +1616,10 @@ static void gelic_wl_scan_complete_event
> target->valid = 1;
> target->eurus_index = i;
> kfree(target->hwinfo);
> - target->hwinfo = kzalloc(be16_to_cpu(scan_info->size),
> - GFP_KERNEL);
> if (!target->hwinfo)
> continue;
>
> /* copy hw scan info */
> - memcpy(target->hwinfo, scan_info, scan_info->size);
> target->essid_len = strnlen(scan_info->essid,
> sizeof(scan_info->essid));
> target->rate_len = 0;
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> kernel-janitors" 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
* Inconsistent use of size argument in kzalloc and memcpy in 'drivers/net/ethernet/toshiba/ps3_gelic_wireless.c'
From: Christophe JAILLET @ 2016-04-11 10:00 UTC (permalink / raw)
To: geoff, netdev, linuxppc-dev, kernel-janitors
Hi,
while looking at potential clean-up, I ended on the following code which
looks spurious to me.
We allocate 'be16_to_cpu(scan_info->size)' bytes, but then copy
'scan_info->size'.
This is not consistent.
I don't know which one is the correct one.
CJ
--- drivers/net/ethernet/toshiba/ps3_gelic_wireless.c
+++ /tmp/cocci-output-24201-0dddbd-ps3_gelic_wireless.c
@@ -1616,13 +1616,10 @@ static void gelic_wl_scan_complete_event
target->valid = 1;
target->eurus_index = i;
kfree(target->hwinfo);
- target->hwinfo = kzalloc(be16_to_cpu(scan_info->size),
- GFP_KERNEL);
if (!target->hwinfo)
continue;
/* copy hw scan info */
- memcpy(target->hwinfo, scan_info, scan_info->size);
target->essid_len = strnlen(scan_info->essid,
sizeof(scan_info->essid));
target->rate_len = 0;
^ permalink raw reply
* Re: [PATCH net] packet: fix heap info leak in PACKET_DIAG_MCLIST sock_diag interface
From: Pavel Emelyanov @ 2016-04-11 8:58 UTC (permalink / raw)
To: Mathias Krause, David S. Miller; +Cc: netdev, Eric W. Biederman
In-Reply-To: <1460285548-832-1-git-send-email-minipli@googlemail.com>
On 04/10/2016 01:52 PM, Mathias Krause wrote:
> Because we miss to wipe the remainder of i->addr[] in packet_mc_add(),
> pdiag_put_mclist() leaks uninitialized heap bytes via the
> PACKET_DIAG_MCLIST netlink attribute.
>
> Fix this by explicitly memset(0)ing the remaining bytes in i->addr[].
>
> Fixes: eea68e2f1a00 ("packet: Report socket mclist info via diag module")
> Signed-off-by: Mathias Krause <minipli@googlemail.com>
> Cc: Eric W. Biederman <ebiederm@xmission.com>
> Cc: Pavel Emelyanov <xemul@parallels.com>
Acked-by: Pavel Emelyanov <xemul@virtuozzo.com>
^ permalink raw reply
* Re: [Lsf-pc] [LSF/MM TOPIC] Generic page-pool recycle facility?
From: Mel Gorman @ 2016-04-11 8:58 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: lsf, linux-mm, netdev@vger.kernel.org, Brenden Blanco,
James Bottomley, Tom Herbert, lsf-pc, Alexei Starovoitov
In-Reply-To: <20160407161715.52635cac@redhat.com>
On Thu, Apr 07, 2016 at 04:17:15PM +0200, Jesper Dangaard Brouer wrote:
> (Topic proposal for MM-summit)
>
> Network Interface Cards (NIC) drivers, and increasing speeds stress
> the page-allocator (and DMA APIs). A number of driver specific
> open-coded approaches exists that work-around these bottlenecks in the
> page allocator and DMA APIs. E.g. open-coded recycle mechanisms, and
> allocating larger pages and handing-out page "fragments".
>
> I'm proposing a generic page-pool recycle facility, that can cover the
> driver use-cases, increase performance and open up for zero-copy RX.
>
Which bottleneck dominates -- the page allocator or the DMA API when
setting up coherent pages?
I'm wary of another page allocator API being introduced if it's for
performance reasons. In response to this thread, I spent two days on
a series that boosts performance of the allocator in the fast paths by
11-18% to illustrate that there was low-hanging fruit for optimising. If
the one-LRU-per-node series was applied on top, there would be a further
boost to performance on the allocation side. It could be further boosted
if debugging checks and statistic updates were conditionally disabled by
the caller.
The main reason another allocator concerns me is that those pages
are effectively pinned and cannot be reclaimed by the VM in low memory
situations. It ends up needing its own API for tuning the size and hoping
all the drivers get it right without causing OOM situations. It becomes
a slippery slope of introducing shrinkers, locking and complexity. Then
callers start getting concerned about NUMA locality and having to deal
with multiple lists to maintain performance. Ultimately, it ends up being
as slow as the page allocator and back to square 1 except now with more code.
If it's the DMA API that dominates then something may be required but it
should rely on the existing page allocator to alloc/free from. It would
also need something like drain_all_pages to force free everything in there
in low memory situations. Remember that multiple instances private to
drivers or tasks will require shrinker implementations and the complexity
may get unwieldly.
--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 0/2] drivers: net: cpsw: fix ale calls and drop host_port field from cpsw_priv
From: Mugunthan V N @ 2016-04-11 8:36 UTC (permalink / raw)
To: Grygorii Strashko, David S. Miller, netdev
Cc: Sekhar Nori, linux-kernel, linux-omap
In-Reply-To: <1460031404-28594-1-git-send-email-grygorii.strashko@ti.com>
On Thursday 07 April 2016 05:46 PM, Grygorii Strashko wrote:
> This clean up series intended to:
> - fix port_mask parameters in ale calls and drop unnecessary shifts
> - drop host_port field from struct cpsw_priv
>
> Nothing critical. Tested on am437x-idk-evm in dual mac and switch modes.
>
> Grygorii Strashko (2):
> drivers: net: cpsw: fix port_mask parameters in ale calls
> drivers: net: cpsw: drop host_port field from struct cpsw_priv
>
> drivers/net/ethernet/ti/cpsw.c | 52 +++++++++++++++++-------------------------
> 1 file changed, 21 insertions(+), 31 deletions(-)
>
Reviewed-by: Mugunthan V N <mugunthanvnm@ti.com>
Regards
Mugunthan V N
^ permalink raw reply
* Re: [PATCH] can: mcp251x: Replace create_freezable_workqueue with alloc_workqueue
From: Marc Kleine-Budde @ 2016-04-11 8:35 UTC (permalink / raw)
To: Amitoj Kaur Chawla, wg, linux-can, netdev, linux-kernel; +Cc: tj
In-Reply-To: <20160408153210.GA15068@amitoj-Inspiron-3542>
[-- Attachment #1.1: Type: text/plain, Size: 983 bytes --]
On 04/08/2016 05:32 PM, Amitoj Kaur Chawla wrote:
> Replace scheduled to be removed create_freezable_workqueue with
> alloc_workqueue.
>
> priv->wq should be explicitly set as freezable to ensure it is frozen
> in the suspend sequence and work items are drained so that no new work
> item starts execution until thawed. Thus, use of WQ_FREEZABLE flag
> here is required.
>
> WQ_MEM_RECLAIM flag has been set here to ensure forward progress
> regardless of memory pressure.
>
> The order of execution is not important so set @max_active as 0.
>
> Signed-off-by: Amitoj Kaur Chawla <amitoj1606@gmail.com>
> Acked-by: Tejun Heo <tj@kernel.org>
Applied to can-next/master.
Tnx,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* [PATCH net-next 11/11] fjes: Update fjes driver version : 1.1
From: Taku Izumi @ 2016-04-11 8:10 UTC (permalink / raw)
To: davem, netdev; +Cc: Taku Izumi
In-Reply-To: <1460362136-14968-1-git-send-email-izumi.taku@jp.fujitsu.com>
Signed-off-by: Taku Izumi <izumi.taku@jp.fujitsu.com>
---
drivers/net/fjes/fjes_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/fjes/fjes_main.c b/drivers/net/fjes/fjes_main.c
index 22bd175..bfd58cc 100644
--- a/drivers/net/fjes/fjes_main.c
+++ b/drivers/net/fjes/fjes_main.c
@@ -30,7 +30,7 @@
#include "fjes_ioctl.h"
#define MAJ 1
-#define MIN 0
+#define MIN 1
#define DRV_VERSION __stringify(MAJ) "." __stringify(MIN)
#define DRV_NAME "fjes"
char fjes_driver_name[] = DRV_NAME;
--
2.4.3
^ permalink raw reply related
* [PATCH net-next 10/11] fjes: Introduce spinlock for rx_status
From: Taku Izumi @ 2016-04-11 8:10 UTC (permalink / raw)
To: davem, netdev; +Cc: Taku Izumi
In-Reply-To: <1460362136-14968-1-git-send-email-izumi.taku@jp.fujitsu.com>
This patch introduces spinlock of rx_status for
proper excusive control.
Signed-off-by: Taku Izumi <izumi.taku@jp.fujitsu.com>
---
drivers/net/fjes/fjes_hw.c | 22 ++++++++++++++++-
drivers/net/fjes/fjes_hw.h | 2 ++
drivers/net/fjes/fjes_main.c | 57 +++++++++++++++++++++++++++++++++++++-------
3 files changed, 72 insertions(+), 9 deletions(-)
diff --git a/drivers/net/fjes/fjes_hw.c b/drivers/net/fjes/fjes_hw.c
index 4861e36..79599d0 100644
--- a/drivers/net/fjes/fjes_hw.c
+++ b/drivers/net/fjes/fjes_hw.c
@@ -216,6 +216,7 @@ static int fjes_hw_setup(struct fjes_hw *hw)
u8 mac[ETH_ALEN] = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };
struct fjes_device_command_param param;
struct ep_share_mem_info *buf_pair;
+ unsigned long flags;
size_t mem_size;
int result;
int epidx;
@@ -264,10 +265,12 @@ static int fjes_hw_setup(struct fjes_hw *hw)
if (result)
return result;
+ spin_lock_irqsave(&hw->rx_status_lock, flags);
fjes_hw_setup_epbuf(&buf_pair->tx, mac,
fjes_support_mtu[0]);
fjes_hw_setup_epbuf(&buf_pair->rx, mac,
fjes_support_mtu[0]);
+ spin_unlock_irqrestore(&hw->rx_status_lock, flags);
}
}
@@ -329,6 +332,7 @@ int fjes_hw_init(struct fjes_hw *hw)
INIT_WORK(&hw->epstop_task, fjes_hw_epstop_task);
mutex_init(&hw->hw_info.lock);
+ spin_lock_init(&hw->rx_status_lock);
hw->max_epid = fjes_hw_get_max_epid(hw);
hw->my_epid = fjes_hw_get_my_epid(hw);
@@ -736,6 +740,7 @@ fjes_hw_get_partner_ep_status(struct fjes_hw *hw, int epid)
void fjes_hw_raise_epstop(struct fjes_hw *hw)
{
enum ep_partner_status status;
+ unsigned long flags;
int epidx;
for (epidx = 0; epidx < hw->max_epid; epidx++) {
@@ -756,8 +761,10 @@ void fjes_hw_raise_epstop(struct fjes_hw *hw)
set_bit(epidx, &hw->hw_info.buffer_unshare_reserve_bit);
set_bit(epidx, &hw->txrx_stop_req_bit);
+ spin_lock_irqsave(&hw->rx_status_lock, flags);
hw->ep_shm_info[epidx].tx.info->v1i.rx_status |=
FJES_RX_STOP_REQ_REQUEST;
+ spin_unlock_irqrestore(&hw->rx_status_lock, flags);
}
}
@@ -939,6 +946,7 @@ static void fjes_hw_update_zone_task(struct work_struct *work)
struct fjes_adapter *adapter;
struct net_device *netdev;
+ unsigned long flags;
ulong unshare_bit = 0;
ulong share_bit = 0;
@@ -1031,8 +1039,10 @@ static void fjes_hw_update_zone_task(struct work_struct *work)
continue;
if (test_bit(epidx, &share_bit)) {
+ spin_lock_irqsave(&hw->rx_status_lock, flags);
fjes_hw_setup_epbuf(&hw->ep_shm_info[epidx].tx,
netdev->dev_addr, netdev->mtu);
+ spin_unlock_irqrestore(&hw->rx_status_lock, flags);
mutex_lock(&hw->hw_info.lock);
@@ -1082,10 +1092,14 @@ static void fjes_hw_update_zone_task(struct work_struct *work)
hw->ep_shm_info[epidx].ep_stats
.command_unregister_buffer_executed += 1;
- if (ret == 0)
+ if (ret == 0) {
+ spin_lock_irqsave(&hw->rx_status_lock, flags);
fjes_hw_setup_epbuf(
&hw->ep_shm_info[epidx].tx,
netdev->dev_addr, netdev->mtu);
+ spin_unlock_irqrestore(&hw->rx_status_lock,
+ flags);
+ }
}
if (test_bit(epidx, &irq_bit)) {
@@ -1095,9 +1109,11 @@ static void fjes_hw_update_zone_task(struct work_struct *work)
.send_interrupts_unshare += 1;
set_bit(epidx, &hw->txrx_stop_req_bit);
+ spin_lock_irqsave(&hw->rx_status_lock, flags);
hw->ep_shm_info[epidx].tx.
info->v1i.rx_status |=
FJES_RX_STOP_REQ_REQUEST;
+ spin_unlock_irqrestore(&hw->rx_status_lock, flags);
set_bit(epidx, &hw->hw_info.buffer_unshare_reserve_bit);
}
}
@@ -1113,6 +1129,7 @@ static void fjes_hw_epstop_task(struct work_struct *work)
{
struct fjes_hw *hw = container_of(work, struct fjes_hw, epstop_task);
struct fjes_adapter *adapter = (struct fjes_adapter *)hw->back;
+ unsigned long flags;
ulong remain_bit;
int epid_bit;
@@ -1120,9 +1137,12 @@ static void fjes_hw_epstop_task(struct work_struct *work)
while ((remain_bit = hw->epstop_req_bit)) {
for (epid_bit = 0; remain_bit; remain_bit >>= 1, epid_bit++) {
if (remain_bit & 1) {
+ spin_lock_irqsave(&hw->rx_status_lock, flags);
hw->ep_shm_info[epid_bit].
tx.info->v1i.rx_status |=
FJES_RX_STOP_REQ_DONE;
+ spin_unlock_irqrestore(&hw->rx_status_lock,
+ flags);
clear_bit(epid_bit, &hw->epstop_req_bit);
set_bit(epid_bit,
diff --git a/drivers/net/fjes/fjes_hw.h b/drivers/net/fjes/fjes_hw.h
index 66cefd1..ca72474 100644
--- a/drivers/net/fjes/fjes_hw.h
+++ b/drivers/net/fjes/fjes_hw.h
@@ -329,6 +329,8 @@ struct fjes_hw {
bool trace_started;
u32 trace_mode;
+
+ spinlock_t rx_status_lock; /* spinlock for rx_status */
};
int fjes_hw_init(struct fjes_hw *);
diff --git a/drivers/net/fjes/fjes_main.c b/drivers/net/fjes/fjes_main.c
index 8ab0523..22bd175 100644
--- a/drivers/net/fjes/fjes_main.c
+++ b/drivers/net/fjes/fjes_main.c
@@ -293,6 +293,7 @@ static int fjes_close(struct net_device *netdev)
{
struct fjes_adapter *adapter = netdev_priv(netdev);
struct fjes_hw *hw = &adapter->hw;
+ unsigned long flags;
int epidx;
netif_tx_stop_all_queues(netdev);
@@ -302,13 +303,18 @@ static int fjes_close(struct net_device *netdev)
napi_disable(&adapter->napi);
+ spin_lock_irqsave(&hw->rx_status_lock, flags);
for (epidx = 0; epidx < hw->max_epid; epidx++) {
if (epidx == hw->my_epid)
continue;
- adapter->hw.ep_shm_info[epidx].tx.info->v1i.rx_status &=
- ~FJES_RX_POLL_WORK;
+ if (fjes_hw_get_partner_ep_status(hw, epidx) ==
+ EP_PARTNER_SHARED)
+ adapter->hw.ep_shm_info[epidx]
+ .tx.info->v1i.rx_status &=
+ ~FJES_RX_POLL_WORK;
}
+ spin_unlock_irqrestore(&hw->rx_status_lock, flags);
fjes_free_irq(adapter);
@@ -333,6 +339,7 @@ static int fjes_setup_resources(struct fjes_adapter *adapter)
struct net_device *netdev = adapter->netdev;
struct ep_share_mem_info *buf_pair;
struct fjes_hw *hw = &adapter->hw;
+ unsigned long flags;
int result;
int epidx;
@@ -376,8 +383,10 @@ static int fjes_setup_resources(struct fjes_adapter *adapter)
buf_pair = &hw->ep_shm_info[epidx];
+ spin_lock_irqsave(&hw->rx_status_lock, flags);
fjes_hw_setup_epbuf(&buf_pair->tx, netdev->dev_addr,
netdev->mtu);
+ spin_unlock_irqrestore(&hw->rx_status_lock, flags);
if (fjes_hw_epid_is_same_zone(hw, epidx)) {
mutex_lock(&hw->hw_info.lock);
@@ -410,6 +419,7 @@ static void fjes_free_resources(struct fjes_adapter *adapter)
struct ep_share_mem_info *buf_pair;
struct fjes_hw *hw = &adapter->hw;
bool reset_flag = false;
+ unsigned long flags;
int result;
int epidx;
@@ -429,8 +439,10 @@ static void fjes_free_resources(struct fjes_adapter *adapter)
buf_pair = &hw->ep_shm_info[epidx];
+ spin_lock_irqsave(&hw->rx_status_lock, flags);
fjes_hw_setup_epbuf(&buf_pair->tx,
netdev->dev_addr, netdev->mtu);
+ spin_unlock_irqrestore(&hw->rx_status_lock, flags);
clear_bit(epidx, &hw->txrx_stop_req_bit);
}
@@ -789,6 +801,7 @@ static int fjes_change_mtu(struct net_device *netdev, int new_mtu)
struct fjes_adapter *adapter = netdev_priv(netdev);
bool running = netif_running(netdev);
struct fjes_hw *hw = &adapter->hw;
+ unsigned long flags;
int ret = -EINVAL;
int idx, epidx;
@@ -807,12 +820,15 @@ static int fjes_change_mtu(struct net_device *netdev, int new_mtu)
return ret;
if (running) {
+ spin_lock_irqsave(&hw->rx_status_lock, flags);
for (epidx = 0; epidx < hw->max_epid; epidx++) {
if (epidx == hw->my_epid)
continue;
hw->ep_shm_info[epidx].tx.info->v1i.rx_status &=
~FJES_RX_MTU_CHANGING_DONE;
}
+ spin_unlock_irqrestore(&hw->rx_status_lock, flags);
+
netif_tx_stop_all_queues(netdev);
netif_carrier_off(netdev);
cancel_work_sync(&adapter->tx_stall_task);
@@ -826,23 +842,25 @@ static int fjes_change_mtu(struct net_device *netdev, int new_mtu)
netdev->mtu = new_mtu;
if (running) {
+ spin_lock_irqsave(&hw->rx_status_lock, flags);
for (epidx = 0; epidx < hw->max_epid; epidx++) {
if (epidx == hw->my_epid)
continue;
- local_irq_disable();
+ spin_lock_irqsave(&hw->rx_status_lock, flags);
fjes_hw_setup_epbuf(&hw->ep_shm_info[epidx].tx,
netdev->dev_addr,
netdev->mtu);
- local_irq_enable();
hw->ep_shm_info[epidx].tx.info->v1i.rx_status |=
FJES_RX_MTU_CHANGING_DONE;
+ spin_unlock_irqrestore(&hw->rx_status_lock, flags);
}
netif_tx_wake_all_queues(netdev);
netif_carrier_on(netdev);
napi_enable(&adapter->napi);
+ napi_schedule(&adapter->napi);
}
return ret;
@@ -1096,6 +1114,7 @@ static void fjes_txrx_stop_req_irq(struct fjes_adapter *adapter,
{
struct fjes_hw *hw = &adapter->hw;
enum ep_partner_status status;
+ unsigned long flags;
status = fjes_hw_get_partner_ep_status(hw, src_epid);
switch (status) {
@@ -1105,8 +1124,10 @@ static void fjes_txrx_stop_req_irq(struct fjes_adapter *adapter,
break;
case EP_PARTNER_WAITING:
if (src_epid < hw->my_epid) {
+ spin_lock_irqsave(&hw->rx_status_lock, flags);
hw->ep_shm_info[src_epid].tx.info->v1i.rx_status |=
FJES_RX_STOP_REQ_DONE;
+ spin_unlock_irqrestore(&hw->rx_status_lock, flags);
clear_bit(src_epid, &hw->txrx_stop_req_bit);
set_bit(src_epid, &adapter->unshare_watch_bitmask);
@@ -1132,14 +1153,17 @@ static void fjes_stop_req_irq(struct fjes_adapter *adapter, int src_epid)
{
struct fjes_hw *hw = &adapter->hw;
enum ep_partner_status status;
+ unsigned long flags;
set_bit(src_epid, &hw->hw_info.buffer_unshare_reserve_bit);
status = fjes_hw_get_partner_ep_status(hw, src_epid);
switch (status) {
case EP_PARTNER_WAITING:
+ spin_lock_irqsave(&hw->rx_status_lock, flags);
hw->ep_shm_info[src_epid].tx.info->v1i.rx_status |=
FJES_RX_STOP_REQ_DONE;
+ spin_unlock_irqrestore(&hw->rx_status_lock, flags);
clear_bit(src_epid, &hw->txrx_stop_req_bit);
/* fall through */
case EP_PARTNER_UNSHARE:
@@ -1284,13 +1308,17 @@ static int fjes_poll(struct napi_struct *napi, int budget)
size_t frame_len;
void *frame;
+ spin_lock(&hw->rx_status_lock);
for (epidx = 0; epidx < hw->max_epid; epidx++) {
if (epidx == hw->my_epid)
continue;
- adapter->hw.ep_shm_info[epidx].tx.info->v1i.rx_status |=
- FJES_RX_POLL_WORK;
+ if (fjes_hw_get_partner_ep_status(hw, epidx) ==
+ EP_PARTNER_SHARED)
+ adapter->hw.ep_shm_info[epidx]
+ .tx.info->v1i.rx_status |= FJES_RX_POLL_WORK;
}
+ spin_unlock(&hw->rx_status_lock);
while (work_done < budget) {
prefetch(&adapter->hw);
@@ -1348,13 +1376,17 @@ static int fjes_poll(struct napi_struct *napi, int budget)
if (((long)jiffies - (long)adapter->rx_last_jiffies) < 3) {
napi_reschedule(napi);
} else {
+ spin_lock(&hw->rx_status_lock);
for (epidx = 0; epidx < hw->max_epid; epidx++) {
if (epidx == hw->my_epid)
continue;
- adapter->hw.ep_shm_info[epidx]
- .tx.info->v1i.rx_status &=
+ if (fjes_hw_get_partner_ep_status(hw, epidx) ==
+ EP_PARTNER_SHARED)
+ adapter->hw.ep_shm_info[epidx].tx
+ .info->v1i.rx_status &=
~FJES_RX_POLL_WORK;
}
+ spin_unlock(&hw->rx_status_lock);
fjes_hw_set_irqmask(hw, REG_ICTL_MASK_RX_DATA, false);
}
@@ -1527,6 +1559,7 @@ static void fjes_watch_unshare_task(struct work_struct *work)
int max_epid, my_epid, epidx;
int stop_req, stop_req_done;
ulong unshare_watch_bitmask;
+ unsigned long flags;
int wait_time = 0;
int is_shared;
int ret;
@@ -1582,8 +1615,10 @@ static void fjes_watch_unshare_task(struct work_struct *work)
hw->ep_shm_info[epidx].ep_stats
.command_unregister_buffer_executed += 1;
+ spin_lock_irqsave(&hw->rx_status_lock, flags);
fjes_hw_setup_epbuf(&hw->ep_shm_info[epidx].tx,
netdev->dev_addr, netdev->mtu);
+ spin_unlock_irqrestore(&hw->rx_status_lock, flags);
clear_bit(epidx, &hw->txrx_stop_req_bit);
clear_bit(epidx, &unshare_watch_bitmask);
@@ -1624,9 +1659,12 @@ static void fjes_watch_unshare_task(struct work_struct *work)
hw->ep_shm_info[epidx].ep_stats
.command_unregister_buffer_executed += 1;
+ spin_lock_irqsave(&hw->rx_status_lock, flags);
fjes_hw_setup_epbuf(
&hw->ep_shm_info[epidx].tx,
netdev->dev_addr, netdev->mtu);
+ spin_unlock_irqrestore(&hw->rx_status_lock,
+ flags);
clear_bit(epidx, &hw->txrx_stop_req_bit);
clear_bit(epidx, &unshare_watch_bitmask);
@@ -1634,8 +1672,11 @@ static void fjes_watch_unshare_task(struct work_struct *work)
}
if (test_bit(epidx, &unshare_watch_bitmask)) {
+ spin_lock_irqsave(&hw->rx_status_lock, flags);
hw->ep_shm_info[epidx].tx.info->v1i.rx_status &=
~FJES_RX_STOP_REQ_DONE;
+ spin_unlock_irqrestore(&hw->rx_status_lock,
+ flags);
}
}
}
--
2.4.3
^ permalink raw reply related
* [PATCH net-next 08/11] fjes: fix bitwise check bug in fjes_raise_intr_rxdata_task
From: Taku Izumi @ 2016-04-11 8:10 UTC (permalink / raw)
To: davem, netdev; +Cc: Taku Izumi
In-Reply-To: <1460362136-14968-1-git-send-email-izumi.taku@jp.fujitsu.com>
In fjes_raise_intr_rxdata_task(), there's a bug of bitwise
check because of missing "& FJES_RX_POLL_WORK".
This patch fixes this bug.
Signed-off-by: Taku Izumi <izumi.taku@jp.fujitsu.com>
---
drivers/net/fjes/fjes_main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/fjes/fjes_main.c b/drivers/net/fjes/fjes_main.c
index e785d89..8c7a8b0 100644
--- a/drivers/net/fjes/fjes_main.c
+++ b/drivers/net/fjes/fjes_main.c
@@ -560,7 +560,8 @@ static void fjes_raise_intr_rxdata_task(struct work_struct *work)
if ((hw->ep_shm_info[epid].tx_status_work ==
FJES_TX_DELAY_SEND_PENDING) &&
(pstatus == EP_PARTNER_SHARED) &&
- !(hw->ep_shm_info[epid].rx.info->v1i.rx_status)) {
+ !(hw->ep_shm_info[epid].rx.info->v1i.rx_status &
+ FJES_RX_POLL_WORK)) {
fjes_hw_raise_interrupt(hw, epid,
REG_ICTL_MASK_RX_DATA);
hw->ep_shm_info[epid].ep_stats.send_interrupts_rx += 1;
--
2.4.3
^ permalink raw reply related
* [PATCH net-next 09/11] fjes: Enhance changing MTU related work
From: Taku Izumi @ 2016-04-11 8:10 UTC (permalink / raw)
To: davem, netdev; +Cc: Taku Izumi
In-Reply-To: <1460362136-14968-1-git-send-email-izumi.taku@jp.fujitsu.com>
This patch enhances the fjes_change_mtu() method
by introducing new flag named FJES_RX_MTU_CHANGING_DONE
in rx_status. At the same time, default MTU value is
changed into 65510 bytes.
Signed-off-by: Taku Izumi <izumi.taku@jp.fujitsu.com>
---
drivers/net/fjes/fjes_hw.c | 8 +++++-
drivers/net/fjes/fjes_hw.h | 1 +
drivers/net/fjes/fjes_main.c | 60 ++++++++++++++++++++++++++++++++++++--------
3 files changed, 58 insertions(+), 11 deletions(-)
diff --git a/drivers/net/fjes/fjes_hw.c b/drivers/net/fjes/fjes_hw.c
index b2b11c3..4861e36 100644
--- a/drivers/net/fjes/fjes_hw.c
+++ b/drivers/net/fjes/fjes_hw.c
@@ -179,6 +179,8 @@ void fjes_hw_setup_epbuf(struct epbuf_handler *epbh, u8 *mac_addr, u32 mtu)
for (i = 0; i < EP_BUFFER_SUPPORT_VLAN_MAX; i++)
info->v1i.vlan_id[i] = vlan_id[i];
+
+ info->v1i.rx_status |= FJES_RX_MTU_CHANGING_DONE;
}
void
@@ -811,7 +813,8 @@ bool fjes_hw_check_mtu(struct epbuf_handler *epbh, u32 mtu)
{
union ep_buffer_info *info = epbh->info;
- return (info->v1i.frame_max == FJES_MTU_TO_FRAME_SIZE(mtu));
+ return ((info->v1i.frame_max == FJES_MTU_TO_FRAME_SIZE(mtu)) &&
+ info->v1i.rx_status & FJES_RX_MTU_CHANGING_DONE);
}
bool fjes_hw_check_vlan_id(struct epbuf_handler *epbh, u16 vlan_id)
@@ -864,6 +867,9 @@ bool fjes_hw_epbuf_rx_is_empty(struct epbuf_handler *epbh)
{
union ep_buffer_info *info = epbh->info;
+ if (!(info->v1i.rx_status & FJES_RX_MTU_CHANGING_DONE))
+ return true;
+
if (info->v1i.count_max == 0)
return true;
diff --git a/drivers/net/fjes/fjes_hw.h b/drivers/net/fjes/fjes_hw.h
index a1c3d65..66cefd1 100644
--- a/drivers/net/fjes/fjes_hw.h
+++ b/drivers/net/fjes/fjes_hw.h
@@ -58,6 +58,7 @@ struct fjes_hw;
#define FJES_RX_STOP_REQ_DONE (0x1)
#define FJES_RX_STOP_REQ_REQUEST (0x2)
#define FJES_RX_POLL_WORK (0x4)
+#define FJES_RX_MTU_CHANGING_DONE (0x8)
#define EP_BUFFER_SIZE \
(((sizeof(union ep_buffer_info) + (128 * (64 * 1024))) \
diff --git a/drivers/net/fjes/fjes_main.c b/drivers/net/fjes/fjes_main.c
index 8c7a8b0..8ab0523 100644
--- a/drivers/net/fjes/fjes_main.c
+++ b/drivers/net/fjes/fjes_main.c
@@ -492,6 +492,9 @@ static void fjes_tx_stall_task(struct work_struct *work)
info = adapter->hw.ep_shm_info[epid].tx.info;
+ if (!(info->v1i.rx_status & FJES_RX_MTU_CHANGING_DONE))
+ return;
+
if (EP_RING_FULL(info->v1i.head, info->v1i.tail,
info->v1i.count_max)) {
all_queue_available = 0;
@@ -783,9 +786,11 @@ fjes_get_stats64(struct net_device *netdev, struct rtnl_link_stats64 *stats)
static int fjes_change_mtu(struct net_device *netdev, int new_mtu)
{
+ struct fjes_adapter *adapter = netdev_priv(netdev);
bool running = netif_running(netdev);
- int ret = 0;
- int idx;
+ struct fjes_hw *hw = &adapter->hw;
+ int ret = -EINVAL;
+ int idx, epidx;
for (idx = 0; fjes_support_mtu[idx] != 0; idx++) {
if (new_mtu <= fjes_support_mtu[idx]) {
@@ -793,19 +798,54 @@ static int fjes_change_mtu(struct net_device *netdev, int new_mtu)
if (new_mtu == netdev->mtu)
return 0;
- if (running)
- fjes_close(netdev);
+ ret = 0;
+ break;
+ }
+ }
+
+ if (ret)
+ return ret;
- netdev->mtu = new_mtu;
+ if (running) {
+ for (epidx = 0; epidx < hw->max_epid; epidx++) {
+ if (epidx == hw->my_epid)
+ continue;
+ hw->ep_shm_info[epidx].tx.info->v1i.rx_status &=
+ ~FJES_RX_MTU_CHANGING_DONE;
+ }
+ netif_tx_stop_all_queues(netdev);
+ netif_carrier_off(netdev);
+ cancel_work_sync(&adapter->tx_stall_task);
+ napi_disable(&adapter->napi);
- if (running)
- ret = fjes_open(netdev);
+ msleep(1000);
- return ret;
+ netif_tx_stop_all_queues(netdev);
+ }
+
+ netdev->mtu = new_mtu;
+
+ if (running) {
+ for (epidx = 0; epidx < hw->max_epid; epidx++) {
+ if (epidx == hw->my_epid)
+ continue;
+
+ local_irq_disable();
+ fjes_hw_setup_epbuf(&hw->ep_shm_info[epidx].tx,
+ netdev->dev_addr,
+ netdev->mtu);
+ local_irq_enable();
+
+ hw->ep_shm_info[epidx].tx.info->v1i.rx_status |=
+ FJES_RX_MTU_CHANGING_DONE;
}
+
+ netif_tx_wake_all_queues(netdev);
+ netif_carrier_on(netdev);
+ napi_enable(&adapter->napi);
}
- return -EINVAL;
+ return ret;
}
static int fjes_vlan_rx_add_vid(struct net_device *netdev,
@@ -1450,7 +1490,7 @@ static void fjes_netdev_setup(struct net_device *netdev)
netdev->watchdog_timeo = FJES_TX_RETRY_INTERVAL;
netdev->netdev_ops = &fjes_netdev_ops;
fjes_set_ethtool_ops(netdev);
- netdev->mtu = fjes_support_mtu[0];
+ netdev->mtu = fjes_support_mtu[3];
netdev->flags |= IFF_BROADCAST;
netdev->features |= NETIF_F_HW_CSUM | NETIF_F_HW_VLAN_CTAG_FILTER;
}
--
2.4.3
^ permalink raw reply related
* [PATCH net-next 06/11] fjes: optimize timeout value
From: Taku Izumi @ 2016-04-11 8:10 UTC (permalink / raw)
To: davem, netdev; +Cc: Taku Izumi
In-Reply-To: <1460362136-14968-1-git-send-email-izumi.taku@jp.fujitsu.com>
This patch optimizes the following timeout value.
- FJES_DEVICE_RESET_TIMEOUT
- FJES_COMMAND_REQ_TIMEOUT
- FJES_COMMAND_REQ_BUFF_TIMEOUT
Signed-off-by: Taku Izumi <izumi.taku@jp.fujitsu.com>
---
drivers/net/fjes/fjes_hw.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/fjes/fjes_hw.h b/drivers/net/fjes/fjes_hw.h
index 41fe418..a1c3d65 100644
--- a/drivers/net/fjes/fjes_hw.h
+++ b/drivers/net/fjes/fjes_hw.h
@@ -34,9 +34,9 @@ struct fjes_hw;
#define EP_BUFFER_INFO_SIZE 4096
#define EP_TRACE_PAGE_SIZE 4096
-#define FJES_DEVICE_RESET_TIMEOUT ((17 + 1) * 3) /* sec */
-#define FJES_COMMAND_REQ_TIMEOUT (5 + 1) /* sec */
-#define FJES_COMMAND_REQ_BUFF_TIMEOUT (8 * 3) /* sec */
+#define FJES_DEVICE_RESET_TIMEOUT ((17 + 1) * 3 * 8) /* sec */
+#define FJES_COMMAND_REQ_TIMEOUT ((5 + 1) * 3 * 8) /* sec */
+#define FJES_COMMAND_REQ_BUFF_TIMEOUT (60 * 3) /* sec */
#define FJES_COMMAND_EPSTOP_WAIT_TIMEOUT (1) /* sec */
#define FJES_CMD_REQ_ERR_INFO_PARAM (0x0001)
--
2.4.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox