> >On Tue, 1 Dec 2015 21:53:59 +0000 >Harish Patil <harish.patil at qlogic.com> wrote: > >> > >> >Anyone to review please? >> > >> >2015-11-03 12:26, Chas Williams: >> >> Signed-off-by: Chas Williams <3chas3 at gmail.com> >> >> --- >> >> drivers/net/bnx2x/bnx2x.c | 3 ++- >> >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> >> >> diff --git a/drivers/net/bnx2x/bnx2x.c b/drivers/net/bnx2x/bnx2x.c >> >> index fed7a06..76444eb 100644 >> >> --- a/drivers/net/bnx2x/bnx2x.c >> >> +++ b/drivers/net/bnx2x/bnx2x.c >> >> @@ -2169,7 +2169,8 @@ int bnx2x_tx_encap(struct bnx2x_tx_queue *txq, >> >>struct rte_mbuf **m_head, int m_p >> >> struct ether_hdr *eh >> >> = rte_pktmbuf_mtod(m0, struct >>ether_hdr *); >> >> >> >> - tx_start_bd->vlan_or_ethertype = >>eh->ether_type; >> >> + tx_start_bd->vlan_or_ethertype >> >> + = >>rte_cpu_to_le_16(rte_be_to_cpu_16(eh->ether_type)); >> >> } >> >> } >> > >> > >> >> Acked-by: Harish Patil <harish.patil at qlogic.com> >> >> >> Minor question - any specific reason to use rte_be_to_cpu_16() on >> ether_type alone before converting from native order to le16? > >ether_type is in network byte order (big endian) >and hardware wants little endian. On x86 the second step is a nop. >
Thanks. Yes the question was for second step, second step would be a no-op on x86 - thanks for clarifying. ________________________________ This message and any attached documents contain information from the sending company or its parent company(s), subsidiaries, divisions or branch offices that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.
