On 4/12/2019 5:35 PM, Ferruh Yigit wrote:
> On 3/28/2019 8:53 PM, Stephen Hemminger wrote:
>> If mbuf is shared then rte_vlan_insert() would clobber the original
>> Ethernet header. The changed version handles this by getting
>> an mbuf that will hold the new Ethernet and VLAN header followed
>> by
On 3/28/2019 8:53 PM, Stephen Hemminger wrote:
> If mbuf is shared then rte_vlan_insert() would clobber the original
> Ethernet header. The changed version handles this by getting
> an mbuf that will hold the new Ethernet and VLAN header followed
> by another mbuf (cloned) for the data.
Hi Stephen
On 4/4/19 7:54 PM, Stephen Hemminger wrote:
On Sat, 30 Mar 2019 08:41:33 -0400
Chas Williams <3ch...@gmail.com> wrote:
Unfortunately, I think the complete fix is more complicated than this.
Drivers that use rte_vlan_insert don't anticipate that the mbuf might
change and that (hardware) trans
On Sat, 30 Mar 2019 08:41:33 -0400
Chas Williams <3ch...@gmail.com> wrote:
> Unfortunately, I think the complete fix is more complicated than this.
> Drivers that use rte_vlan_insert don't anticipate that the mbuf might
> change and that (hardware) transmit can fail.
>
> They make a copy of the m
Unfortunately, I think the complete fix is more complicated than this.
Drivers that use rte_vlan_insert don't anticipate that the mbuf might
change and that (hardware) transmit can fail.
They make a copy of the mbuf pointer from the incoming transmit list
and don't update the original if rte_vlan
If mbuf is shared then rte_vlan_insert() would clobber the original
Ethernet header. The changed version handles this by getting
an mbuf that will hold the new Ethernet and VLAN header followed
by another mbuf (cloned) for the data.
Fixes: c974021a5949 ("ether: add soft vlan encap/decap")
Signed-o
6 matches
Mail list logo
