"Let me think a little more about this. The functionality is meant to be
generic, so I don't like calling the variable 'encapBytes', since it becomes a
specific usage of the API."
I know, but I think "encapBytes" is the only usage we could ever have for the
project.
We could also use something
Hi Samuel,
> -Original Message-
> From: Samuel Ghinet [mailto:sghi...@cloudbasesolutions.com]
> Sent: Tuesday, August 26, 2014 10:40 AM
> To: Saurabh Shah
> Cc: dev@openvswitch.org
> Subject: RE: Cloning packets for "action: set field"
>
> Hi Saurabh,
>
> That may not be a very easy answ
Hi Saurabh,
That may not be a very easy answer, but, a better way would be, I believe:
headRoom -> encapBytes
copySize -> headersSize
copySize + headRoom -> (new variable) newMdlSize
It would also be very useful to have documentation comments on the parameters,
e.g.
/*
* headersSize:the numb
Hi Samuel,
>Hello Saurabh,
>
>Thanks for the clarifications!
>The param name "copySize" was very ambiguous.
What name do you think will make it easy to understand? I can take this in
to account when I post a patch for -
https://github.com/openvswitch/ovs-issues/issues/28.
>
>I did not debug this
Hello Saurabh,
Thanks for the clarifications!
The param name "copySize" was very ambiguous.
I did not debug this exact scenario, but you must be right:
- Cloning an original NB that has DataOffset > 0 causes the clone to have
DataOffset = 0
- NdisRetreatNetBufferDataStart doc says
"
DataOffsetDe
Hi Samuel,
Thanks for your patience. I believe all of your concerns are arising due
to a fundamental misunderstanding of the NDIS apis & the buffer management
code. I thought it would useful if I walk you through the
OvsPartialCopyNBL logic by giving an example.
Let's say there is a ca
"it sometimes happens for packets to come in FilterSentNetBufferLists callback:
NBL1, NBL2, NBL3 and NBL4, and only after NBL4 was finished being sent
via NdisFSendNetBufferLists, FilterSentNetBufferListsComplete starts to be
called."
I mean, to enter the FilterSentNetBufferLists callback 4 time
Hello Saurabh,
[QUOTE]For the set case, we actually send out the packet to all the existing
output ports before going ahead with the set. This is what the function
OvsOutputBeforeSetAction does. So, at any given point we only have one NBL to
deal with.[/QUOTE]
This may still not solve the probl
Hi Samuel,
> -Original Message-
> From: Samuel Ghinet [mailto:sghi...@cloudbasesolutions.com]
> Sent: Tuesday, August 05, 2014 5:00 AM
> To: Saurabh Shah
> Cc: dev@openvswitch.org
> Subject: RE: Cloning packets for "action: set field"
>
> Hello Saurabh,
>
> I believe there are more compl
Hello Saurabh,
I believe there are more complexities associated to this packet cloning.
Consider for instance the following flow:
if (conditions on packet) =>
out_to_port: vm1;
set ip_dest: X1; out_to_port: vm2
set ip_dest: X2; out_to_port: vm3
Given that multiple destinations are set, and only
Hi Samuel,
This is a bug. As you rightfully pointed, we shouldn't modify the original
packet but instead copy out the relevant bits before modifying them. Copying
the entire data buffer is simpler, but sub-optimal. We should only copy out the
headers that are being modified. We already have the
11 matches
Mail list logo
