On Thu, Sep 19, 2019 at 2:16 AM Ramana Reddy <[email protected]> wrote: > > Hi William, > Thanks for your reply. Please find the inline comments. > > On Fri, Aug 30, 2019 at 9:26 PM William Tu <[email protected]> wrote: >> >> Hi Ramana, >> >> I'm trying to understand your setup. >> >> On Wed, Aug 28, 2019 at 4:11 AM Ramana Reddy <[email protected]> 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 _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
