When a flow is missed in datapath (kernel), queue_userspace_packet calls
genlmsg_unicast to transfer skb to userspace. In userspace context, 2
threads are of interest, udpif_dispatcher & udpif_upcall_handler.
udpif_upcall_handle seems to check semantics about missed flow and
subsequtently installs
I've known about this problem for years now, but I've always ignored it
because it didn't seem to cause trouble in practice.
I have a favorite straw-man approach. It won't work as-is, but perhaps
it will spur someone to an idea that would work. Suppose that we
changed the semantics of the kernel
On Oct 3, 2013, at 22:41 PM, Jesse Gross wrote:
> On Thu, Oct 3, 2013 at 6:26 AM, Dmitry Fleytman wrote:
>> On Oct 3, 2013, at 04:20 AM, Jesse Gross wrote:
>>> On Wed, Oct 2, 2013 at 4:49 AM, Dmitry Fleytman wrote:
On Apr 30, 2012, at 20:15 PM, Ben Pfaff wrote:
> I think
On Thu, Oct 3, 2013 at 6:26 AM, Dmitry Fleytman wrote:
> On Oct 3, 2013, at 04:20 AM, Jesse Gross wrote:
>> On Wed, Oct 2, 2013 at 4:49 AM, Dmitry Fleytman wrote:
>>>
>>> On Apr 30, 2012, at 20:15 PM, Ben Pfaff wrote:
>>>
I think that your explanation stems from a misunderstanding. Yes, i
On Oct 3, 2013, at 04:20 AM, Jesse Gross wrote:
> On Wed, Oct 2, 2013 at 4:49 AM, Dmitry Fleytman wrote:
>>
>> On Apr 30, 2012, at 20:15 PM, Ben Pfaff wrote:
>>
>>> I think that your explanation stems from a misunderstanding. Yes, if
>>> an OpenFlow controller uses a reactive model, then it
On Wed, Oct 2, 2013 at 4:49 AM, Dmitry Fleytman wrote:
>
> On Apr 30, 2012, at 20:15 PM, Ben Pfaff wrote:
>
>> I think that your explanation stems from a misunderstanding. Yes, if
>> an OpenFlow controller uses a reactive model, then it cannot avoid the
>> problem. However, I think that Joji is
On Apr 30, 2012, at 20:15 PM, Ben Pfaff wrote:
> I think that your explanation stems from a misunderstanding. Yes, if
> an OpenFlow controller uses a reactive model, then it cannot avoid the
> problem. However, I think that Joji is raising a different issue, one
> that is an implementation det
I think that your explanation stems from a misunderstanding. Yes, if
an OpenFlow controller uses a reactive model, then it cannot avoid the
problem. However, I think that Joji is raising a different issue, one
that is an implementation detail within Open vSwitch and that
controllers have no power
On Mon, Apr 30, 2012 at 7:30 AM, Joji Mtt wrote:
>> In practice you can easily solve the problem either by pushing down routes
>> proactively
>
> I am not sure that this will solve the problem - per my understanding, the
> rules that are pro-actively pushed are still in user space.
> Is there a wa
> In practice you can easily solve the problem either by pushing down
routes proactively
I am not sure that this will solve the problem - per my understanding, the
rules that are pro-actively pushed are still in user space.
Is there a way to push them down proactively to the DP?
> or by buffering
It does indeed happen with UDP flows (or if a rule is removed while a flow is
active) and it's easy to observe.
It's not a bug in Open vSwitch, which is in fact implementing the correct
OpenFlow behavior.
In practice you can easily solve the problem either by pushing down routes
proactively or b
I currently do not have a real scenario where I have run into this problem.
However, it is easy to see real scenarios where I could run into this. As
you said, most flows start off with a single packet and wait for a
response. But, there is also the flow eviction mechanism which would bring
this i
It isn't commonly a problem in practice because flows most often start
off with a single packet and wait for a return packet before ramping up
packet volume. I've been aware of the issue for years, but you are the
only other person I ever recall bringing it up on the mailing lists.
Do you have a
Are you planning to solve this problem in near future or do you have any
suggestions to mitigate this problem?
On Thu, Apr 26, 2012 at 2:37 AM, Ben Pfaff wrote:
> On Wed, Apr 25, 2012 at 01:33:56PM -0700, Joji Mtt wrote:
> > I am trying to figure out if there would be a packet order issue with t
On Wed, Apr 25, 2012 at 01:33:56PM -0700, Joji Mtt wrote:
> I am trying to figure out if there would be a packet order issue with the
> current version of OVS. Consider a case where a controller has added a
> forwarding rule for a specific flow (Flow A) and this rule is not yet
> installed in the D
Hi-
I am trying to figure out if there would be a packet order issue with the
current version of OVS. Consider a case where a controller has added a
forwarding rule for a specific flow (Flow A) and this rule is not yet
installed in the DP. In this scenario, it is conceivable that certain
(bursty)
16 matches
Mail list logo
