> -----Original Message----- > From: David Marchand <[email protected]> > Sent: Thursday, April 1, 2021 8:04 PM > To: Wang, Xiao W <[email protected]> > Cc: Xia, Chenbo <[email protected]>; Maxime Coquelin > <[email protected]>; Liu, Yong <[email protected]>; dev > <[email protected]>; Ananyev, Konstantin <[email protected]>; > dpdk stable <[email protected]> > Subject: Re: [PATCH v3] vhost: add header check in dequeue offload > > On Wed, Mar 17, 2021 at 7:50 AM Xiao Wang <[email protected]> > wrote: > > > > When parsing the virtio net header and packet header for dequeue offload, > > we need to perform sanity check on the packet header to ensure: > > - No out-of-boundary memory access. > > - The packet header and virtio_net header are valid and aligned. > > > > Fixes: d0cf91303d73 ("vhost: add Tx offload capabilities") > > Cc: [email protected] > > > > Signed-off-by: Xiao Wang <[email protected]> > > I spent some time digging on this topic. > > Afaiu the offload API, vhost is not supposed to populate tx offloads. > I would drop this whole parse_ethernet function and replace > vhost_dequeue_offload with what virtio does on the rx side. > > Please have a look at this series (especially the last patch): > http://patchwork.dpdk.org/project/dpdk/list/?series=16052 > > > Thanks. > > -- > David Marchand
+Yang ,Yi into this loop who may have comments especially from OVS perspective on CKSUM/TSO/TSO in tunnel/etc.. I think the original vhost implementation here is to help pass virtio's offload request onto the next output port, either physical device or a virtio device. If we go with series http://patchwork.dpdk.org/project/dpdk/list/?series=16052, then virtual switch need to do an extra translation on the flags: e.g. PKT_RX_LRO --> PKT_TX_TCP_SEG. The question is that a packet marked with PKT_RX_LRO may come from different types of ports (non-vhost), how vSwitch can tell if TSO request should be set for this packet at transmission? If I think from an endpoint app's perspective, I'm inclined to agree with your series. If I think from a switch/router's perspective, I'm inclined to keep the current implementation. Maybe we can add PKT_RX_L4_CKSUM_NONE/PKT_RX_LRO flags into the current implementation, seems this method can cover both scenarios. BRs, Xiao
