[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 1/4] xen-netfront: remove unused variable `extra'

On 2013-3-19 17:28, Paul Durrant wrote:
-----Original Message-----
From: xen-devel-bounces@xxxxxxxxxxxxx [mailto:xen-devel-
bounces@xxxxxxxxxxxxx] On Behalf Of annie li
Sent: 19 March 2013 02:39
To: Ian Campbell
Cc: netdev@xxxxxxxxxxxxxxx; konrad.wilk@xxxxxxxxxx; Wei Liu; xen-
Subject: Re: [Xen-devel] [PATCH 1/4] xen-netfront: remove unused variable

On 2013-3-18 20:14, Ian Campbell wrote:
On Mon, 2013-03-18 at 12:04 +0000, Wei Liu wrote:
On Mon, 2013-03-18 at 11:42 +0000, Ian Campbell wrote:
On Mon, 2013-03-18 at 10:35 +0000, Wei Liu wrote:

I think a few more words are needed here since from the code you are
removing it seems very much like gso is used for something. If you have
a proof that the "extra = gso" case is never hit then please explain it.
Perhaps a reference to the removal of the last user?

Or maybe it is the case that it should be used and the bug is that it

Looks like the latter one. 'extra' field should  be used to get hold of
the last extra info in the ring. ;-)

But, the only extra info in upstream kernel is
so there's really no other extra info in the ring at that point. Could
it be possible that it is something from classic Xen kernel?
The classic kernel netfront has exactly the same code it seems and
netif_extra_type_gso is the only one I've ever heard of.

Maybe this extra thing is just redundant unless/until a second extra
comes along.
In our windows pv driver, we do not process this for GSO in tx path
either. Maybe we ignored processing for some special GSO?

BTW, what is XEN_NETIF_EXTRA_FLAG_MORE actually for? Backend only
processes it in xen_netback_tx_build_gops, but netfront xmit path does
not really set this flag. I did process it in rx path of my windows pv
driver(linux netfront did that too), but it seems unnecessary since
netback does not set this flag at all.

The flag is there to denote the existence of an 'extra' segment in the packet. 
The 'extra' segment goes after the 1st segment and specifies metadata such as 
the GSO type (TCPv4 is the only one at the moment but we'll need TCPv6 very 
shortly) and the MSS.

For TCPv4 GSO, it seems one extra info request(NETTXF_extra_info) is enough in my winpv driver, and I did not process the XEN_NETIF_EXTRA_MORE. Do you create two extra info requests for bothTCPv4 and TCPv6 GSO like following?

 * [Request 2: netif_tx_extra]  (only if request 1 has NETTXF_extra_info)
 * [Request 3: netif_tx_extra]  (only if request 2 has XEN_NETIF_EXTRA_MORE)

Extra segments are certainly not redundant; the Citrix Windows PV drivers send 
TSOs using them and handle LRO using them too.

About the LRO, upstream netback does not create any response with XEN_NETIF_EXTRA_MORE, so I assume your dom0 did such process?


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.