[ovs-discuss] [ovs-dev] Regarding TSO using AF_PACKET in OVS

William Tu u9012063 at gmail.com
Wed Sep 25 23:26:29 UTC 2019


On Thu, Sep 19, 2019 at 2:16 AM Ramana Reddy <gtvrreddy at gmail.com> wrote:
>
> Hi William,
> Thanks for your reply. Please find the inline comments.
>
> On Fri, Aug 30, 2019 at 9:26 PM William Tu <u9012063 at gmail.com> wrote:
>>
>> Hi Ramana,
>>
>> I'm trying to understand your setup.
>>
>> On Wed, Aug 28, 2019 at 4:11 AM Ramana Reddy <gtvrreddy at gmail.com> wrote:
>> >
>> > Hi Ben, Justin, Jesse and All,
>> >
>> > Hope everyone doing great.
>> >
>> > During my work, I create a socket using AF_PACKET with virtio_net_hdr and
>> > filled all the fields in the virtio_net_hdr
>> > and the flag to VIRTIO_NET_GSO_TCPV4 to enable TSO using af_packet.
>> >
>> > vnet->gso_type = VIRTIO_NET_HDR_GSO_TCPV4;
>> >
>> > The code is not working when I am trying to send large packets over OVS
>> > VXLAN tunnel. It's dropping the large packets and
>> > the application is resending the MTU sized packets. The code is working
>> > fine in non ovs case (directly sending without ovs).

btw, does 'dmesg' shows that OVS complaining about packet size
larger than MTU, so it drops the packet?

>>
>> Do you create AF_PACKET and bind its socket to OVS's vxlan device,
>> ex: vxlan_sys_4789?
>
> No. We created a AF_PACKET and binding it our own interface in the container. It takes the help of the routing table in the container
> and routes the packets to the OVS veth interface, and from there, the OVS rule selects the respective out_port  based on the destination IP address.
> We can't select  vxlan_sys_4789 interface as it is in the host namespace. It's up to the OVS  to select the respective interface (out_port).
> And we are not aware and need not know about the underlying network (OVS bridge or linux or some docker bridge) in the host.
>
>> In the non-ovs working case, do you bind AF_PACKET to the vxlan device created
>> by using ip link command?
>>
>> >
>> > I understood that UDP tunneling offloading (VXLAN) not happening because of
>> > nic may not support this offloading feature,
>> > but when I send iperf (AF_INET) traffic, though the offloading is not
>> > happening, but the large packets are fragmented and the
>> > VXLAN tunneling sending the fragmented packets.  Why are we seeing this
>> > different behavior?
>>
>> OVS's vxlan device is a light-weight tunnel device, so it might not
>> have all the
>> features.
>
> This is the same question in my mind. OVS may not be handling AF_PACKET with vnet_hdr.

Right, I couldn't find any source code related to vnet_hdr in OVS kernel module.

>>
>>
>> >
>> > What is the expected behavior in AF_PACKET in OVS? Does OVS support
>> > AF_PACKET offloading mechanism?
>>
>> AF_PACKET (see net/packet/af_packet.c) just from userspace send packet into
>> kernel and to the device you bind to.  It creates skb and invokes the
>> device's xmit
>> function.
>
> This I understood. But OVS should understand this and offload the packet to the driver or to the nic
> when virtio_net_hdr is set. If we send the packets to the normal interface (eth0) without ovs, the kernel
> is able to understand the TSO packets with virtio_net_hdr and handover the offloading to the driver (GSO) or nic (TSO).

I see your point. Yes, currently OVS does not understand this offload type,
this might be a good feature to add to OVS.

Regards,
William


More information about the discuss mailing list