2 spaces between int and xn_assemble_...

You can also remove the comment while there :)

xn_get_responses to match the rest of the prefixes?

Probably a stupid question, but do you know why do we need the +1 here and above?

A boolean_t might be more adequate type here. And setting it with TRUE or FALSE.

Those macros are not specially helpful IMHO, so if you think removing them would make the code clearer that's fine for me.

boolean_t hierachy

Those KASSERT messages are not really helpful, IMHO the first one should be "Mismatch between RX and TX queue id", and the second one the text in the comment just below "Split event channels are not supported".

err != 0. In FreeBSD coding style the construct you are using can only be applied to boolean types, everything else must be checked explicitly.

I know there are a lot of other instances of this construct in netfront, but we should try to at least avoid introducing new ones.

err != 0 should be fine. Anything else different than 0 returned by xs_scanf is an error.

Newline please.

Align with 4 spaces after the newline.

err != 0

Align with 4 spaces after the newline.

err != 0

Align with 4 spaces.

err != 0

extra newline?

XN_TX_LOCK_ASSERT(txq);

Shouldn't this call xn_txq_start instead of open coding it?

If a function has no local variables an empty newline should be left at the start (here and in the function below).

Align using 4 spaces always after a newline is inserted (ie: don't align to the "(" of the previous line).

The malloc at the start of the function uses M_WAITOK, so I guess this one should also use it.

error != 0

Can we use error labels here in order to prevent repeating and expanding the same cleanup in every fail case?

I think this is missing a '&', shouldn't it be:

xen_intr_unbind(&txq->xen_intr_handle);

Isn't the compiler complaining about it?

And then the line below is not needed.

The cast is not needed, and you are using malloc with M_WAITOK above in the same function, so this one should also be using M_WAITOK.

4 spaces to indent

error != 0

Is there any reason to not use:

txq->mbufs[NET_TX_RING_SIZE] = NULL;

M_WAITOK

M_WAITOK

Newline between return and out label, and I would rename the "out" label to "fail" to make it clear it's only taken on failure. Adding a KASSERT to the error path would also be nice:

KASSERT(error != 0, ("Error path taken without providing an error code"));

Same comment here as in setup_rxqs I would rather use labels in order to avoid repeating the same cleanup each time.

Since the interrupt handler just schedules a thread, I guess we could look into using a filter and then a fast taskqueue (see taskqueue_create_fast), it might prove the be faster.

Since you are already touching the line, could you add a "XXX:" prefix to the comment to make it clear it's a doubt that we need to look into and not a clarification.

s/xennet/xn/ in order to keep the same prefix for the whole file?

Fixed.

Done.

Done, along with other xennet_ functions.

I didn't notice this until you mentioned it.

I think this is because mbufs doubles as a free list so an extra element is required.

Done.

I will leave them as they are now. This patch is massive enough.

Fixed.

Done.

All instances fixed.

Done.

Done.

Done.

Done.

Done.

Done.

Done.

Indeed. I've fixed it.

Replaced all M_NOWAIT with M_WAITOK and deleted error handling code since M_WAITOK won't fail.

Maybe I missed the warning. Anyway, I've fixed that.

Does xen_intr_unbind sets the handle to a known value? If not, txq->xen_intr_handle = 0 is still needed because reconnection routine needs that to determine if it needs to release that handle. It is not implemented at the moment though.

The reason is that it actually is storing 0 semantically, because the array doubles as a free list chain. Using NULL is wrong.

I know this is not your fault, but according to the coding style(9) you should not use function calls in initializers:

"DO NOT use function calls in initializers."

I don't plan to block this change on this, it can always be fixed as a follow up patch.

Yes, xen_intr_unbind sets it to NULL:

http://fxr.watson.org/fxr/source/x86/xen/xen_intr.c#L1496

Ack, thanks for the clarification.

AFAICT, you are using fast taskqueues now, so you should be using a filter instead of a handler, it should be:

xen_intr_alloc_and_bind_local_port(dev, xenbus_get_otherend_id(dev), xn_intr, NULL, ...

You will have to change xn_intr slightly, so that it now returns FILTER_HANDLED:

http://fxr.watson.org/fxr/source/sys/bus.h?im=3#L222
http://fxr.watson.org/fxr/source/dev/xen/timer/timer.c?im=3#L252

This should help reduce the latency.

The (void ) here is pointless AFAICT.