xen-netfront: fix initialization

[royger]

Summary

A couple of mostly cosmetic fixes for the final initialization of netfront:

• Switch to "connected" state before starting to kick the rings.
• Correctly use "rxq" in the initialization loop (previously rxq was not updated in the loop, and netfront would kick np->rxq[N] several times).
• Kick the TX task in case there are packets pending for send.

Sponsored by: Citrix Systems R&D

[liuw_liuw.name]

sys/dev/xen/netfront/netfront.c

1973 ↗

(On Diff #17147)

It's better to leave this in the state changing function.

Just move this before calling xn_connect will do, right?

[royger]

sys/dev/xen/netfront/netfront.c

1973 ↗

(On Diff #17147)

Thanks for the review!

I'm not sure that's correct. If the call to xenbus_set_state is done before calling xn_connect, netfront would be switching to state 4 before writing the ring information on xenstore (grant-ref, evtchn) and the features. I'm quite sure netback would choke if it sees state 4 but no shared-ring information on xenstore.

I could split out the last part of xn_connect into something like xn_kick_rings, and then call xenbus_set_state in the middle:

xn_connect(...)
xenbus_set_state(...)
xn_kick_rings(...)

Does that look better?

[liuw_liuw.name]

sys/dev/xen/netfront/netfront.c

1973 ↗

(On Diff #17147)

Yes, that's better.

But, maybe we could just remove the taskqueue_enqueue and leave that to the interrupt handler? Because that's more or less what Linux netfront does -- it allocates resources, kick the backend, no kicking itself is done.

Sorry our freebsd vm is not yet back online so I can't easily navigate the freebsd code.

[royger]

Split xn_kick_rings from xn_connect and leave the set_state call at the same
place. Also remove the taskqueue kick.