On 01/12/15 at 10:55am, Jesse Gross wrote:
> There are at least two parts to this:
> * Calculating the right MTU for the guest device.
> * Transferring the MTU from the host to the guest.
>
> The first would presumably involve exposing some kind of API that the
> component that does know the rig
On Thu, Jan 8, 2015 at 9:48 PM, Fan Du wrote:
> 于 2015年01月09日 03:55, Jesse Gross 写道:
>>
>> On Thu, Jan 8, 2015 at 1:39 AM, Fan Du
>> wrote:
>>
>>> >于 2015年01月08日 04:52, Jesse Gross 写道:
>
> >>>
> >>>My understanding is:
>>
>> >>> >controller sets the forwarding rules into kernel
On Thu, Jan 8, 2015 at 9:42 PM, Fan Du wrote:
> 于 2015年01月09日 03:55, Jesse Gross 写道:
>
>> On Thu, Jan 8, 2015 at 1:39 AM, Fan Du
>> wrote:
>>>
>>> 于 2015年01月08日 04:52, Jesse Gross 写道:
>
>
> My understanding is:
>>
>> controller sets the forwarding rules into kernel datapath, a
于 2015年01月09日 03:55, Jesse Gross 写道:
On Thu, Jan 8, 2015 at 1:39 AM, Fan Du wrote:
>于 2015年01月08日 04:52, Jesse Gross 写道:
>>>
>>>My understanding is:
>>> >controller sets the forwarding rules into kernel datapath, any flow not
>>> >matching
>>> >with the rules are threw to controller by upcall
于 2015年01月09日 03:55, Jesse Gross 写道:
On Thu, Jan 8, 2015 at 1:39 AM, Fan Du wrote:
于 2015年01月08日 04:52, Jesse Gross 写道:
My understanding is:
controller sets the forwarding rules into kernel datapath, any flow not
matching
with the rules are threw to controller by upcall. Once the rule decisi
On Thu, Jan 8, 2015 at 1:39 AM, Fan Du wrote:
> 于 2015年01月08日 04:52, Jesse Gross 写道:
>>>
>>> My understanding is:
>>> >controller sets the forwarding rules into kernel datapath, any flow not
>>> >matching
>>> >with the rules are threw to controller by upcall. Once the rule decision
>>> > is
>>> >m
于 2015年01月08日 04:52, Jesse Gross 写道:
My understanding is:
>controller sets the forwarding rules into kernel datapath, any flow not
>matching
>with the rules are threw to controller by upcall. Once the rule decision is
>made
>by controller, then, this flow packet is pushed down to datapath to be
>
On Tue, Jan 6, 2015 at 9:58 PM, Fan Du wrote:
> 于 2015年01月07日 03:11, Jesse Gross 写道:
One of the reasons for only doing path MTU discovery
>>for L3 is that it operates seamlessly as part of normal operation -
>>there is no need to forge addresses or potentially generate ICMP whe
于 2015年01月07日 03:11, Jesse Gross 写道:
One of the reasons for only doing path MTU discovery
>>for L3 is that it operates seamlessly as part of normal operation -
>>there is no need to forge addresses or potentially generate ICMP when
>>on an L2 network. However, this ignores the IP handling that is
On Tue, Jan 6, 2015 at 4:34 AM, Fan Du wrote:
>
> On 2015/1/6 1:58, Jesse Gross wrote:
>>
>> On Mon, Jan 5, 2015 at 1:02 AM, Fan Du
>> wrote:
>>>
>>> 于 2014年12月03日 10:31, Du, Fan 写道:
>>>
> -Original Message-
> From: Thomas Graf [mailto:t...@infradead.org] On Behalf Of Thomas
On 2015/1/6 1:58, Jesse Gross wrote:
On Mon, Jan 5, 2015 at 1:02 AM, Fan Du wrote:
于 2014年12月03日 10:31, Du, Fan 写道:
-Original Message-
From: Thomas Graf [mailto:t...@infradead.org] On Behalf Of Thomas Graf
Sent: Wednesday, December 3, 2014 1:42 AM
To: Michael S. Tsirkin
Cc: Du, Fan
On Mon, Jan 5, 2015 at 1:02 AM, Fan Du wrote:
> 于 2014年12月03日 10:31, Du, Fan 写道:
>
>>
>>
>>> -Original Message-
>>> From: Thomas Graf [mailto:t...@infradead.org] On Behalf Of Thomas Graf
>>> Sent: Wednesday, December 3, 2014 1:42 AM
>>> To: Michael S. Tsirkin
>>> Cc: Du, Fan; 'Jason Wang';
于 2014年12月03日 10:31, Du, Fan 写道:
-Original Message-
From: Thomas Graf [mailto:t...@infradead.org] On Behalf Of Thomas Graf
Sent: Wednesday, December 3, 2014 1:42 AM
To: Michael S. Tsirkin
Cc: Du, Fan; 'Jason Wang'; net...@vger.kernel.org; da...@davemloft.net;
f...@strlen.de; dev@openvs
On 2014/12/5 7:23, Jesse Gross wrote:
On Wed, Dec 3, 2014 at 11:48 PM, Du Fan wrote:
于 2014年12月04日 06:51, Jesse Gross 写道:
My proposal would be something like this:
* For L2, reduce the VM MTU to the lowest common denominator on the
segment.
* For L3, use path MTU discovery or fragment i
On Wed, Dec 3, 2014 at 11:48 PM, Du Fan wrote:
> 于 2014年12月04日 06:51, Jesse Gross 写道:
>>
>> My proposal would be something like this:
>> * For L2, reduce the VM MTU to the lowest common denominator on the
>> segment.
>> * For L3, use path MTU discovery or fragment inner packet (i.e.
>> normal
On Thu, Dec 4, 2014 at 1:26 AM, Thomas Graf wrote:
> On 12/03/14 at 05:51pm, Jesse Gross wrote:
>> I think it depends on where you put the PMTU check. If routing is
>> happening in OVS where it is decomposed in several discrete actions
>> like set MAC and decrement TTL then perhaps there is anothe
On Wed, Dec 03, 2014 at 10:56:02AM -0800, Rick Jones wrote:
> Trying to "fake-out" an ICMP message to paper-over "devices" in the "middle"
> of same Layer2 network having different MTUs from the ends goes back to at
> least the days when people started joining FDDI networks to Ethernet
> networks w
On 12/03/14 at 05:51pm, Jesse Gross wrote:
> I think it depends on where you put the PMTU check. If routing is
> happening in OVS where it is decomposed in several discrete actions
> like set MAC and decrement TTL then perhaps there is another explicit
> action to check the MTU. If it is happening
于 2014年12月04日 06:51, Jesse Gross 写道:
My proposal would be something like this:
* For L2, reduce the VM MTU to the lowest common denominator on the segment.
* For L3, use path MTU discovery or fragment inner packet (i.e.
normal routing behavior).
* As a last resort (such as if using an old v
On Wed, Dec 3, 2014 at 5:15 PM, Thomas Graf wrote:
> On 12/03/14 at 04:54pm, Jesse Gross wrote:
>> I don't think that we actually need a bit. I would expect that ICMP
>> generation to be coupled with routing (although this requires being
>> able to know what the ultimate MTU is at the time of rout
On 12/03/14 at 04:54pm, Jesse Gross wrote:
> I don't think that we actually need a bit. I would expect that ICMP
> generation to be coupled with routing (although this requires being
> able to know what the ultimate MTU is at the time of routing the inner
> packet). If that's the case, you just nee
On Wed, Dec 3, 2014 at 3:05 PM, Thomas Graf wrote:
> On 12/03/14 at 02:51pm, Jesse Gross wrote:
>> My proposal would be something like this:
>> * For L2, reduce the VM MTU to the lowest common denominator on the segment.
>> * For L3, use path MTU discovery or fragment inner packet (i.e.
>> norma
On 12/03/14 at 02:51pm, Jesse Gross wrote:
> My proposal would be something like this:
> * For L2, reduce the VM MTU to the lowest common denominator on the segment.
> * For L3, use path MTU discovery or fragment inner packet (i.e.
> normal routing behavior).
> * As a last resort (such as if usi
On Wed, Dec 3, 2014 at 2:02 PM, Thomas Graf wrote:
> On 12/03/14 at 11:38am, Jesse Gross wrote:
>> On Wed, Dec 3, 2014 at 10:38 AM, Michael S. Tsirkin wrote:
>> > Both approaches seem strange. You are sending 1 packet an hour to
>> > some destination behind 100 tunnels. Why would you want to
>> >
On Wed, Dec 03, 2014 at 10:02:44PM +, Thomas Graf wrote:
> On 12/03/14 at 11:38am, Jesse Gross wrote:
> > On Wed, Dec 3, 2014 at 10:38 AM, Michael S. Tsirkin wrote:
> > > Both approaches seem strange. You are sending 1 packet an hour to
> > > some destination behind 100 tunnels. Why would you
On 12/03/14 at 11:38am, Jesse Gross wrote:
> On Wed, Dec 3, 2014 at 10:38 AM, Michael S. Tsirkin wrote:
> > Both approaches seem strange. You are sending 1 packet an hour to
> > some destination behind 100 tunnels. Why would you want to
> > cut down your MTU for all packets? On the other hand,
> >
On Wed, Dec 3, 2014 at 10:38 AM, Michael S. Tsirkin wrote:
> On Wed, Dec 03, 2014 at 10:07:42AM -0800, Jesse Gross wrote:.
>> ICMP can't be the complete solution in any case because it only works
>> for IP traffic.
>
> Let's be specific please. What protocols do you most care about? IPX?
>
>> I t
Trying to "fake-out" an ICMP message to paper-over "devices" in the
"middle" of same Layer2 network having different MTUs from the ends goes
back to at least the days when people started joining FDDI networks to
Ethernet networks with bridges rather than routers. Perhaps back even
further. It
On Wed, Dec 03, 2014 at 10:07:42AM -0800, Jesse Gross wrote:
> On Wed, Dec 3, 2014 at 1:03 AM, Michael S. Tsirkin wrote:
> > On Tue, Dec 02, 2014 at 10:12:04AM -0800, Jesse Gross wrote:
> >> On Tue, Dec 2, 2014 at 9:41 AM, Thomas Graf wrote:
> >> > On 12/02/14 at 07:34pm, Michael S. Tsirkin wrote
On Wed, Dec 3, 2014 at 1:03 AM, Michael S. Tsirkin wrote:
> On Tue, Dec 02, 2014 at 10:12:04AM -0800, Jesse Gross wrote:
>> On Tue, Dec 2, 2014 at 9:41 AM, Thomas Graf wrote:
>> > On 12/02/14 at 07:34pm, Michael S. Tsirkin wrote:
>> >> On Tue, Dec 02, 2014 at 05:09:27PM +, Thomas Graf wrote:
On Tue, Dec 02, 2014 at 10:12:04AM -0800, Jesse Gross wrote:
> On Tue, Dec 2, 2014 at 9:41 AM, Thomas Graf wrote:
> > On 12/02/14 at 07:34pm, Michael S. Tsirkin wrote:
> >> On Tue, Dec 02, 2014 at 05:09:27PM +, Thomas Graf wrote:
> >> > On 12/02/14 at 01:48pm, Flavio Leitner wrote:
> >> > > Wh
>-Original Message-
>From: Thomas Graf [mailto:t...@infradead.org] On Behalf Of Thomas Graf
>Sent: Wednesday, December 3, 2014 1:42 AM
>To: Michael S. Tsirkin
>Cc: Du, Fan; 'Jason Wang'; net...@vger.kernel.org; da...@davemloft.net;
>f...@strlen.de; dev@openvswitch.org; je...@nicira.com; p
On Tue, Dec 2, 2014 at 9:41 AM, Thomas Graf wrote:
> On 12/02/14 at 07:34pm, Michael S. Tsirkin wrote:
>> On Tue, Dec 02, 2014 at 05:09:27PM +, Thomas Graf wrote:
>> > On 12/02/14 at 01:48pm, Flavio Leitner wrote:
>> > > What about containers or any other virtualization environment that
>> > >
On 12/02/14 at 07:34pm, Michael S. Tsirkin wrote:
> On Tue, Dec 02, 2014 at 05:09:27PM +, Thomas Graf wrote:
> > On 12/02/14 at 01:48pm, Flavio Leitner wrote:
> > > What about containers or any other virtualization environment that
> > > doesn't use Virtio?
> >
> > The host can dictate the MTU
On Tue, Dec 02, 2014 at 05:09:27PM +, Thomas Graf wrote:
> On 12/02/14 at 01:48pm, Flavio Leitner wrote:
> > What about containers or any other virtualization environment that
> > doesn't use Virtio?
>
> The host can dictate the MTU in that case for both veth or OVS
> internal which would be p
On 12/02/14 at 01:48pm, Flavio Leitner wrote:
> What about containers or any other virtualization environment that
> doesn't use Virtio?
The host can dictate the MTU in that case for both veth or OVS
internal which would be primary container plumbing techniques.
ivshmem would need it's own fix.
_
On Mon, Dec 01, 2014 at 01:52:25PM +, Thomas Graf wrote:
> On 11/30/14 at 10:08am, Du, Fan wrote:
> > >-Original Message-
> > >From: Jason Wang [mailto:jasow...@redhat.com]
> > >Sent: Friday, November 28, 2014 3:02 PM
> > >To: Du, Fan
> > >Cc: net...@vger.kernel.org; da...@davemloft.net
On Mon, Dec 01, 2014 at 01:52:25PM +, Thomas Graf wrote:
> On 11/30/14 at 10:08am, Du, Fan wrote:
> > >-Original Message-
> > >From: Jason Wang [mailto:jasow...@redhat.com]
> > >Sent: Friday, November 28, 2014 3:02 PM
> > >To: Du, Fan
> > >Cc: net...@vger.kernel.org; da...@davemloft.net
On 11/30/14 at 10:08am, Du, Fan wrote:
> >-Original Message-
> >From: Jason Wang [mailto:jasow...@redhat.com]
> >Sent: Friday, November 28, 2014 3:02 PM
> >To: Du, Fan
> >Cc: net...@vger.kernel.org; da...@davemloft.net; f...@strlen.de; Du, Fan
> >Subject: Re: [PATCH net] gso: do GSO for loc
39 matches
Mail list logo
