OK. I will send V2 for net-next very soon.
Zhu Yanjun
On Mon, Sep 17, 2018 at 6:38 AM David Miller wrote:
>
> From: Zhu Yanjun
> Date: Fri, 14 Sep 2018 04:45:38 -0400
>
> > The function rds_inc_init is in recv process. To use memset can optimize
> > the function rds_inc_init.
> > The test resu
Reviewed-by: Zhu Yanjun
On Wed, Feb 7, 2018 at 3:34 AM, Shannon Nelson
wrote:
> Add the appropriate SPDX license tags to the Sun network drivers
> as outlined in Documentation/process/license-rules.rst.
>
> Signed-off-by: Shannon Nelson
> ---
> drivers/net/ethernet/sun/Kconfig | 1 +
After several week tests, your advice still make this bug appear. But
my patch make this bug disappear.
Zhu Yanjun
On Thu, Nov 17, 2016 at 5:33 PM, zhuyj wrote:
> Sure. From the following.
> "
> VLAN Filter. Each bit ‘i’ in register ‘n’ affects packets with VLAN
> tags equal
Thanks a lot.
When will offset become -1?
On Tue, Nov 29, 2016 at 3:14 PM, Amir Vadai wrote:
> On Tue, Nov 29, 2016 at 10:32:05AM +0800, zhuyj wrote:
>> + if (offset > 0 && offset > skb->len)
>>
>> offset > skb->len is enough?
> offset is
+ if (offset > 0 && offset > skb->len)
offset > skb->len is enough?
On Mon, Nov 28, 2016 at 6:56 PM, Amir Vadai wrote:
> Add a validation function to make sure offset is valid:
> 1. Not below skb head (could happen when offset is negative).
> 2. Validate both 'offset' and 'at'.
>
> Signed
Sure. From the following.
"
VLAN Filter. Each bit ‘i’ in register ‘n’ affects packets with VLAN
tags equal to 32*n+i.
128 VLAN Filter registers compose a table of 4096 bits that cover all
possible VLAN
tags.
Each bit when set, enables packets with the associated VLAN tags to
pass. Each bit
when cle
__attribute__((packed)) is potentially unsafe on some systems. The
symptom probably won't show up on an x86, which just makes the problem
more insidious; testing on x86 systems won't reveal the problem. (On
the x86, misaligned accesses are handled in hardware; if you
dereference an int* pointer th
Soon I will analyze the previous patch. I will let you know.
Thanks a lot.
On Thu, Oct 13, 2016 at 1:28 PM, zhuyj wrote:
> Hi, Jiri
>
> The dumped source code is in the attachment. Please check it. I think
> this file can explain all.
>
> If anything, please just let me kn
Hi, Jiri
How to explain the following source code? As you mentioned, are the
#ifdefs in the following source pointless?
As to the previous patch, I will compile and analyze it. But now I am
busy with something else. After I draw a conclusion, I will let you
know.
Thanks for your reply.
static
+static int e1000_xdp_set(struct net_device *netdev, struct bpf_prog *prog)
+{
+ struct e1000_adapter *adapter = netdev_priv(netdev);
+ struct bpf_prog *old_prog;
+
+ old_prog = xchg(&adapter->prog, prog);
+ if (old_prog) {
+ synchronize_net();
+
how about this patch "ixgbe: remove the useless header file ixgbe_type.h"?
On Tue, Sep 20, 2016 at 1:00 AM, Tantilov, Emil S
wrote:
>>-Original Message-
>>From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On
>>Behalf Of zyjzyj2...@gmail.com
>>Sent: Wednesday, Septem
+ u32 in[MLX5_ST_SZ_DW(dcbx_param)];
+
+ memset(in, 0, sizeof(in));
can we replace the above with "u32 in[MLX5_ST_SZ_DW(dcbx_param)] = {0};"?
On Tue, Aug 30, 2016 at 7:29 PM, Saeed Mahameed wrote:
> From: Huy Nguyen
>
> Add set/query commands for DCBX_PARAM register
>
> Signed-off
+#define DEFAULT_MTU (VIRTIO_VSOCK_MAX_PKT_BUF_SIZE + sizeof(struct
af_vsockmon_hdr));
It is better.
On Sat, Aug 13, 2016 at 6:21 PM, wrote:
> From: Gerard Garcia
>
> Add vsockmon virtual network device that receives packets from the vsock
> transports and exposes them to user space.
>
> Based
Can we check slave_ops->ndo_set_mac_address?
1476 if ((slave_ops->ndo_set_mac_address) &&
(!bond->params.fail_over_mac ||
1477 BOND_MODE(bond) != BOND_MODE_ACTIVEBACKUP)) {
1478 /* Set slave to master's mac address. The
application already
1479 * set the master'
Sure.
Why are preempt_disable and rcu_read_lock used here? is there a great
benefit of dong this?
On Fri, Aug 5, 2016 at 3:05 PM, Sargun Dhillon wrote:
> On Thu, Aug 04, 2016 at 05:34:32PM +0800, zhuyj wrote:
>> Sure.
>> Is it better to add
>> #ifndef CONFIG_PREEMPT_RCU
+ switch (phydev->speed) {
+ case SPEED_1000:
+ val |= BMCR_SPEED1000;
+ case SPEED_100:
+ val |= BMCR_SPEED100;
+ }
Are there only 2 kinds of speed?
On Thu, Aug 4, 2016 at 8:13 PM, Kedareswara rao Appana
wrote:
> This patch adds support for g
Sure.
Is it better to add
#ifndef CONFIG_PREEMPT_RCU ?
On Thu, Aug 4, 2016 at 4:28 PM, Eric Dumazet wrote:
> Please do not top post
>
> On Thu, 2016-08-04 at 16:08 +0800, zhuyj wrote:
>> +void register_checmate_prog_ops(void);
>> maybe it is extern void register_c
+void register_checmate_prog_ops(void);
maybe it is extern void register_checmate_prog_ops(void);?
+ preempt_disable();
+ rcu_read_lock();
IMHO, it is not necessary to use the above 2 since rcu_read_lock will
call preempt_disable.
Zhu Yanjun
On Thu, Aug 4, 2016 at 3:11 PM, Sargun Dh
Sorry.
An inline function will be inserted into the calling function. Why
"Assigning NULL to parmeter dcb has no effect outside of the
inlined function." ?
On Sun, Jul 31, 2016 at 6:07 PM, Heinrich Schuchardt wrote:
> Assigning NULL to parmeter dcb has no effect outside of the
> inlined function.
+ if (vnics > pf->max_rsscos_ctxs || vnics > pf->max_vnics) {
<-Does this happen very rarely? If so,
if (unlikely(vnics > pf->max_rsscos_ctxs || vnics > pf->max_vnics) { is better?
+ netdev_warn(bp->dev,
+ "Not enough resources to support NTUP
Hi, all
Would you like to give me some advice?
Any reply is appreciated.
Zhu Yanjun
On 03/10/2016 10:54 AM, Zhu Yanjun wrote:
Sometimes the system engineer and application expect a new net namespace
to inherit config from the base net config. Sometimes the current net config
is expected by the
ping
On 03/10/2016 10:54 AM, Zhu Yanjun wrote:
Sometimes the system engineer and application expect a new net namespace
to inherit config from the base net config. Sometimes the current net config
is expected by the system engineer and application. So it is necessary that
the system engineer and
Add Alexey Kuznetsov, James Morris, Hideaki YOSHIFUJI and Patrick McHardy
Zhu Yanjun
On 02/29/2016 01:07 PM, yanjun@windriver.com wrote:
From: Zhu Yanjun
Sometimes the system engineer and application expect a new net namespace
to inherit config from the base net config. Sometimes the cur
On 02/29/2016 01:39 PM, Jay Vosburgh wrote:
zhuyj wrote:
On 02/25/2016 09:33 PM, Jay Vosburgh wrote:
zhuyj wrote:
[...]
I delved into the source code and Emil's tests. I think that the problem
that this patch expects to fix occurs very unusually.
Do you agree with me?
If so, mayb
On 02/25/2016 09:33 PM, Jay Vosburgh wrote:
zhuyj wrote:
[...]
I delved into the source code and Emil's tests. I think that the problem
that this patch expects to fix occurs very unusually.
Do you agree with me?
If so, maybe the following patch can reduce the performance loss.
Please co
On 02/09/2016 04:10 AM, Jay Vosburgh wrote:
There is presently a race condition between the bonding periodic
link monitor and the updating of a slave's speed and duplex. The former
occurs on a periodic basis, and the latter in response to a driver's
calling of netif_carrier_on.
On 02/05/2016 08:43 AM, Tantilov, Emil S wrote:
-Original Message-
From: Jay Vosburgh [mailto:jay.vosbu...@canonical.com]
Sent: Thursday, February 04, 2016 4:37 PM
To: Tantilov, Emil S
Cc: netdev@vger.kernel.org; go...@cumulusnetworks.com; zhuyj;
j...@mellanox.com
Subject: Re: bonding
On 02/05/2016 08:37 AM, Jay Vosburgh wrote:
Jay Vosburgh wrote:
[...]
Thinking about the trace again... Emil: what happens in the
trace before this? Is there ever a call to the ixgbe_get_settings?
Does a NETDEV_UP or NETDEV_CHANGE event ever hit the bond_netdev_event
function?
On 02/04/2016 01:57 PM, Jay Vosburgh wrote:
Tantilov, Emil S wrote:
We are seeing an occasional issue where the bonding driver may report interface
up with 0 Mbps:
bond0: link status definitely up for interface eth0, 0 Mbps full duplex
So far in all the failed traces I have collected this ha
Hi, Emil
Thanks for your hard work.
With kernel 3.14, NETDEV_CHANGELOWERSTATE is not introduced. my user
still confronted
"bond_mii_monitor: bond0: link status definitely up for interface eth1,
0 Mbps full duplex".
How to explain it?
Would you like to make tests with kernel 3.14?
Thanks a
Hi, Emil
Thanks for your reply.
I made simple tests. And maybe this patch should work. Because you can
reproduce this problem, would you like to make tests with this patch?
If this patch can fix this problem, it can prove that the root cause is
correct.
We can find another solution to fix thi
Thanks a lot.
Maybe this patch is to miimon and notifier. Maybe it is not appropriate to arp
monitor.
So the following patch will avoid arp monitor.
Thanks a lot.
Zhu Yanjun
+ /* Because of link flap from the slave interface, it is possilbe that
+* the notifiler is NETDEV_UP whi
On 01/22/2016 02:52 PM, Jiri Pirko wrote:
Fri, Jan 22, 2016 at 05:21:28AM CET, wen.gang.w...@oracle.com wrote:
在 2016年01月21日 16:35, Jiri Pirko 写道:
Thu, Jan 21, 2016 at 06:32:58AM CET, wen.gang.w...@oracle.com wrote:
In a bonding setting, we determines fragment size according to MTU and
PMTU a
On 01/26/2016 02:26 PM, zhuyj wrote:
On 01/26/2016 02:00 PM, Jay Vosburgh wrote:
zhuyj wrote:
On 01/26/2016 08:43 AM, Jay Vosburgh wrote:
wrote:
From: Zhu Yanjun
Bonding will utilize notifier callbacks to detect slave
link state changes. It is intended to be used with miimon
set to
On 01/26/2016 02:00 PM, Jay Vosburgh wrote:
zhuyj wrote:
On 01/26/2016 08:43 AM, Jay Vosburgh wrote:
wrote:
From: Zhu Yanjun
Bonding will utilize notifier callbacks to detect slave
link state changes. It is intended to be used with miimon
set to zero, and does not support the updelay or
On 01/26/2016 08:43 AM, Jay Vosburgh wrote:
wrote:
From: Zhu Yanjun
Bonding will utilize notifier callbacks to detect slave
link state changes. It is intended to be used with miimon
set to zero, and does not support the updelay or downdelay
options to bonding.
Because of link flap from the
https://www.mail-archive.com/netdev@vger.kernel.org/msg94109.html
Maybe this link can help you. If work, please let me know.
Thanks a lot.
Zhu Yanjun
On 01/25/2016 06:08 PM, Nikola Ciprich wrote:
Hello netdev readers,
I'd like to consult following problem we're dealing with:
I have a cluster
On 01/07/2016 03:59 PM, Michal Kubecek wrote:
On Thu, Jan 07, 2016 at 03:37:26PM +0800, zhuyj wrote:
If I read this right, whenever this state (link up but speed/duplex
unknown) is entered, you'll keep writing this message into kernel log
every miimon milliseconds until something changes
On 01/07/2016 10:43 AM, Tantilov, Emil S wrote:
-Original Message-
From: zhuyj [mailto:zyjzyj2...@gmail.com]
Sent: Tuesday, January 05, 2016 7:05 PM
To: Tantilov, Emil S; Michal Kubecek; Jay Vosburgh
Cc: vfal...@gmail.com; go...@cumulusnetworks.com; netdev@vger.kernel.org;
Shteinbock
Hi, Emil
Would you like to help me to make tests with this patch?
If the root cause is not the time span, I will make a new patch for this.
Thanks a lot.
Zhu Yanjun
On 01/07/2016 02:15 PM, zyjzyj2...@gmail.com wrote:
From: Zhu Yanjun
In 802.3ad mode, the speed and duplex is needed. But in so
On 01/07/2016 10:43 AM, Tantilov, Emil S wrote:
-Original Message-
From: zhuyj [mailto:zyjzyj2...@gmail.com]
Sent: Tuesday, January 05, 2016 7:05 PM
To: Tantilov, Emil S; Michal Kubecek; Jay Vosburgh
Cc: vfal...@gmail.com; go...@cumulusnetworks.com; netdev@vger.kernel.org;
Shteinbock
On 01/06/2016 11:30 PM, Tantilov, Emil S wrote:
-Original Message-
From: zhuyj [mailto:zyjzyj2...@gmail.com]
Sent: Tuesday, January 05, 2016 9:42 PM
To: Tantilov, Emil S; Kirsher, Jeffrey T; Brandeburg, Jesse; Nelson,
Shannon; Wyborny, Carolyn; Skidmore, Donald C; Allan, Bruce W; Ronciak
On 01/06/2016 11:30 PM, Tantilov, Emil S wrote:
-Original Message-
From: zhuyj [mailto:zyjzyj2...@gmail.com]
Sent: Tuesday, January 05, 2016 9:42 PM
To: Tantilov, Emil S; Kirsher, Jeffrey T; Brandeburg, Jesse; Nelson,
Shannon; Wyborny, Carolyn; Skidmore, Donald C; Allan, Bruce W; Ronciak
On 01/06/2016 05:03 PM, Wengang Wang wrote:
In a bonding setting, we determines fragment size according to MTU and
s/determines/determine
Thanks a lot.
Zhu Yanjun
PMTU associated to the bonding master. If the slave finds the fragment
size is too big, it drops the fragment and calls ip_rt_updat
On 01/06/2016 04:14 PM, Wengang Wang wrote:
在 2016年01月06日 16:00, zhuyj 写道:
On 01/06/2016 03:45 PM, Wengang Wang wrote:
在 2016年01月06日 15:35, zhuyj 写道:
IMHO, "The path MTU is set to the active slave device, not the
bonding master."
Can we set PMTU to bonding master when path MTU
On 01/06/2016 03:45 PM, Wengang Wang wrote:
在 2016年01月06日 15:35, zhuyj 写道:
IMHO, "The path MTU is set to the active slave device, not the
bonding master."
Can we set PMTU to bonding master when path MTU is set to the active
slave device?
Actually the route is set on bonding mast
ed to 2044 after the
first send(hopefully), for the seconds send the fragment size is set
to 2044.
To fix in bonding code, I don't find where we can.
thanks,
wengang
在 2016年01月06日 14:19, zhuyj 写道:
IMHO, this should fix in bonding driver because the active slave mtu
should be the same
IMHO, the following comments will help us all.
case NETDEV_CHANGEMTU:
/* TODO: Should slaves be allowed to
* independently alter their MTU? For
* an active-backup bond, slaves need
* not be the same type of device, so
IMHO, this should fix in bonding driver because the active slave mtu
should be the same with the master.
bonding master's mtu is changed to path MTU, then slave dev's MTU should
be changed, too.
Zhu Yanjun
On 01/06/2016 01:49 PM, Wengang Wang wrote:
A problem is found that we are looking for
On 12/31/2015 12:37 AM, Tantilov, Emil S wrote:
-Original Message-
From: zhuyj [mailto:zyjzyj2...@gmail.com]
Sent: Wednesday, December 30, 2015 12:20 AM
To: Tantilov, Emil S; Kirsher, Jeffrey T; Brandeburg, Jesse; Nelson,
Shannon; Wyborny, Carolyn; Skidmore, Donald C; Allan, Bruce W
On 01/06/2016 09:26 AM, Tantilov, Emil S wrote:
-Original Message-
From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On
Behalf Of zhuyj
Sent: Monday, December 28, 2015 1:19 AM
To: Michal Kubecek; Jay Vosburgh
Cc: vfal...@gmail.com; go...@cumulusnetworks.com; netdev
On 12/31/2015 01:17 PM, Jeff Kirsher wrote:
On Thu, 2015-12-31 at 13:04 +0800, zyjzyj2...@gmail.com wrote:
Thanks for the suggestions from Rustad, Mark D.
According to his suggestions, the logs and source code are
simplified.
I find it funny that this email (no patch) is got the correct subject
On 12/30/2015 02:55 PM, Tantilov, Emil S wrote:
-Original Message-
From: zhuyj [mailto:zyjzyj2...@gmail.com]
Sent: Tuesday, December 29, 2015 6:49 PM
To: Tantilov, Emil S; Kirsher, Jeffrey T; Brandeburg, Jesse; Nelson,
Shannon; Wyborny, Carolyn; Skidmore, Donald C; Allan, Bruce W
On 12/30/2015 03:17 AM, Rustad, Mark D wrote:
Emil S wrote:
*/
- if (hw->mac.type == ixgbe_mac_X540)
+ if ((hw->mac.type == ixgbe_mac_X540) &&
+ (netdev->flags & IFF_SLAVE))
if (link_speed == IXGBE_LINK_SPEED_UNKNOWN)
return;
If
On 12/30/2015 12:18 AM, Tantilov, Emil S wrote:
-Original Message-
From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On
Behalf Of zyjzyj2...@gmail.com
Sent: Monday, December 28, 2015 6:32 PM
To: Kirsher, Jeffrey T; Brandeburg, Jesse; Nelson, Shannon; Wyborny,
Carolyn
On 12/28/2015 04:43 PM, Michal Kubecek wrote:
On Thu, Dec 17, 2015 at 01:57:16PM -0800, Jay Vosburgh wrote:
wrote:
In 802.3ad mode, the speed and duplex is needed. But in some NIC,
there is a time span between NIC up state and getting speed and duplex.
As such, sometimes a slave in 802.3ad mod
On 12/24/2015 01:58 PM, Tantilov, Emil S wrote:
-Original Message-
From: zhuyj [mailto:zyjzyj2...@gmail.com]
Sent: Wednesday, December 23, 2015 6:28 PM
To: Tantilov, Emil S; Kirsher, Jeffrey T; Brandeburg, Jesse; Nelson,
Shannon; Wyborny, Carolyn; Skidmore, Donald C; Allan, Bruce W
On 12/23/2015 11:59 PM, Tantilov, Emil S wrote:
-Original Message-
From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On
Behalf Of zyjzyj2...@gmail.com
Sent: Tuesday, December 22, 2015 10:47 PM
To: Kirsher, Jeffrey T; Brandeburg, Jesse; Nelson, Shannon; Wyborny,
Carol
58 matches
Mail list logo
