Discussion:
[Ryu-devel] Throughput losses with HP Switch
Chaitanya Kumar
2017-07-13 05:56:32 UTC
Permalink
Hi

We are working on a research project that involves HP OpenFlow enabled
switch (HP 3500 yl). We are facing some issues with performance
particularly when operating the switch in "OpenFlow" mode. The switch is
controlled via a desktop running the Ryu controller.

The rules on the switch match packets based on the fields supported by
OpenFlow. Further, the switch also modifies a certain IP header field (in
this case the ToS bits) for packets that match the rules and are hence
forwarded.

More precisely, the rules match the ToS bits of the packet and change them
to a different value before forwarding them to a chosen host.

However, in the process, the forwarded packets achieve a throughput of no
more than 700kbps, while the source and destination hosts have 100 Mbit/s
Ethernet ports. If we disable "OpenFlow" mode and use it as it is then we
achieve a full throughput of 100Mbit/s (the Ethernet link speeds of the
client and server hosts). The end-to-end throughput was measured using
*iperf*.

Could someone shed some light on the reason for this drastic performance
degradation? (all the switch does is match packets whose ToS value is
(say,) 0x28 and replaces it with 0x40 before forwarding them to the right
destination)

Also, is there an alternative switch that someone has used successfully for
similar things?


A figure showing our experiment scenario is given below, for reference.




Thanks,

Chaitanya
Oleg Sadov
2017-07-13 08:23:23 UTC
Permalink
In fact, it depends on which fields are used in the match for HP switches:

http://h20628.www2.hp.com/km-ext/kmcsdirect/emr_na-c03991489-1.pdf

For ex. in HP 3500 yl MACs handled by software level, but IP address for IP
Eth type (0x800) -- in hardware. As a consequence -- switching form MAC to
IP matching can increase the throughput for such OF switches.
Post by Chaitanya Kumar
Hi
We are working on a research project that involves HP OpenFlow enabled
switch (HP 3500 yl). We are facing some issues with performance
particularly when operating the switch in "OpenFlow" mode. The switch is
controlled via a desktop running the Ryu controller.
The rules on the switch match packets based on the fields supported by
OpenFlow. Further, the switch also modifies a certain IP header field (in
this case the ToS bits) for packets that match the rules and are hence
forwarded.
More precisely, the rules match the ToS bits of the packet and change them
to a different value before forwarding them to a chosen host.
However, in the process, the forwarded packets achieve a throughput of no
more than 700kbps, while the source and destination hosts have 100 Mbit/s
Ethernet ports. If we disable "OpenFlow" mode and use it as it is then we
achieve a full throughput of 100Mbit/s (the Ethernet link speeds of the
client and server hosts). The end-to-end throughput was measured using
*iperf*.
Could someone shed some light on the reason for this drastic performance
degradation? (all the switch does is match packets whose ToS value is
(say,) 0x28 and replaces it with 0x40 before forwarding them to the right
destination)
Also, is there an alternative switch that someone has used successfully
for similar things?
A figure showing our experiment scenario is given below, for reference.
Thanks,
Chaitanya
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Ryu-devel mailing list
https://lists.sourceforge.net/lists/listinfo/ryu-devel
Sambuddho Chakravarty
2017-07-13 09:51:26 UTC
Permalink
Strangely we are seeing a terrible throughput drop when packets are matched
(by IP header)
and then modified and sent out through a different egress port (basically
NATting packets).

Line rates of the interfaces are 1 Gbps, but when we turn on the openflow
mode and
matched packets are forwarded through a different port (after their
source/destination IP addresses
are modified), their speed drastically drops to about 700 Kbps (99% drop in
throughput).

Regards
Sambuddho Chakravarty
Post by Oleg Sadov
http://h20628.www2.hp.com/km-ext/kmcsdirect/emr_na-c03991489-1.pdf
For ex. in HP 3500 yl MACs handled by software level, but IP address for
IP Eth type (0x800) -- in hardware. As a consequence -- switching form MAC
to IP matching can increase the throughput for such OF switches.
Post by Chaitanya Kumar
Hi
We are working on a research project that involves HP OpenFlow enabled
switch (HP 3500 yl). We are facing some issues with performance
particularly when operating the switch in "OpenFlow" mode. The switch is
controlled via a desktop running the Ryu controller.
The rules on the switch match packets based on the fields supported by
OpenFlow. Further, the switch also modifies a certain IP header field
(in this case the ToS bits) for packets that match the rules and are hence
forwarded.
More precisely, the rules match the ToS bits of the packet and change
them to a different value before forwarding them to a chosen host.
However, in the process, the forwarded packets achieve a throughput of no
more than 700kbps, while the source and destination hosts have 100 Mbit/s
Ethernet ports. If we disable "OpenFlow" mode and use it as it is then we
achieve a full throughput of 100Mbit/s (the Ethernet link speeds of the
client and server hosts). The end-to-end throughput was measured using
*iperf*.
Could someone shed some light on the reason for this drastic performance
degradation? (all the switch does is match packets whose ToS value is
(say,) 0x28 and replaces it with 0x40 before forwarding them to the right
destination)
Also, is there an alternative switch that someone has used successfully
for similar things?
A figure showing our experiment scenario is given below, for reference.
Thanks,
Chaitanya
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Ryu-devel mailing list
https://lists.sourceforge.net/lists/listinfo/ryu-devel
Loading...