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
在 2016年01月22日 14:52, Jiri Pirko 写道:
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 assoc
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 associated to the bonding master. If
在 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 associated to the bonding master. If the slave finds the fragment
size is too big, it drops the fragment and call
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 associated to the bonding master. If the slave finds the fragment
>size is too big, it drops the fragment and calls ip_rt_update_pmtu(),
>passing _skb_
In a bonding setting, we determines fragment size according to MTU and
PMTU associated to the bonding master. If the slave finds the fragment
size is too big, it drops the fragment and calls ip_rt_update_pmtu(),
passing _skb_ and _pmtu_, trying to update the path MTU.
Problem is that the target dev
在 2016年01月21日 12:05, Jay Vosburgh 写道:
Wengang Wang wrote:
[...]
For ipip, yes seems update_pmtu is called in line for each call of
queue_xmit. Do you know if it's a good configuration for ipip + bonding?
Yes, it is.
Other's comment and suggestion?
I agree with Sabrina Du
在 2016年01月20日 23:18, Sabrina Dubroca 写道:
2016-01-20, 13:32:13 +0800, Wengang Wang wrote:
In a bonding setting, we determines fragment size according to MTU and
PMTU associated to the bonding master. If the slave finds the fragment
size is too big, it drops the fragment and calls ip_rt_update_p
Wengang Wang wrote:
[...]
>For ipip, yes seems update_pmtu is called in line for each call of
>queue_xmit. Do you know if it's a good configuration for ipip + bonding?
Yes, it is.
>Other's comment and suggestion?
I agree with Sabrina Dubroca 's suggestions
from yesterday.
在 2016年01月20日 17:56, zhuyj 写道:
On 01/20/2016 05:47 PM, Wengang Wang wrote:
在 2016年01月20日 15:54, zhuyj 写道:
On 01/20/2016 03:38 PM, Wengang Wang wrote:
在 2016年01月20日 14:24, zhuyj 写道:
On 01/20/2016 01:32 PM, Wengang Wang wrote:
In a bonding setting, we determines fragment size according to
2016-01-20, 13:32:13 +0800, Wengang Wang wrote:
> In a bonding setting, we determines fragment size according to MTU and
> PMTU associated to the bonding master. If the slave finds the fragment
> size is too big, it drops the fragment and calls ip_rt_update_pmtu(),
> passing _skb_ and _pmtu_, tryin
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
Please see if the V2 is clear.
thanks,
wengang
在 2016年01月06日 16:18, zhuyj 写道:
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 t
In a bonding setting, we determines fragment size according to MTU and
PMTU associated to the bonding master. If the slave finds the fragment
size is too big, it drops the fragment and calls ip_rt_update_pmtu(),
passing _skb_ and _pmtu_, trying to update the path MTU.
Problem is that the target dev
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 is set to th
在 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 is set to the active
slave device?
Actually the route
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 master, not on a
在 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 master, not on any slave, the
trying to set PMTU to the acti
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?
If not appropriate, you can ignore it.
Best Regards!
Zhu Yanjun
On 01/06/2016 03:06 PM, Wengang Wang wrote:
Hi Yanjun,
Thanks fo
Hmm, we are not changing device MTU but PMTU...
thanks,
wengang
在 2016年01月06日 14:44, zhuyj 写道:
IMHO, the following comments will help us all.
case NETDEV_CHANGEMTU:
/* TODO: Should slaves be allowed to
* independently alter their MTU? For
Hi Yanjun,
Thanks for your review.
Master MTU is same as that for slaves.
Maybe fixing in bonding driver is a good idea, but I don't find a good
place to do that.
Let's go through the simplified follow:
...
1) Fragmentation.
--This is is done is against the bonding master device(device MTU
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
在 2016年01月06日 14:18, David Miller 写道:
From: Wengang Wang
Date: Wed, 6 Jan 2016 13:49:28 +0800
@@ -523,11 +523,20 @@ static void build_skb_flow_key(struct flowi4 *fl4, const
struct sk_buff *skb,
const struct sock *sk)
{
const struct iphdr *iph = ip_h
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
From: Wengang Wang
Date: Wed, 6 Jan 2016 13:49:28 +0800
> @@ -523,11 +523,20 @@ static void build_skb_flow_key(struct flowi4 *fl4,
> const struct sk_buff *skb,
> const struct sock *sk)
> {
> const struct iphdr *iph = ip_hdr(skb);
> - int oif = skb->dev->i
A problem is found that we are looking for route basing a bonding device and
deal with path MTU there: The path MTU is set to the active slave device, not
the bonding master.
The patch tries to fix the issue by letting build_skb_flow_key() take care
of the transition of device index from bonding s
26 matches
Mail list logo
