netfront: shrink MAX_TX_REQ_FRAGS by one

[liuw_liuw.name]

Summary

MAX_TX_REQ_FRAGS is derived from Linux backend driver.

There is nothing wrong with the original value, but nowadays Linux backend copes more efficiently with the new value.

[royger]

I think some other fixups are needed if MAX_TX_REQ_FRAGS is changed.

sys/dev/xen/netfront/netfront.c

112

AFAICT changing this requires some other fixups in the code,

For example in xn_assemble_tx_request shouldn't we add a +1 to the check:

if (nfrags > MAX_TX_REQ_FRAGS) {

[liuw_liuw.name]

sys/dev/xen/netfront/netfront.c

112

I don't think so.

It wouldn't hurt to do that, but then that restores the same behaviour that makes driver domain less efficient.

[royger]

sys/dev/xen/netfront/netfront.c

112

I don't know much about netfront, but AFAICT Linux is doing this check like:

if (unlikely(slots > MAX_SKB_FRAGS + 1)) {

Can you elaborate on why does this affect driver domains specifically?

[liuw_liuw.name]

sys/dev/xen/netfront/netfront.c

112

So this is an independent issue in FreeBSD netfront.

I don't know enough of how a packet in FreeBSD is assembled, but it indeed looks like it should be MAX_TX_REQ_FRAGS+1, regardless of what the value of MAX_TX_REQ_FRAGS is.

Do you want another patch for that?

[royger]

sys/dev/xen/netfront/netfront.c

112

TBH, I don't know that much, but for example I'm wondering whether:

ifp->if_hw_tsomaxsegcount = MAX_TX_REQ_FRAGS;

Should then also be adjusted to:

ifp->if_hw_tsomaxsegcount = MAX_TX_REQ_FRAGS + 1;

And also I'm not sure about the following line:

	return (RING_FREE_REQUESTS(&np->tx) > (MAX_TX_REQ_FRAGS + 2));

Because AFAICT we only need one extra request per mbuf chain (to account for the netif_extra_info request payload).

[liuw_liuw.name]

sys/dev/xen/netfront/netfront.c

112

I think it's better we just drop this patch and revisit it later when I have better understanding of FreeBSD network stack.