Juha-Matti Tilli(jmtilli) replied on github web page:

example/generator/.gitignore
line 3
@@ -1 +1,3 @@
 odp_generator
+*.log
+*.trs


Comment:
It isn't, at least in the master version on which this branch is based.

> Juha-Matti Tilli(jmtilli) wrote:
> This is taken from the .pcap pktio, and incremented by one to make it 
> distinct from the .pcap MAC address. But agree, an internal API to generate 
> the MAC address would be great. It needs to be made sure the multicast bit is 
> not being set, then.


>> Juha-Matti Tilli(jmtilli) wrote:
>> This will also be fixed in the next version.


>>> Juha-Matti Tilli(jmtilli) wrote:
>>> I'll fix in the next version.


>>>> Juha-Matti Tilli(jmtilli) wrote:
>>>> I'm not entirely sure about this... If the programmer wants to wait 
>>>> indefinitely, that's perhaps what we should do, which is indeed what is 
>>>> done now. The odp_pktio_stop() comment should perhaps be made to the PR 
>>>> #341. A good question is do we really need the empty readfds fd_set. 
>>>> Probably we could do without it.


>>>>> Juha-Matti Tilli(jmtilli) wrote:
>>>>> Will do. This will result in a checkpatch warning then, but if that is 
>>>>> not an obstacle to a merge, I can do this.


>>>>>> Juha-Matti Tilli(jmtilli) wrote:
>>>>>> Ok, the only reason I used this call was to increase code coverage. But 
>>>>>> is it deprecated? I grepped through the repository, finding to evidence 
>>>>>> that any API having the name mtu would be deprecated...


>>>>>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>>>>>> This should be supportable also. Just like it is done in other software 
>>>>>>> interfaces.


>>>>>>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>>>>>>> Maybe we should add internal API to generate random (or semi-random) 
>>>>>>>> local MAC-addresses with L bit being set?


>>>>>>>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>>>>>>>> Just use ODP_UNUSED and forget about checkpatch being unoptimal here. 


>>>>>>>>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>>>>>>>>> just exit $STATUS. This would allow underlying program to return 42 
>>>>>>>>>> to mark the test as skipped


>>>>>>>>>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>>>>>>>>>> this should go under `if test_example` 


>>>>>>>>>>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>>>>>>>>>>> I think this should be now in one of top-level .gitignore files.


>>>>>>>>>>>>> Dmitry Eremin-Solenikov(lumag) wrote:
>>>>>>>>>>>>> This should probably go to a separate PR. And ideally examples 
>>>>>>>>>>>>> should not add much to code coverage on top of tests, so you 
>>>>>>>>>>>>> might want also to add code to api testcases.


>>>>>>>>>>>>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>>>>>>>>>>>>> `odp_pktio_mtu()` is a deprecated API and should not be used in 
>>>>>>>>>>>>>> new code.


>>>>>>>>>>>>>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>>>>>>>>>>>>>> Where does this "magic number" come from? Why not 
>>>>>>>>>>>>>>> `00:00:00:00:00:00`?


>>>>>>>>>>>>>>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>>>>>>>>>>>>>>> This is a deprecated API. Not sure we need to include it for a 
>>>>>>>>>>>>>>>> new Pktio type.


>>>>>>>>>>>>>>>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>>>>>>>>>>>>>>>> The parameter should be `num`, not `len` here.


>>>>>>>>>>>>>>>>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>>>>>>>>>>>>>>>>> `odp_packet_free_multi()` would be better here.


>>>>>>>>>>>>>>>>>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>>>>>>>>>>>>>>>>>> Same comments about `ODP_PKTIN_WAIT` here.


>>>>>>>>>>>>>>>>>>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>>>>>>>>>>>>>>>>>>> Shouldn't it be an error to try to receive from a null 
>>>>>>>>>>>>>>>>>>>> device with `ODP_PKTIN_WAIT` since such a call would never 
>>>>>>>>>>>>>>>>>>>> complete? Alternately one could support such semantics and 
>>>>>>>>>>>>>>>>>>>> simply wait indefinitely until `odp_pktio_stop()` is 
>>>>>>>>>>>>>>>>>>>> called to stop the interface.
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Actually, looking at the semantics of `odp_pktio_stop()` 
>>>>>>>>>>>>>>>>>>>> we're not precise about what happens if there are pending 
>>>>>>>>>>>>>>>>>>>> `odp_pktio_recv_tmo()` call(s) on the interface at the 
>>>>>>>>>>>>>>>>>>>> time `odp_pktio_stop()` is called. Presumably these should 
>>>>>>>>>>>>>>>>>>>> be terminated, reporting no packets received when the stop 
>>>>>>>>>>>>>>>>>>>> call is made.


>>>>>>>>>>>>>>>>>>>>> Bill Fischofer(Bill-Fischofer-Linaro) wrote:
>>>>>>>>>>>>>>>>>>>>> In this case it's probably better to be consistent and 
>>>>>>>>>>>>>>>>>>>>> use `(void)pktio_entry` and `(void)index` as well. Mixing 
>>>>>>>>>>>>>>>>>>>>> this idiom with `ODP_UNUSED` looks odd. It also needs no 
>>>>>>>>>>>>>>>>>>>>> explanation as both are acceptable.


https://github.com/Linaro/odp/pull/365#discussion_r158597273
updated_at 2017-12-24 09:38:55

Reply via email to