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

Re: [Xen-devel] xen-netback notify DomU to send ARP.



>>> On 09.01.13 at 16:37, Jason Luan <luanjianhai@xxxxxxx> wrote:
> ä 2013å01æ09æ 21:44, Jan Beulich åé:
>>>>> On 09.01.13 at 13:28, jianhai luan <jianhai.luan@xxxxxxxxxx> wrote:
>>>>> + switch (event) {
>>>>> + case NETDEV_NOTIFY_PEERS:
>>>>> +         /* Notify frontend to Send gratuitous ARP */
>>>>> +         xenbus_switch_state(be->dev, XenbusStateInitialised);
>>>>> +         xenbus_switch_state(be->dev, );
>>>> This is the sort of change that clearly isn't acceptable, as I don't
>>>> think you have ways to check _all_ existing frontends for their
>>>> compatibility with this. A connected -> connected transition
>>>> might be acceptable (that was done in the block frontend too, for
>>>> implementing dynamic resize), but will likely need to be
>>>> accompanied by a frontend side patch to handle that (which so
>>>> far should be a no-op).
>>> The latest xen net-frontent driver have handled the condition. State
>>> XenbusStateInitialised will do nothing,
>>> but change to XenbusStateConnected will trigger
>>> netdev_notify_peers(netdev) to send ARP.
>> Did you read my earlier reply carefully? You still only talk about
>> (upstream) Linux netfront, but this is not the only (possible)
>> frontend. You should not invoke state transitions that can -
>> even if only theoretically - blow up frontends. And afaict the
> I only want to notify xen-netfront. I don't know what is better way?
> To attainthegoal, i try to modify virtual interrupt, but the way is
> morecomplicated,modified and working. So, i give up the way.
> Would you like to give some suggestion about how to notify xen-netfront?
>> only thing you can safely assume frontends ought to tolerate
>> are transitions from Connected to Connected (or more
>> generally from one state to the same one, but the other
>> states aren't useful here, except maybe the Reconfigur* ones).
> Sorry for that. At the beginning the patch be applied in kernel 2.6.18 to
> fixed one issue. Only XenbusStateInitialised and XenbusStateClosed ( Not
> Reconfigure* one) don't any thing, so i choose the XenbusStateInitialised.
> Do you suggestion that i choose Reconfigure*?

I already said that I think that only a Connected->Connected
transition is to be considered here. Bringing up Reconfigur* was
just to point out that there are other states available that could
be used, but you'd first need to make sure that (a) they aren't
used for anything else and (b) frontends can reasonably be
expected to deal with (ignore) them when not originally aware
of them (as opposed to a Connected->Connected transition,
which all frontends ought to be able to deal with afaict).

Also, when you reply to earlier mails, could you - in order to make
the result readable - insert blank lines between the quoted text
and your responses, please?

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

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