Solved it. VT-d was not enabled in BIOS. Thanks for help.
On Thu, Dec 13, 2018 at 9:39 AM Ramzah Rehman
wrote:
> sure
>
>
> Best Regards,
> Ramzah Rehman
>
>
> On Wed, Dec 12, 2018 at 8:32 PM Flavio Leitner wrote:
>
>> On Wed, Dec 12, 2018 at 01:12:49PM +0500, Ramzah Rehman wrote:
>> > Solved
> On Dec 12, 2018, at 12:32 AM, Ramzah Rehman wrote:
>
> I have tested meter action in OpenFLow. I have drawn following conclusions:
>
> • TCP
> • Conclusion: meter works fine for low rate-limiting values
> (till ~100Mbps). However, for higher values, the expected bandwidth
Hi Ben,
Tried using the ofproto/trace but it is giving me errors. I pasted the
output of ovs-dpctl to ovs-appctl ofproto/trace.
ovs-dpctl doesn't show that queue is being set in action.
// dpctl output
:~$ sudo ovs-dpctl dump-flows | grep in_port\(2
recirc_id(0),skb_priority(0),tunnel(tun_id=0x
OK, I'll look closer.
On Thu, Dec 13, 2018 at 12:13:16PM +1300, Josh Bailey wrote:
> Just tried it - frustratingly, this seems to cause the vswitchd disappears
> with status 0/no coredump scenario.
>
> 2018-12-12T23:07:01.485Z|2|daemon_unix(monitor)|INFO|pid 23736 died,
> exit status 0, exiti
Just tried it - frustratingly, this seems to cause the vswitchd disappears
with status 0/no coredump scenario.
2018-12-12T23:07:01.485Z|2|daemon_unix(monitor)|INFO|pid 23736 died,
exit status 0, exiting
I ran with vlog DBG and it didn't seem to print anything more than that.
What a puzzle!
If I'm not mistaken, we briefly discussed this at ovscon. It seems to
me that this is a fairly complicated issue and proposal, and it might
benefit from in-person discussion. I seem to recall that you are local
to the Bay Area, and, if so, do you think we could take some time,
perhaps next week,
Thanks for testing.
I discovered that this exact patch causes another problem. I posted a
slight revision without that issue. Would you mind re-testing? Thanks
a lot.
The new version is here:
https://patchwork.ozlabs.org/patch/1012261/
On Tue, Dec 11, 2018 at 12:35:15PM +1300, Josh Bailey wro
Next, I'd suggest using ofproto/trace to figure out the path of the
packets through OVS. It's documented in ovs-vswitchd(8).
On Wed, Dec 12, 2018 at 11:19:52AM -0800, Rallapalli Jagannath wrote:
> Hi Ben,
> Thanks a lot for your reply. I added min-rate to queue config. Still the
> traffic is goi
Hi Ben,
Thanks a lot for your reply. I added min-rate to queue config. Still the
traffic is going only to the default queue. Do I need to check anything
else?
ovs-vsctl set port br1 qos=@newqos1 -- --id=@newqos1 create qos
type=linux-htb other-config:max-rate=100 queues:4=@vn4queue --
--id=@v
There are several fixes for upcall handling on branch-2.7 after 2.7.0.
commit 634e1d0f3a5b9b40b665fca1bcf6e63a07bda2d2
Author: Joe Stringer
Date: Mon Jul 31 16:54:22 2017 -0700
ofproto-dpif-upcall: Fix key attr iteration.
This call is operating on messages generated by the datapat
On Tue, Dec 11, 2018 at 11:18:16PM -0800, Rallapalli Jagannath wrote:
> Hi,
> I am new to OVS and I have a question on traffic shaping .
> Setup:
> -
> I have a bridge br1 with two interfaces br1(LOCAL) and tn1 tunnel
> interface. Bridge br1 doesn't have any physical interfaces.
> Traffic
Edit: I have 2 servers connected via 1Gbps Ethernet RJ45 cable.
On Wed, Dec 12, 2018 at 1:32 PM Ramzah Rehman
wrote:
> I have tested meter action in OpenFLow. I have drawn following conclusions:
>
>
>-
>
>TCP
>-
>
> Conclusion: meter works fine for low rate-limiting values (ti
I have tested meter action in OpenFLow. I have drawn following conclusions:
-
TCP
-
Conclusion: meter works fine for low rate-limiting values (till
~100Mbps). However, for higher values, the expected bandwidth is
relatively
very low.
-
*UDP:*
-
Con
13 matches
Mail list logo
