Pavel Emelianov wrote:
> Patrick McHardy wrote:
>
>>I'm going to push my latest patches to Dave today, the easiest way is
>>probably is you just add whatever you need to the API afterwards.
>>
>
>
> OK. Dave didn't object against the driver. Hope he will accept it as well.
>
> I have also found
Patrick McHardy wrote:
> Pavel Emelianov wrote:
>> Patrick McHardy wrote:
>>
>>> The question is how to proceed. I haven't read all mails yet, but it
>>> seems there is some disagreement about whether to create all devices
>>> in the same namespace and move them later or create them directly in
>>
Pavel Emelianov wrote:
> Patrick McHardy wrote:
>
>>The question is how to proceed. I haven't read all mails yet, but it
>>seems there is some disagreement about whether to create all devices
>>in the same namespace and move them later or create them directly in
>
>
> The agreement was that we c
Patrick McHardy wrote:
> Pavel Emelianov wrote:
>> Patrick McHardy wrote:
>>
>
+ skb->pkt_type = PACKET_HOST;
+ skb->protocol = eth_type_trans(skb, rcv);
+ if (dev->features & NETIF_F_NO_CSUM)
+ skb->ip_summed = rcv_priv->ip_summed;
+
+ dst_release(skb->d
Ben Greear wrote:
> Pavel Emelianov wrote:
>
>>> I would also like some way to identify veth from other device types,
>>> preferably
>>> something like a value in sysfs. However, that should not hold up
>>>
>>
>>
>> We can do this with ethtool. It can get and print the driver name of
>> the
Pavel Emelianov wrote:
> Patrick McHardy wrote:
>
>>>+skb->pkt_type = PACKET_HOST;
>>>+skb->protocol = eth_type_trans(skb, rcv);
>>>+if (dev->features & NETIF_F_NO_CSUM)
>>>+skb->ip_summed = rcv_priv->ip_summed;
>>>+
>>>+dst_release(skb->dst);
>>>+skb->dst = NULL;
Carl-Daniel Hailfinger wrote:
On 08.06.2007 19:00, Ben Greear wrote:
I have another sysfs patch that allows setting a default skb->mark for
an interface so that you can set the skb->mark
before it hits the connection tracking logic, but I'm been told this one
has very little chance
of getting in
On 08.06.2007 19:00, Ben Greear wrote:
> I have another sysfs patch that allows setting a default skb->mark for
> an interface so that you can set the skb->mark
> before it hits the connection tracking logic, but I'm been told this one
> has very little chance
> of getting into the kernel. The skb
Pavel Emelianov wrote:
Ben Greear wrote:
[snip]
I would also like some way to identify veth from other device types,
preferably
something like a value in sysfs. However, that should not hold up
We can do this with ethtool. It can get and print the driver name of
the device.
Ben Greear wrote:
[snip]
>>> I would also like some way to identify veth from other device types,
>>> preferably
>>> something like a value in sysfs. However, that should not hold up
>>>
>>
>> We can do this with ethtool. It can get and print the driver name of
>> the device.
>>
> I thi
Pavel Emelianov wrote:
Hmm... The loopback must be doing bad things then. It first calls
eth_type_trans and then accounts for the new skb->len.
Perhaps it should be changed. e100 calculates the entire
frame as far as I can tell, and e1000 and tg3 do it in hardware
(not sure what all they are
Ben Greear wrote:
> Pavel Emelianov wrote:
>> Ben Greear wrote:
>>
>>> Pavel Emelianov wrote:
>>>
Veth stands for Virtual ETHernet. It is a simple tunnel driver
that works at the link layer and looks like a pair of ethernet
devices interconnected with each other.
Pavel Emelianov wrote:
Ben Greear wrote:
Pavel Emelianov wrote:
Veth stands for Virtual ETHernet. It is a simple tunnel driver
that works at the link layer and looks like a pair of ethernet
devices interconnected with each other.
As Dave mentioned, there is already a driver k
Pavel Emelianov wrote:
Daniel Lezcano wrote:
Pavel Emelianov wrote:
I did this at the very first version, but Alexey showed me that this
would be wrong. Look. When we create the second device it must be in
the other namespace as it is useless to have them in one namespace.
But if we have the de
Ben Greear wrote:
> Pavel Emelianov wrote:
>> Veth stands for Virtual ETHernet. It is a simple tunnel driver
>> that works at the link layer and looks like a pair of ethernet
>> devices interconnected with each other.
>>
> As Dave mentioned, there is already a driver known as 'veth'. Maybe borr
>>
>> no one is against generic code and ability to create 2 interfaces in
>> *one* namespace.
>> (Like we currently allow to do so in OpenVZ)
>>
>> However, believe me, moving an interface is a *hard* operation. Much
>> harder then netdev
>> register from the scratch.
>>
>> Because it requires to
Pavel Emelianov wrote:
Veth stands for Virtual ETHernet. It is a simple tunnel driver
that works at the link layer and looks like a pair of ethernet
devices interconnected with each other.
As Dave mentioned, there is already a driver known as 'veth'. Maybe borrow
the etun name as well?
I wo
Daniel Lezcano wrote:
> Pavel Emelianov wrote:
I did this at the very first version, but Alexey showed me that this
would be wrong. Look. When we create the second device it must be in
the other namespace as it is useless to have them in one namespace.
But if we have the device
Kirill Korotaev wrote:
Deniel,
Daniel Lezcano wrote:
Pavel Emelianov wrote:
I did this at the very first version, but Alexey showed me that this
would be wrong. Look. When we create the second device it must be in
the other namespace as it is useless to have them in one namespace.
But
Deniel,
Daniel Lezcano wrote:
> Pavel Emelianov wrote:
>
I did this at the very first version, but Alexey showed me that this
would be wrong. Look. When we create the second device it must be in
the other namespace as it is useless to have them in one namespace.
But if we have the
Pavel Emelianov wrote:
I did this at the very first version, but Alexey showed me that this
would be wrong. Look. When we create the second device it must be in
the other namespace as it is useless to have them in one namespace.
But if we have the device in the other namespace the RTNL_NEWLINK
me
Veth stands for Virtual ETHernet. It is a simple tunnel driver
that works at the link layer and looks like a pair of ethernet
devices interconnected with each other.
Mainly it allows to communicate between network namespaces
but it can be used as is as well.
Eric recently sent a similar driver c
>> I did this at the very first version, but Alexey showed me that this
>> would be wrong. Look. When we create the second device it must be in
>> the other namespace as it is useless to have them in one namespace.
>> But if we have the device in the other namespace the RTNL_NEWLINK
>> message from
David Miller wrote:
From: Kirill Korotaev <[EMAIL PROTECTED]>
Date: Thu, 07 Jun 2007 12:14:29 +0400
David Miller wrote:
From: Pavel Emelianov <[EMAIL PROTECTED]>
Date: Wed, 06 Jun 2007 19:11:38 +0400
Veth stands for Virtual ETHernet. It is a simple tunnel driver
that works at the link layer
Pavel Emelianov wrote:
Patrick McHardy wrote:
Pavel Emelianov wrote:
Veth stands for Virtual ETHernet. It is a simple tunnel driver
that works at the link layer and looks like a pair of ethernet
devices interconnected with each other.
Mainly it allows to communicate between network nam
From: Kirill Korotaev <[EMAIL PROTECTED]>
Date: Thu, 07 Jun 2007 12:14:29 +0400
> David Miller wrote:
> > From: Pavel Emelianov <[EMAIL PROTECTED]>
> > Date: Wed, 06 Jun 2007 19:11:38 +0400
> >
> >
> >>Veth stands for Virtual ETHernet. It is a simple tunnel driver
> >>that works at the link laye
David Miller wrote:
> From: Pavel Emelianov <[EMAIL PROTECTED]>
> Date: Wed, 06 Jun 2007 19:11:38 +0400
>
>
>>Veth stands for Virtual ETHernet. It is a simple tunnel driver
>>that works at the link layer and looks like a pair of ethernet
>>devices interconnected with each other.
>
>
> I would s
Patrick McHardy wrote:
> Pavel Emelianov wrote:
>> Veth stands for Virtual ETHernet. It is a simple tunnel driver
>> that works at the link layer and looks like a pair of ethernet
>> devices interconnected with each other.
>>
>> Mainly it allows to communicate between network namespaces but
>> it c
From: Daniel Lezcano <[EMAIL PROTECTED]>
Date: Wed, 06 Jun 2007 22:38:11 +0200
> Perhaps, a name like "epipe" or "npipe", which reflects what does the
> device, is more appropriate ?
'npipe' (Network PIPE) or 'epipe' (Ethernet PIPE) are fine with me.
-
To unsubscribe from this list: send the lin
David Miller wrote:
From: Pavel Emelianov <[EMAIL PROTECTED]>
Date: Wed, 06 Jun 2007 19:11:38 +0400
Veth stands for Virtual ETHernet. It is a simple tunnel driver
that works at the link layer and looks like a pair of ethernet
devices interconnected with each other.
I would suggest cho
From: Pavel Emelianov <[EMAIL PROTECTED]>
Date: Wed, 06 Jun 2007 19:11:38 +0400
> Veth stands for Virtual ETHernet. It is a simple tunnel driver
> that works at the link layer and looks like a pair of ethernet
> devices interconnected with each other.
I would suggest choosing a different name.
'
On Wed, 06 Jun 2007 19:11:38 +0400
Pavel Emelianov <[EMAIL PROTECTED]> wrote:
> Veth stands for Virtual ETHernet. It is a simple tunnel driver
> that works at the link layer and looks like a pair of ethernet
> devices interconnected with each other.
>
> Mainly it allows to communicate between net
Pavel Emelianov wrote:
> +MODULE_DESCRIPTION("Virtual Ethernet Tunnel");
> +MODULE_LICENSE("GPL v2");
This seems to be missing MODULE_ALIAS_RTNL_LINK("veth");
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Pavel Emelianov wrote:
> Veth stands for Virtual ETHernet. It is a simple tunnel driver
> that works at the link layer and looks like a pair of ethernet
> devices interconnected with each other.
>
> Mainly it allows to communicate between network namespaces but
> it can be used as is as well.
>
>
Veth stands for Virtual ETHernet. It is a simple tunnel driver
that works at the link layer and looks like a pair of ethernet
devices interconnected with each other.
Mainly it allows to communicate between network namespaces but
it can be used as is as well.
Eric recently sent a similar driver ca
35 matches
Mail list logo
