diff mbox series

[v2] kni: implement header_ops parse method

Message ID 20190410103003.42385-1-iryzhov@nfware.com (mailing list archive)
State Accepted, archived
Delegated to: Thomas Monjalon
Headers
Series [v2] kni: implement header_ops parse method |

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/Intel-compilation success Compilation OK
ci/intel-Performance-Testing success Performance Testing PASS
ci/mellanox-Performance-Testing success Performance Testing PASS

Commit Message

Igor Ryzhov April 10, 2019, 10:30 a.m. UTC 
  It allows applications running packet sockets over KNI interfaces to get
source Ethernet addresses of packets received using recvfrom function.

Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
---
v2:
Use eth_header_parse instead of own implementation.
---
 kernel/linux/kni/kni_net.c | 1 +
 1 file changed, 1 insertion(+)

Comments

Ferruh Yigit April 12, 2019, 2:52 p.m. UTC | #1 
On 4/10/2019 11:30 AM, Igor Ryzhov wrote:
> It allows applications running packet sockets over KNI interfaces to get
> source Ethernet addresses of packets received using recvfrom function.
> 
> Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>

Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>


Hi Igor,

I tested this with a quick application on top of kni interfaces, that reads and
prints the 'sll_halen', but the last two bytes of the mac address are always
zero, it is quite possible that something is not right in the test app, but
before spending any time on it, can you please confirm this is working fine for you?
Ferruh Yigit April 12, 2019, 2:53 p.m. UTC | #2 
On 4/12/2019 3:52 PM, Ferruh Yigit wrote:
> On 4/10/2019 11:30 AM, Igor Ryzhov wrote:
>> It allows applications running packet sockets over KNI interfaces to get
>> source Ethernet addresses of packets received using recvfrom function.
>>
>> Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
> 
> Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
> 
> 
> Hi Igor,
> 
> I tested this with a quick application on top of kni interfaces, that reads and
> prints the 'sll_halen', but the last two bytes of the mac address are always

I mean 'sll_addr', 'sll_halen' is right (6).

> zero, it is quite possible that something is not right in the test app, but
> before spending any time on it, can you please confirm this is working fine for you?
>
Igor Ryzhov April 12, 2019, 5:12 p.m. UTC | #3 
Hi Ferruh,

I didn't test it with any special application, but FRR's ISIS works for me
after the patch, and it didn't work before.

Igor

On Fri, Apr 12, 2019 at 5:53 PM Ferruh Yigit <ferruh.yigit@intel.com> wrote:

> On 4/12/2019 3:52 PM, Ferruh Yigit wrote:
> > On 4/10/2019 11:30 AM, Igor Ryzhov wrote:
> >> It allows applications running packet sockets over KNI interfaces to get
> >> source Ethernet addresses of packets received using recvfrom function.
> >>
> >> Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
> >
> > Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
> >
> >
> > Hi Igor,
> >
> > I tested this with a quick application on top of kni interfaces, that
> reads and
> > prints the 'sll_halen', but the last two bytes of the mac address are
> always
>
> I mean 'sll_addr', 'sll_halen' is right (6).
>
> > zero, it is quite possible that something is not right in the test app,
> but
> > before spending any time on it, can you please confirm this is working
> fine for you?
> >
>
>
Ferruh Yigit April 12, 2019, 5:15 p.m. UTC | #4 
On 4/12/2019 6:12 PM, Igor Ryzhov wrote:
> Hi Ferruh,
> 
> I didn't test it with any special application, but FRR's ISIS works for me after
> the patch, and it didn't work before.

That is good enough, and by work you mean that you are able to get correct value
on 'sll_addr', right?

> 
> Igor
> 
> On Fri, Apr 12, 2019 at 5:53 PM Ferruh Yigit <ferruh.yigit@intel.com
> <mailto:ferruh.yigit@intel.com>> wrote:
> 
>     On 4/12/2019 3:52 PM, Ferruh Yigit wrote:
>     > On 4/10/2019 11:30 AM, Igor Ryzhov wrote:
>     >> It allows applications running packet sockets over KNI interfaces to get
>     >> source Ethernet addresses of packets received using recvfrom function.
>     >>
>     >> Signed-off-by: Igor Ryzhov <iryzhov@nfware.com <mailto:iryzhov@nfware.com>>
>     >
>     > Acked-by: Ferruh Yigit <ferruh.yigit@intel.com
>     <mailto:ferruh.yigit@intel.com>>
>     >
>     >
>     > Hi Igor,
>     >
>     > I tested this with a quick application on top of kni interfaces, that
>     reads and
>     > prints the 'sll_halen', but the last two bytes of the mac address are always
> 
>     I mean 'sll_addr', 'sll_halen' is right (6).
> 
>     > zero, it is quite possible that something is not right in the test app, but
>     > before spending any time on it, can you please confirm this is working
>     fine for you?
>     >
>
Igor Ryzhov April 15, 2019, 8:37 a.m. UTC | #5 
Hi Ferruh,

To be absolutely sure, I performed a test using the test application.

When I send pings from an interface:
3: ens8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:c8:79:c6 brd ff:ff:ff:ff:ff:ff

Here is what's in sockaddr_ll:
$2 = {sll_family = 0x11, sll_protocol = 0x8, sll_ifindex = 0x2, sll_hatype
= 0x1, sll_pkttype = 0x0, sll_halen = 0x6, sll_addr = {
    0x52, 0x54, 0x0, 0xc8, 0x79, 0xc6, 0x0, 0x0}}

So everything works as expected – the address in sll_addr is correct.
Last two bytes are zero because the length of sll_addr is 8, however,
Ethernet length is 6.

Igor

On Fri, Apr 12, 2019 at 8:15 PM Ferruh Yigit <ferruh.yigit@intel.com> wrote:

> On 4/12/2019 6:12 PM, Igor Ryzhov wrote:
> > Hi Ferruh,
> >
> > I didn't test it with any special application, but FRR's ISIS works for
> me after
> > the patch, and it didn't work before.
>
> That is good enough, and by work you mean that you are able to get correct
> value
> on 'sll_addr', right?
>
> >
> > Igor
> >
> > On Fri, Apr 12, 2019 at 5:53 PM Ferruh Yigit <ferruh.yigit@intel.com
> > <mailto:ferruh.yigit@intel.com>> wrote:
> >
> >     On 4/12/2019 3:52 PM, Ferruh Yigit wrote:
> >     > On 4/10/2019 11:30 AM, Igor Ryzhov wrote:
> >     >> It allows applications running packet sockets over KNI interfaces
> to get
> >     >> source Ethernet addresses of packets received using recvfrom
> function.
> >     >>
> >     >> Signed-off-by: Igor Ryzhov <iryzhov@nfware.com <mailto:
> iryzhov@nfware.com>>
> >     >
> >     > Acked-by: Ferruh Yigit <ferruh.yigit@intel.com
> >     <mailto:ferruh.yigit@intel.com>>
> >     >
> >     >
> >     > Hi Igor,
> >     >
> >     > I tested this with a quick application on top of kni interfaces,
> that
> >     reads and
> >     > prints the 'sll_halen', but the last two bytes of the mac address
> are always
> >
> >     I mean 'sll_addr', 'sll_halen' is right (6).
> >
> >     > zero, it is quite possible that something is not right in the test
> app, but
> >     > before spending any time on it, can you please confirm this is
> working
> >     fine for you?
> >     >
> >
>
>
Ferruh Yigit April 15, 2019, 3:49 p.m. UTC | #6 
On 4/15/2019 9:37 AM, Igor Ryzhov wrote:
> Hi Ferruh,
> 
> To be absolutely sure, I performed a test using the test application.
> 
> When I send pings from an interface:
> 3: ens8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
> UP mode DEFAULT group default qlen 1000
>     link/ether 52:54:00:c8:79:c6 brd ff:ff:ff:ff:ff:ff
> 
> Here is what's in sockaddr_ll:
> $2 = {sll_family = 0x11, sll_protocol = 0x8, sll_ifindex = 0x2, sll_hatype
> = 0x1, sll_pkttype = 0x0, sll_halen = 0x6, sll_addr = {
>     0x52, 0x54, 0x0, 0xc8, 0x79, 0xc6, 0x0, 0x0}}
> 
> So everything works as expected – the address in sll_addr is correct.
> Last two bytes are zero because the length of sll_addr is 8, however,
> Ethernet length is 6.

Perfect, thanks for confirming, I am OK with the patch.


For my case sll_halen = 0x6 but only first 4 byte of the sll_addr was the valid,
so it was not the issue of size of sll_addr being 8, anyway it was quick dirty
app, something should be wrong, I believe not need to dig it more.

> 
> Igor
> 
> On Fri, Apr 12, 2019 at 8:15 PM Ferruh Yigit <ferruh.yigit@intel.com> wrote:
> 
>> On 4/12/2019 6:12 PM, Igor Ryzhov wrote:
>>> Hi Ferruh,
>>>
>>> I didn't test it with any special application, but FRR's ISIS works for
>> me after
>>> the patch, and it didn't work before.
>>
>> That is good enough, and by work you mean that you are able to get correct
>> value
>> on 'sll_addr', right?
>>
>>>
>>> Igor
>>>
>>> On Fri, Apr 12, 2019 at 5:53 PM Ferruh Yigit <ferruh.yigit@intel.com
>>> <mailto:ferruh.yigit@intel.com>> wrote:
>>>
>>>     On 4/12/2019 3:52 PM, Ferruh Yigit wrote:
>>>     > On 4/10/2019 11:30 AM, Igor Ryzhov wrote:
>>>     >> It allows applications running packet sockets over KNI interfaces
>> to get
>>>     >> source Ethernet addresses of packets received using recvfrom
>> function.
>>>     >>
>>>     >> Signed-off-by: Igor Ryzhov <iryzhov@nfware.com <mailto:
>> iryzhov@nfware.com>>
>>>     >
>>>     > Acked-by: Ferruh Yigit <ferruh.yigit@intel.com
>>>     <mailto:ferruh.yigit@intel.com>>
>>>     >
>>>     >
>>>     > Hi Igor,
>>>     >
>>>     > I tested this with a quick application on top of kni interfaces,
>> that
>>>     reads and
>>>     > prints the 'sll_halen', but the last two bytes of the mac address
>> are always
>>>
>>>     I mean 'sll_addr', 'sll_halen' is right (6).
>>>
>>>     > zero, it is quite possible that something is not right in the test
>> app, but
>>>     > before spending any time on it, can you please confirm this is
>> working
>>>     fine for you?
>>>     >
>>>
>>
>>
Thomas Monjalon April 19, 2019, 10:36 a.m. UTC | #7 
12/04/2019 16:52, Ferruh Yigit:
> On 4/10/2019 11:30 AM, Igor Ryzhov wrote:
> > It allows applications running packet sockets over KNI interfaces to get
> > source Ethernet addresses of packets received using recvfrom function.
> > 
> > Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
> 
> Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>

Applied, thanks
diff mbox series

Patch

diff --git a/kernel/linux/kni/kni_net.c b/kernel/linux/kni/kni_net.c
index be9e6b0b9..ad8365877 100644
--- a/kernel/linux/kni/kni_net.c
+++ b/kernel/linux/kni/kni_net.c
@@ -744,6 +744,7 @@  kni_net_change_carrier(struct net_device *dev, bool new_carrier)
 
 static const struct header_ops kni_net_header_ops = {
 	.create  = kni_net_header,
+	.parse   = eth_header_parse,
 #ifdef HAVE_REBUILD_HEADER
 	.rebuild = kni_net_rebuild_header,
 #endif /* < 4.1.0  */