| Message ID | 1412605552-11129-1-git-send-email-petri.savolainen@linaro.org |
|---|---|
| State | Accepted |
| Commit | 7a6c3779f1495166ae10697f7ae7bc26a266583f |
| Headers | show |
Can we coordinate these changes with the ongoing Packet API design work? Simply making code changes without that coordination at this point is going to get confusing. Not saying there may not be good reasons for these changes, but we want everything to sync up since the ODP Test Suite is going to be written from the design docs, not from the code. Thanks. Bill On Mon, Oct 6, 2014 at 9:25 AM, Petri Savolainen < petri.savolainen@linaro.org> wrote: > Rename odp_buffer_from_packet() to odp_packet_to_buffer(). > It's a function of packet API vs buffer API. > > Signed-off-by: Petri Savolainen <petri.savolainen@linaro.org> > --- > example/generator/odp_generator.c | 2 +- > example/ipsec/odp_ipsec.c | 10 +++++----- > helper/include/odph_packet.h | 6 +++--- > platform/linux-generic/include/api/odp_packet.h | 6 +++--- > platform/linux-generic/odp_crypto.c | 4 ++-- > platform/linux-generic/odp_packet.c | 8 ++++---- > platform/linux-generic/odp_packet_io.c | 6 +++--- > 7 files changed, 21 insertions(+), 21 deletions(-) > > diff --git a/example/generator/odp_generator.c > b/example/generator/odp_generator.c > index 6055324..5538d0c 100644 > --- a/example/generator/odp_generator.c > +++ b/example/generator/odp_generator.c > @@ -397,7 +397,7 @@ static void print_pkts(int thr, odp_packet_t > pkt_tbl[], unsigned len) > > odp_atomic_inc_u64(&counters.ip); > rlen += sprintf(msg, "receive Packet proto:IP "); > - buf = odp_buffer_addr(odp_buffer_from_packet(pkt)); > + buf = odp_buffer_addr(odp_packet_to_buffer(pkt)); > ip = (odph_ipv4hdr_t *)(buf + odp_packet_l3_offset(pkt)); > rlen += sprintf(msg + rlen, "id %d ", > odp_be_to_cpu_16(ip->id)); > diff --git a/example/ipsec/odp_ipsec.c b/example/ipsec/odp_ipsec.c > index ec6c87a..56539ba 100644 > --- a/example/ipsec/odp_ipsec.c > +++ b/example/ipsec/odp_ipsec.c > @@ -738,7 +738,7 @@ pkt_disposition_e do_ipsec_in_classify(odp_packet_t > pkt, > *skip = FALSE; > if (odp_crypto_operation(¶ms, > &posted, > - odp_buffer_from_packet(pkt))) { > + odp_packet_to_buffer(pkt))) { > abort(); > } > return (posted) ? PKT_POSTED : PKT_CONTINUE; > @@ -764,7 +764,7 @@ pkt_disposition_e do_ipsec_in_finish(odp_packet_t pkt, > int trl_len = 0; > > /* Check crypto result */ > - event = odp_buffer_from_packet(pkt); > + event = odp_packet_to_buffer(pkt); > odp_crypto_get_operation_compl_status(event, &cipher_rc, &auth_rc); > if (!is_crypto_compl_status_ok(&cipher_rc)) > return PKT_DROP; > @@ -935,7 +935,7 @@ pkt_disposition_e do_ipsec_out_classify(odp_packet_t > pkt, > > /* Send packet to the atmoic queue to assign sequence numbers */ > *skip = FALSE; > - odp_queue_enq(seqnumq, odp_buffer_from_packet(pkt)); > + odp_queue_enq(seqnumq, odp_packet_to_buffer(pkt)); > > return PKT_POSTED; > } > @@ -974,7 +974,7 @@ pkt_disposition_e do_ipsec_out_seq(odp_packet_t pkt, > /* Issue crypto request */ > if (odp_crypto_operation(&ctx->ipsec.params, > &posted, > - odp_buffer_from_packet(pkt))) { > + odp_packet_to_buffer(pkt))) { > abort(); > } > return (posted) ? PKT_POSTED : PKT_CONTINUE; > @@ -998,7 +998,7 @@ pkt_disposition_e do_ipsec_out_finish(odp_packet_t pkt, > odph_ipv4hdr_t *ip; > > /* Check crypto result */ > - event = odp_buffer_from_packet(pkt); > + event = odp_packet_to_buffer(pkt); > odp_crypto_get_operation_compl_status(event, &cipher_rc, &auth_rc); > if (!is_crypto_compl_status_ok(&cipher_rc)) > return PKT_DROP; > diff --git a/helper/include/odph_packet.h b/helper/include/odph_packet.h > index c18f48d..3d53593 100644 > --- a/helper/include/odph_packet.h > +++ b/helper/include/odph_packet.h > @@ -31,7 +31,7 @@ extern "C" { > */ > static inline int odph_packet_is_valid(odp_packet_t pkt) > { > - odp_buffer_t buf = odp_buffer_from_packet(pkt); > + odp_buffer_t buf = odp_packet_to_buffer(pkt); > > return odp_buffer_is_valid(buf); > } > @@ -67,7 +67,7 @@ static inline odp_packet_t > odph_packet_alloc(odp_buffer_pool_t pool_id) > */ > static inline void odph_packet_free(odp_packet_t pkt) > { > - odp_buffer_t buf = odp_buffer_from_packet(pkt); > + odp_buffer_t buf = odp_packet_to_buffer(pkt); > > odp_buffer_free(buf); > } > @@ -84,7 +84,7 @@ static inline void odph_packet_free(odp_packet_t pkt) > */ > static inline size_t odph_packet_buf_size(odp_packet_t pkt) > { > - odp_buffer_t buf = odp_buffer_from_packet(pkt); > + odp_buffer_t buf = odp_packet_to_buffer(pkt); > > return odp_buffer_size(buf); > } > diff --git a/platform/linux-generic/include/api/odp_packet.h > b/platform/linux-generic/include/api/odp_packet.h > index 316279b..8204000 100644 > --- a/platform/linux-generic/include/api/odp_packet.h > +++ b/platform/linux-generic/include/api/odp_packet.h > @@ -63,7 +63,7 @@ typedef struct odp_packet_seg_info_t { > void odp_packet_init(odp_packet_t pkt); > > /** > - * Convert from packet handle to buffer handle > + * Convert a buffer handle to a packet handle > * > * @param buf Buffer handle > * > @@ -72,13 +72,13 @@ void odp_packet_init(odp_packet_t pkt); > odp_packet_t odp_packet_from_buffer(odp_buffer_t buf); > > /** > - * Convert from buffer handle to packet handle > + * Convert a packet handle to a buffer handle > * > * @param pkt Packet handle > * > * @return Buffer handle > */ > -odp_buffer_t odp_buffer_from_packet(odp_packet_t pkt); > +odp_buffer_t odp_packet_to_buffer(odp_packet_t pkt); > > /** > * Set the packet length > diff --git a/platform/linux-generic/odp_crypto.c > b/platform/linux-generic/odp_crypto.c > index b37ad6b..1475437 100644 > --- a/platform/linux-generic/odp_crypto.c > +++ b/platform/linux-generic/odp_crypto.c > @@ -367,9 +367,9 @@ odp_crypto_operation(odp_crypto_op_params_t *params, > if (odp_unlikely(ODP_PACKET_INVALID == params->out_pkt)) > abort(); > odp_packet_copy(params->out_pkt, params->pkt); > - if (completion_event == > odp_buffer_from_packet(params->pkt)) > + if (completion_event == odp_packet_to_buffer(params->pkt)) > completion_event = > - odp_buffer_from_packet(params->out_pkt); > + odp_packet_to_buffer(params->out_pkt); > odph_packet_free(params->pkt); > params->pkt = ODP_PACKET_INVALID; > } > diff --git a/platform/linux-generic/odp_packet.c > b/platform/linux-generic/odp_packet.c > index 435bc8b..82ea879 100644 > --- a/platform/linux-generic/odp_packet.c > +++ b/platform/linux-generic/odp_packet.c > @@ -41,7 +41,7 @@ odp_packet_t odp_packet_from_buffer(odp_buffer_t buf) > return (odp_packet_t)buf; > } > > -odp_buffer_t odp_buffer_from_packet(odp_packet_t pkt) > +odp_buffer_t odp_packet_to_buffer(odp_packet_t pkt) > { > return (odp_buffer_t)pkt; > } > @@ -58,7 +58,7 @@ size_t odp_packet_get_len(odp_packet_t pkt) > > uint8_t *odp_packet_addr(odp_packet_t pkt) > { > - return odp_buffer_addr(odp_buffer_from_packet(pkt)); > + return odp_buffer_addr(odp_packet_to_buffer(pkt)); > } > > uint8_t *odp_packet_data(odp_packet_t pkt) > @@ -381,8 +381,8 @@ int odp_packet_copy(odp_packet_t pkt_dst, odp_packet_t > pkt_src) > pkt_hdr_dst->buf_hdr.cur_offset = pkt_hdr_src->buf_hdr.cur_offset; > > /* Create a copy of the scatter list */ > - odp_buffer_copy_scatter(odp_buffer_from_packet(pkt_dst), > - odp_buffer_from_packet(pkt_src)); > + odp_buffer_copy_scatter(odp_packet_to_buffer(pkt_dst), > + odp_packet_to_buffer(pkt_src)); > > return 0; > } > diff --git a/platform/linux-generic/odp_packet_io.c > b/platform/linux-generic/odp_packet_io.c > index 0c30f0f..d6f86ce 100644 > --- a/platform/linux-generic/odp_packet_io.c > +++ b/platform/linux-generic/odp_packet_io.c > @@ -431,11 +431,11 @@ odp_buffer_hdr_t *pktin_dequeue(queue_entry_t > *qentry) > > if (pkts > 0) { > pkt = pkt_tbl[0]; > - buf = odp_buffer_from_packet(pkt); > + buf = odp_packet_to_buffer(pkt); > buf_hdr = odp_buf_to_hdr(buf); > > for (i = 1, j = 0; i < pkts; ++i) { > - buf = odp_buffer_from_packet(pkt_tbl[i]); > + buf = odp_packet_to_buffer(pkt_tbl[i]); > tmp_hdr_tbl[j++] = odp_buf_to_hdr(buf); > } > queue_enq_multi(qentry, tmp_hdr_tbl, j); > @@ -467,7 +467,7 @@ int pktin_deq_multi(queue_entry_t *qentry, > odp_buffer_hdr_t *buf_hdr[], int num) > QUEUE_MULTI_MAX); > if (pkts > 0) { > for (i = 0; i < pkts; ++i) { > - buf = odp_buffer_from_packet(pkt_tbl[i]); > + buf = odp_packet_to_buffer(pkt_tbl[i]); > tmp_hdr_tbl[i] = odp_buf_to_hdr(buf); > } > queue_enq_multi(qentry, tmp_hdr_tbl, pkts); > -- > 2.1.1 > > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/lng-odp >
Hi.
Test suite should be written from API documentation, since that’s the contract for users. Arch docs should just provide additional / higher level information, so that API documentation is easier to understand. Too much details in arch doc will duplicate information (without too much added value). Does we need this level of detail (function name for conversions) in arch doc – it’s enough to mention that buf <-> pkt conversion can be done using the packet API.
-Petri
From: ext Bill Fischofer [mailto:bill.fischofer@linaro.org]
Sent: Tuesday, October 07, 2014 12:22 AM
To: Petri Savolainen
Cc: lng-odp-forward
Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function
Can we coordinate these changes with the ongoing Packet API design work? Simply making code changes without that coordination at this point is going to get confusing. Not saying there may not be good reasons for these changes, but we want everything to sync up since the ODP Test Suite is going to be written from the design docs, not from the code.
Thanks.
Bill
I'm not sure I understand this point. The design docs are the API docs. On Tue, Oct 7, 2014 at 7:07 AM, Savolainen, Petri (NSN - FI/Espoo) < petri.savolainen@nsn.com> wrote: > Hi. > > > > Test suite should be written from API documentation, since that’s the > contract for users. Arch docs should just provide additional / higher level > information, so that API documentation is easier to understand. Too much > details in arch doc will duplicate information (without too much added > value). Does we need this level of detail (function name for conversions) > in arch doc – it’s enough to mention that buf <-> pkt conversion can be > done using the packet API. > > > > > > -Petri > > > > > > *From:* ext Bill Fischofer [mailto:bill.fischofer@linaro.org] > *Sent:* Tuesday, October 07, 2014 12:22 AM > *To:* Petri Savolainen > *Cc:* lng-odp-forward > *Subject:* Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > Can we coordinate these changes with the ongoing Packet API design work? > Simply making code changes without that coordination at this point is going > to get confusing. Not saying there may not be good reasons for these > changes, but we want everything to sync up since the ODP Test Suite is > going to be written from the design docs, not from the code. > > > > Thanks. > > > > Bill > > > > >
API doc is generated with Doxygen from the headers. It’s the easiest way to ensure that API definitions (in C code) and documentation are in sync. Arch docs support the doxygen documentation. -Petri From: ext Bill Fischofer [mailto:bill.fischofer@linaro.org] Sent: Tuesday, October 07, 2014 3:54 PM To: Savolainen, Petri (NSN - FI/Espoo) Cc: lng-odp-forward Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function I'm not sure I understand this point. The design docs are the API docs. On Tue, Oct 7, 2014 at 7:07 AM, Savolainen, Petri (NSN - FI/Espoo) <petri.savolainen@nsn.com<mailto:petri.savolainen@nsn.com>> wrote: Hi. Test suite should be written from API documentation, since that’s the contract for users. Arch docs should just provide additional / higher level information, so that API documentation is easier to understand. Too much details in arch doc will duplicate information (without too much added value). Does we need this level of detail (function name for conversions) in arch doc – it’s enough to mention that buf <-> pkt conversion can be done using the packet API. -Petri From: ext Bill Fischofer [mailto:bill.fischofer@linaro.org<mailto:bill.fischofer@linaro.org>] Sent: Tuesday, October 07, 2014 12:22 AM To: Petri Savolainen Cc: lng-odp-forward Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function Can we coordinate these changes with the ongoing Packet API design work? Simply making code changes without that coordination at this point is going to get confusing. Not saying there may not be good reasons for these changes, but we want everything to sync up since the ODP Test Suite is going to be written from the design docs, not from the code. Thanks. Bill
Yes, but continuing the bootstrap, the Google docs are input to the doxygen versions which are integrated with the headers built from it. Agree the doxygen version is intended to be definitive. The prototype APIs we have pre-v1.0 are incomplete and in many cases inconsistent. The arch/design process resolves that and allows us to iterate to the final versions that will be v1.0. Otherwise we're just inventing APIs on the fly with code without any explicit design review. Bill On Tue, Oct 7, 2014 at 7:59 AM, Savolainen, Petri (NSN - FI/Espoo) < petri.savolainen@nsn.com> wrote: > API doc is generated with Doxygen from the headers. It’s the easiest way > to ensure that API definitions (in C code) and documentation are in sync. > > > > Arch docs support the doxygen documentation. > > > > > > -Petri > > > > *From:* ext Bill Fischofer [mailto:bill.fischofer@linaro.org] > *Sent:* Tuesday, October 07, 2014 3:54 PM > *To:* Savolainen, Petri (NSN - FI/Espoo) > *Cc:* lng-odp-forward > *Subject:* Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > I'm not sure I understand this point. The design docs are the API docs. > > > > On Tue, Oct 7, 2014 at 7:07 AM, Savolainen, Petri (NSN - FI/Espoo) < > petri.savolainen@nsn.com> wrote: > > Hi. > > > > Test suite should be written from API documentation, since that’s the > contract for users. Arch docs should just provide additional / higher level > information, so that API documentation is easier to understand. Too much > details in arch doc will duplicate information (without too much added > value). Does we need this level of detail (function name for conversions) > in arch doc – it’s enough to mention that buf <-> pkt conversion can be > done using the packet API. > > > > > > -Petri > > > > > > *From:* ext Bill Fischofer [mailto:bill.fischofer@linaro.org] > *Sent:* Tuesday, October 07, 2014 12:22 AM > *To:* Petri Savolainen > *Cc:* lng-odp-forward > *Subject:* Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > Can we coordinate these changes with the ongoing Packet API design work? > Simply making code changes without that coordination at this point is going > to get confusing. Not saying there may not be good reasons for these > changes, but we want everything to sync up since the ODP Test Suite is > going to be written from the design docs, not from the code. > > > > Thanks. > > > > Bill > > > > > > >
I think that sort of patches should have RFC for better discussion. Due to that changes require everybody to do same changes (all platforms and all odp apps.). It will be nice if we can group such changes when merging because fixing up everything in different repos take some time... Maxim. On 10/07/2014 05:24 PM, Bill Fischofer wrote: > Yes, but continuing the bootstrap, the Google docs are input to the > doxygen versions which are integrated with the headers built from it. > Agree the doxygen version is intended to be definitive. The prototype > APIs we have pre-v1.0 are incomplete and in many cases inconsistent. > The arch/design process resolves that and allows us to iterate to the > final versions that will be v1.0. Otherwise we're just inventing APIs > on the fly with code without any explicit design review. > > Bill > > On Tue, Oct 7, 2014 at 7:59 AM, Savolainen, Petri (NSN - FI/Espoo) > <petri.savolainen@nsn.com <mailto:petri.savolainen@nsn.com>> wrote: > > API doc is generated with Doxygen from the headers. It’s the > easiest way to ensure that API definitions (in C code) and > documentation are in sync. > > Arch docs support the doxygen documentation. > > -Petri > > *From:*ext Bill Fischofer [mailto:bill.fischofer@linaro.org > <mailto:bill.fischofer@linaro.org>] > *Sent:* Tuesday, October 07, 2014 3:54 PM > *To:* Savolainen, Petri (NSN - FI/Espoo) > *Cc:* lng-odp-forward > *Subject:* Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > I'm not sure I understand this point. The design docs are the API > docs. > > On Tue, Oct 7, 2014 at 7:07 AM, Savolainen, Petri (NSN - FI/Espoo) > <petri.savolainen@nsn.com <mailto:petri.savolainen@nsn.com>> wrote: > > Hi. > > Test suite should be written from API documentation, since that’s > the contract for users. Arch docs should just provide additional / > higher level information, so that API documentation is easier to > understand. Too much details in arch doc will duplicate > information (without too much added value). Does we need this > level of detail (function name for conversions) in arch doc – it’s > enough to mention that buf <-> pkt conversion can be done using > the packet API. > > -Petri > > *From:*ext Bill Fischofer [mailto:bill.fischofer@linaro.org > <mailto:bill.fischofer@linaro.org>] > *Sent:* Tuesday, October 07, 2014 12:22 AM > *To:* Petri Savolainen > *Cc:* lng-odp-forward > *Subject:* Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > Can we coordinate these changes with the ongoing Packet API design > work? Simply making code changes without that coordination at this > point is going to get confusing. Not saying there may not be good > reasons for these changes, but we want everything to sync up since > the ODP Test Suite is going to be written from the design docs, > not from the code. > > Thanks. > > Bill > > > > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/lng-odp
Hi, It's not a major architectural change. Just find and replace. If there's nobody against it, could we just merge it and carry on. Implementations can choose to either follow the linux-generic closely or group multiple changes (= update less frequently). It's up to each implementation which strategy works the best. I think it's easier to follow a set of many small changes than few big ones (which seem to rewrite an API in one shot). -Petri > -----Original Message----- > From: lng-odp-bounces@lists.linaro.org [mailto:lng-odp- > bounces@lists.linaro.org] On Behalf Of ext Maxim Uvarov > Sent: Tuesday, October 07, 2014 5:11 PM > To: lng-odp@lists.linaro.org > Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > I think that sort of patches should have RFC for better discussion. Due > to that changes require everybody to do same changes (all platforms and > all odp apps.). It will be nice if we can group such changes when > merging because fixing up everything in different repos take some time... > > Maxim. > > On 10/07/2014 05:24 PM, Bill Fischofer wrote: > > Yes, but continuing the bootstrap, the Google docs are input to the > > doxygen versions which are integrated with the headers built from it. > > Agree the doxygen version is intended to be definitive. The prototype > > APIs we have pre-v1.0 are incomplete and in many cases inconsistent. > > The arch/design process resolves that and allows us to iterate to the > > final versions that will be v1.0. Otherwise we're just inventing APIs > > on the fly with code without any explicit design review. > > > > Bill > > > > On Tue, Oct 7, 2014 at 7:59 AM, Savolainen, Petri (NSN - FI/Espoo) > > <petri.savolainen@nsn.com <mailto:petri.savolainen@nsn.com>> wrote: > > > > API doc is generated with Doxygen from the headers. It's the > > easiest way to ensure that API definitions (in C code) and > > documentation are in sync. > > > > Arch docs support the doxygen documentation. > > > > -Petri > > > > *From:*ext Bill Fischofer [mailto:bill.fischofer@linaro.org > > <mailto:bill.fischofer@linaro.org>] > > *Sent:* Tuesday, October 07, 2014 3:54 PM > > *To:* Savolainen, Petri (NSN - FI/Espoo) > > *Cc:* lng-odp-forward > > *Subject:* Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > I'm not sure I understand this point. The design docs are the API > > docs. > > > > On Tue, Oct 7, 2014 at 7:07 AM, Savolainen, Petri (NSN - FI/Espoo) > > <petri.savolainen@nsn.com <mailto:petri.savolainen@nsn.com>> wrote: > > > > Hi. > > > > Test suite should be written from API documentation, since that's > > the contract for users. Arch docs should just provide additional / > > higher level information, so that API documentation is easier to > > understand. Too much details in arch doc will duplicate > > information (without too much added value). Does we need this > > level of detail (function name for conversions) in arch doc - it's > > enough to mention that buf <-> pkt conversion can be done using > > the packet API. > > > > -Petri > > > > *From:*ext Bill Fischofer [mailto:bill.fischofer@linaro.org > > <mailto:bill.fischofer@linaro.org>] > > *Sent:* Tuesday, October 07, 2014 12:22 AM > > *To:* Petri Savolainen > > *Cc:* lng-odp-forward > > *Subject:* Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > Can we coordinate these changes with the ongoing Packet API design > > work? Simply making code changes without that coordination at this > > point is going to get confusing. Not saying there may not be good > > reasons for these changes, but we want everything to sync up since > > the ODP Test Suite is going to be written from the design docs, > > not from the code. > > > > Thanks. > > > > Bill > > > > > > > > > > _______________________________________________ > > lng-odp mailing list > > lng-odp@lists.linaro.org > > http://lists.linaro.org/mailman/listinfo/lng-odp > > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/lng-odp
On 8 Oct 2014 11:23, "Savolainen, Petri (NSN - FI/Espoo)" < petri.savolainen@nsn.com> wrote: > > Hi, > > It's not a major architectural change. Just find and replace. If there's nobody against it, could we just merge it and carry on. I agree! > > Implementations can choose to either follow the linux-generic closely or group multiple changes (= update less frequently). It's up to each implementation which strategy works the best. I think it's easier to follow a set of many small changes than few big ones (which seem to rewrite an API in one shot). I agree here as well! This was why we create different repositories... To speed up the implementation of linux-generic, right? Cheers, Anders > > -Petri > > > > > > -----Original Message----- > > From: lng-odp-bounces@lists.linaro.org [mailto:lng-odp- > > bounces@lists.linaro.org] On Behalf Of ext Maxim Uvarov > > Sent: Tuesday, October 07, 2014 5:11 PM > > To: lng-odp@lists.linaro.org > > Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > I think that sort of patches should have RFC for better discussion. Due > > to that changes require everybody to do same changes (all platforms and > > all odp apps.). It will be nice if we can group such changes when > > merging because fixing up everything in different repos take some time... > > > > Maxim. > > > > On 10/07/2014 05:24 PM, Bill Fischofer wrote: > > > Yes, but continuing the bootstrap, the Google docs are input to the > > > doxygen versions which are integrated with the headers built from it. > > > Agree the doxygen version is intended to be definitive. The prototype > > > APIs we have pre-v1.0 are incomplete and in many cases inconsistent. > > > The arch/design process resolves that and allows us to iterate to the > > > final versions that will be v1.0. Otherwise we're just inventing APIs > > > on the fly with code without any explicit design review. > > > > > > Bill > > > > > > On Tue, Oct 7, 2014 at 7:59 AM, Savolainen, Petri (NSN - FI/Espoo) > > > <petri.savolainen@nsn.com <mailto:petri.savolainen@nsn.com>> wrote: > > > > > > API doc is generated with Doxygen from the headers. It's the > > > easiest way to ensure that API definitions (in C code) and > > > documentation are in sync. > > > > > > Arch docs support the doxygen documentation. > > > > > > -Petri > > > > > > *From:*ext Bill Fischofer [mailto:bill.fischofer@linaro.org > > > <mailto:bill.fischofer@linaro.org>] > > > *Sent:* Tuesday, October 07, 2014 3:54 PM > > > *To:* Savolainen, Petri (NSN - FI/Espoo) > > > *Cc:* lng-odp-forward > > > *Subject:* Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > > > I'm not sure I understand this point. The design docs are the API > > > docs. > > > > > > On Tue, Oct 7, 2014 at 7:07 AM, Savolainen, Petri (NSN - FI/Espoo) > > > <petri.savolainen@nsn.com <mailto:petri.savolainen@nsn.com>> wrote: > > > > > > Hi. > > > > > > Test suite should be written from API documentation, since that's > > > the contract for users. Arch docs should just provide additional / > > > higher level information, so that API documentation is easier to > > > understand. Too much details in arch doc will duplicate > > > information (without too much added value). Does we need this > > > level of detail (function name for conversions) in arch doc - it's > > > enough to mention that buf <-> pkt conversion can be done using > > > the packet API. > > > > > > -Petri > > > > > > *From:*ext Bill Fischofer [mailto:bill.fischofer@linaro.org > > > <mailto:bill.fischofer@linaro.org>] > > > *Sent:* Tuesday, October 07, 2014 12:22 AM > > > *To:* Petri Savolainen > > > *Cc:* lng-odp-forward > > > *Subject:* Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > > > Can we coordinate these changes with the ongoing Packet API design > > > work? Simply making code changes without that coordination at this > > > point is going to get confusing. Not saying there may not be good > > > reasons for these changes, but we want everything to sync up since > > > the ODP Test Suite is going to be written from the design docs, > > > not from the code. > > > > > > Thanks. > > > > > > Bill > > > > > > > > > > > > > > > _______________________________________________ > > > lng-odp mailing list > > > lng-odp@lists.linaro.org > > > http://lists.linaro.org/mailman/listinfo/lng-odp > > > > > > _______________________________________________ > > lng-odp mailing list > > lng-odp@lists.linaro.org > > http://lists.linaro.org/mailman/listinfo/lng-odp > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/lng-odp
It may be minor, but it is a change to the API. I agree it is straightforward, but since these are trivial conversion routines, why not add these rather than replacing their predecessors? So we could offer both odp_buffer_from_packet() and odp_buffer_to_packet() at no real cost. Post-v1.0 adding the new APIs would be a minor change since it is backward-compatible, while replacing them would be a major change since it would require application source code change. Bill On Wed, Oct 8, 2014 at 4:30 AM, Anders Roxell <anders.roxell@linaro.org> wrote: > > On 8 Oct 2014 11:23, "Savolainen, Petri (NSN - FI/Espoo)" < > petri.savolainen@nsn.com> wrote: > > > > Hi, > > > > It's not a major architectural change. Just find and replace. If there's > nobody against it, could we just merge it and carry on. > > I agree! > > > > > Implementations can choose to either follow the linux-generic closely or > group multiple changes (= update less frequently). It's up to each > implementation which strategy works the best. I think it's easier to follow > a set of many small changes than few big ones (which seem to rewrite an API > in one shot). > > I agree here as well! > > This was why we create different repositories... To speed up the > implementation of linux-generic, right? > > Cheers, > Anders > > > > > -Petri > > > > > > > > > > > -----Original Message----- > > > From: lng-odp-bounces@lists.linaro.org [mailto:lng-odp- > > > bounces@lists.linaro.org] On Behalf Of ext Maxim Uvarov > > > Sent: Tuesday, October 07, 2014 5:11 PM > > > To: lng-odp@lists.linaro.org > > > Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > > > I think that sort of patches should have RFC for better discussion. Due > > > to that changes require everybody to do same changes (all platforms and > > > all odp apps.). It will be nice if we can group such changes when > > > merging because fixing up everything in different repos take some > time... > > > > > > Maxim. > > > > > > On 10/07/2014 05:24 PM, Bill Fischofer wrote: > > > > Yes, but continuing the bootstrap, the Google docs are input to the > > > > doxygen versions which are integrated with the headers built from it. > > > > Agree the doxygen version is intended to be definitive. The prototype > > > > APIs we have pre-v1.0 are incomplete and in many cases inconsistent. > > > > The arch/design process resolves that and allows us to iterate to the > > > > final versions that will be v1.0. Otherwise we're just inventing APIs > > > > on the fly with code without any explicit design review. > > > > > > > > Bill > > > > > > > > On Tue, Oct 7, 2014 at 7:59 AM, Savolainen, Petri (NSN - FI/Espoo) > > > > <petri.savolainen@nsn.com <mailto:petri.savolainen@nsn.com>> wrote: > > > > > > > > API doc is generated with Doxygen from the headers. It's the > > > > easiest way to ensure that API definitions (in C code) and > > > > documentation are in sync. > > > > > > > > Arch docs support the doxygen documentation. > > > > > > > > -Petri > > > > > > > > *From:*ext Bill Fischofer [mailto:bill.fischofer@linaro.org > > > > <mailto:bill.fischofer@linaro.org>] > > > > *Sent:* Tuesday, October 07, 2014 3:54 PM > > > > *To:* Savolainen, Petri (NSN - FI/Espoo) > > > > *Cc:* lng-odp-forward > > > > *Subject:* Re: [lng-odp] [PATCH] Rename buffer_from_packet > function > > > > > > > > I'm not sure I understand this point. The design docs are the API > > > > docs. > > > > > > > > On Tue, Oct 7, 2014 at 7:07 AM, Savolainen, Petri (NSN - > FI/Espoo) > > > > <petri.savolainen@nsn.com <mailto:petri.savolainen@nsn.com>> > wrote: > > > > > > > > Hi. > > > > > > > > Test suite should be written from API documentation, since that's > > > > the contract for users. Arch docs should just provide additional > / > > > > higher level information, so that API documentation is easier to > > > > understand. Too much details in arch doc will duplicate > > > > information (without too much added value). Does we need this > > > > level of detail (function name for conversions) in arch doc - > it's > > > > enough to mention that buf <-> pkt conversion can be done using > > > > the packet API. > > > > > > > > -Petri > > > > > > > > *From:*ext Bill Fischofer [mailto:bill.fischofer@linaro.org > > > > <mailto:bill.fischofer@linaro.org>] > > > > *Sent:* Tuesday, October 07, 2014 12:22 AM > > > > *To:* Petri Savolainen > > > > *Cc:* lng-odp-forward > > > > *Subject:* Re: [lng-odp] [PATCH] Rename buffer_from_packet > function > > > > > > > > Can we coordinate these changes with the ongoing Packet API > design > > > > work? Simply making code changes without that coordination at > this > > > > point is going to get confusing. Not saying there may not be good > > > > reasons for these changes, but we want everything to sync up > since > > > > the ODP Test Suite is going to be written from the design docs, > > > > not from the code. > > > > > > > > Thanks. > > > > > > > > Bill > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > lng-odp mailing list > > > > lng-odp@lists.linaro.org > > > > http://lists.linaro.org/mailman/listinfo/lng-odp > > > > > > > > > _______________________________________________ > > > lng-odp mailing list > > > lng-odp@lists.linaro.org > > > http://lists.linaro.org/mailman/listinfo/lng-odp > > > > _______________________________________________ > > lng-odp mailing list > > lng-odp@lists.linaro.org > > http://lists.linaro.org/mailman/listinfo/lng-odp > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/lng-odp > >
Hi, Less is more in API definition. The less there are functions/options/overlap, the less there is confusion among users and the less work to implement and maintain it. -Petri From: ext Bill Fischofer [mailto:bill.fischofer@linaro.org] Sent: Wednesday, October 08, 2014 2:09 PM To: Anders Roxell Cc: Savolainen, Petri (NSN - FI/Espoo); lng-odp-forward Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function It may be minor, but it is a change to the API. I agree it is straightforward, but since these are trivial conversion routines, why not add these rather than replacing their predecessors? So we could offer both odp_buffer_from_packet() and odp_buffer_to_packet() at no real cost. Post-v1.0 adding the new APIs would be a minor change since it is backward-compatible, while replacing them would be a major change since it would require application source code change. Bill On Wed, Oct 8, 2014 at 4:30 AM, Anders Roxell <anders.roxell@linaro.org<mailto:anders.roxell@linaro.org>> wrote: On 8 Oct 2014 11:23, "Savolainen, Petri (NSN - FI/Espoo)" <petri.savolainen@nsn.com<mailto:petri.savolainen@nsn.com>> wrote: > > Hi, > > It's not a major architectural change. Just find and replace. If there's nobody against it, could we just merge it and carry on. I agree! > > Implementations can choose to either follow the linux-generic closely or group multiple changes (= update less frequently). It's up to each implementation which strategy works the best. I think it's easier to follow a set of many small changes than few big ones (which seem to rewrite an API in one shot). I agree here as well! This was why we create different repositories... To speed up the implementation of linux-generic, right? Cheers, Anders > > -Petri > > > > > > -----Original Message----- > > From: lng-odp-bounces@lists.linaro.org<mailto:lng-odp-bounces@lists.linaro.org> [mailto:lng-odp-<mailto:lng-odp-> > > bounces@lists.linaro.org<mailto:bounces@lists.linaro.org>] On Behalf Of ext Maxim Uvarov > > Sent: Tuesday, October 07, 2014 5:11 PM > > To: lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org> > > Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > I think that sort of patches should have RFC for better discussion. Due > > to that changes require everybody to do same changes (all platforms and > > all odp apps.). It will be nice if we can group such changes when > > merging because fixing up everything in different repos take some time... > > > > Maxim. > > > > On 10/07/2014 05:24 PM, Bill Fischofer wrote: > > > Yes, but continuing the bootstrap, the Google docs are input to the > > > doxygen versions which are integrated with the headers built from it. > > > Agree the doxygen version is intended to be definitive. The prototype > > > APIs we have pre-v1.0 are incomplete and in many cases inconsistent. > > > The arch/design process resolves that and allows us to iterate to the > > > final versions that will be v1.0. Otherwise we're just inventing APIs > > > on the fly with code without any explicit design review. > > > > > > Bill > > > > > > On Tue, Oct 7, 2014 at 7:59 AM, Savolainen, Petri (NSN - FI/Espoo) > > > <petri.savolainen@nsn.com<mailto:petri.savolainen@nsn.com> <mailto:petri.savolainen@nsn.com<mailto:petri.savolainen@nsn.com>>> wrote: > > > > > > API doc is generated with Doxygen from the headers. It's the > > > easiest way to ensure that API definitions (in C code) and > > > documentation are in sync. > > > > > > Arch docs support the doxygen documentation. > > > > > > -Petri > > > > > > *From:*ext Bill Fischofer [mailto:bill.fischofer@linaro.org<mailto:bill.fischofer@linaro.org> > > > <mailto:bill.fischofer@linaro.org<mailto:bill.fischofer@linaro.org>>] > > > *Sent:* Tuesday, October 07, 2014 3:54 PM > > > *To:* Savolainen, Petri (NSN - FI/Espoo) > > > *Cc:* lng-odp-forward > > > *Subject:* Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > > > I'm not sure I understand this point. The design docs are the API > > > docs. > > > > > > On Tue, Oct 7, 2014 at 7:07 AM, Savolainen, Petri (NSN - FI/Espoo) > > > <petri.savolainen@nsn.com<mailto:petri.savolainen@nsn.com> <mailto:petri.savolainen@nsn.com<mailto:petri.savolainen@nsn.com>>> wrote: > > > > > > Hi. > > > > > > Test suite should be written from API documentation, since that's > > > the contract for users. Arch docs should just provide additional / > > > higher level information, so that API documentation is easier to > > > understand. Too much details in arch doc will duplicate > > > information (without too much added value). Does we need this > > > level of detail (function name for conversions) in arch doc - it's > > > enough to mention that buf <-> pkt conversion can be done using > > > the packet API. > > > > > > -Petri > > > > > > *From:*ext Bill Fischofer [mailto:bill.fischofer@linaro.org<mailto:bill.fischofer@linaro.org> > > > <mailto:bill.fischofer@linaro.org<mailto:bill.fischofer@linaro.org>>] > > > *Sent:* Tuesday, October 07, 2014 12:22 AM > > > *To:* Petri Savolainen > > > *Cc:* lng-odp-forward > > > *Subject:* Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > > > Can we coordinate these changes with the ongoing Packet API design > > > work? Simply making code changes without that coordination at this > > > point is going to get confusing. Not saying there may not be good > > > reasons for these changes, but we want everything to sync up since > > > the ODP Test Suite is going to be written from the design docs, > > > not from the code. > > > > > > Thanks. > > > > > > Bill > > > > > > > > > > > > > > > _______________________________________________ > > > lng-odp mailing list > > > lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org> > > > http://lists.linaro.org/mailman/listinfo/lng-odp > > > > > > _______________________________________________ > > lng-odp mailing list > > lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org> > > http://lists.linaro.org/mailman/listinfo/lng-odp > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org> > http://lists.linaro.org/mailman/listinfo/lng-odp _______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org> http://lists.linaro.org/mailman/listinfo/lng-odp
On 8 Oct 2014 13:08, "Bill Fischofer" <bill.fischofer@linaro.org> wrote: > > It may be minor, but it is a change to the API. I agree it is straightforward, but since these are trivial conversion routines, why not add these rather than replacing their predecessors? So we could offer both odp_buffer_from_packet() and odp_buffer_to_packet() at no real cost. Post-v1.0 adding the new APIs would be a minor change since it is backward-compatible, while replacing them would be a major change since it would require application source code change. What?!? Backward compatible with what? Cheers, Anders > > Bill > > On Wed, Oct 8, 2014 at 4:30 AM, Anders Roxell <anders.roxell@linaro.org> wrote: >> >> >> On 8 Oct 2014 11:23, "Savolainen, Petri (NSN - FI/Espoo)" < petri.savolainen@nsn.com> wrote: >> > >> > Hi, >> > >> > It's not a major architectural change. Just find and replace. If there's nobody against it, could we just merge it and carry on. >> >> I agree! >> >> > >> > Implementations can choose to either follow the linux-generic closely or group multiple changes (= update less frequently). It's up to each implementation which strategy works the best. I think it's easier to follow a set of many small changes than few big ones (which seem to rewrite an API in one shot). >> >> I agree here as well! >> >> This was why we create different repositories... To speed up the implementation of linux-generic, right? >> >> Cheers, >> Anders >> >> > >> > -Petri >> > >> > >> > >> > >> > > -----Original Message----- >> > > From: lng-odp-bounces@lists.linaro.org [mailto:lng-odp- >> > > bounces@lists.linaro.org] On Behalf Of ext Maxim Uvarov >> > > Sent: Tuesday, October 07, 2014 5:11 PM >> > > To: lng-odp@lists.linaro.org >> > > Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function >> > > >> > > I think that sort of patches should have RFC for better discussion. Due >> > > to that changes require everybody to do same changes (all platforms and >> > > all odp apps.). It will be nice if we can group such changes when >> > > merging because fixing up everything in different repos take some time... >> > > >> > > Maxim. >> > > >> > > On 10/07/2014 05:24 PM, Bill Fischofer wrote: >> > > > Yes, but continuing the bootstrap, the Google docs are input to the >> > > > doxygen versions which are integrated with the headers built from it. >> > > > Agree the doxygen version is intended to be definitive. The prototype >> > > > APIs we have pre-v1.0 are incomplete and in many cases inconsistent. >> > > > The arch/design process resolves that and allows us to iterate to the >> > > > final versions that will be v1.0. Otherwise we're just inventing APIs >> > > > on the fly with code without any explicit design review. >> > > > >> > > > Bill >> > > > >> > > > On Tue, Oct 7, 2014 at 7:59 AM, Savolainen, Petri (NSN - FI/Espoo) >> > > > <petri.savolainen@nsn.com <mailto:petri.savolainen@nsn.com>> wrote: >> > > > >> > > > API doc is generated with Doxygen from the headers. It's the >> > > > easiest way to ensure that API definitions (in C code) and >> > > > documentation are in sync. >> > > > >> > > > Arch docs support the doxygen documentation. >> > > > >> > > > -Petri >> > > > >> > > > *From:*ext Bill Fischofer [mailto:bill.fischofer@linaro.org >> > > > <mailto:bill.fischofer@linaro.org>] >> > > > *Sent:* Tuesday, October 07, 2014 3:54 PM >> > > > *To:* Savolainen, Petri (NSN - FI/Espoo) >> > > > *Cc:* lng-odp-forward >> > > > *Subject:* Re: [lng-odp] [PATCH] Rename buffer_from_packet function >> > > > >> > > > I'm not sure I understand this point. The design docs are the API >> > > > docs. >> > > > >> > > > On Tue, Oct 7, 2014 at 7:07 AM, Savolainen, Petri (NSN - FI/Espoo) >> > > > <petri.savolainen@nsn.com <mailto:petri.savolainen@nsn.com>> wrote: >> > > > >> > > > Hi. >> > > > >> > > > Test suite should be written from API documentation, since that's >> > > > the contract for users. Arch docs should just provide additional / >> > > > higher level information, so that API documentation is easier to >> > > > understand. Too much details in arch doc will duplicate >> > > > information (without too much added value). Does we need this >> > > > level of detail (function name for conversions) in arch doc - it's >> > > > enough to mention that buf <-> pkt conversion can be done using >> > > > the packet API. >> > > > >> > > > -Petri >> > > > >> > > > *From:*ext Bill Fischofer [mailto:bill.fischofer@linaro.org >> > > > <mailto:bill.fischofer@linaro.org>] >> > > > *Sent:* Tuesday, October 07, 2014 12:22 AM >> > > > *To:* Petri Savolainen >> > > > *Cc:* lng-odp-forward >> > > > *Subject:* Re: [lng-odp] [PATCH] Rename buffer_from_packet function >> > > > >> > > > Can we coordinate these changes with the ongoing Packet API design >> > > > work? Simply making code changes without that coordination at this >> > > > point is going to get confusing. Not saying there may not be good >> > > > reasons for these changes, but we want everything to sync up since >> > > > the ODP Test Suite is going to be written from the design docs, >> > > > not from the code. >> > > > >> > > > Thanks. >> > > > >> > > > Bill >> > > > >> > > > >> > > > >> > > > >> > > > _______________________________________________ >> > > > lng-odp mailing list >> > > > lng-odp@lists.linaro.org >> > > > http://lists.linaro.org/mailman/listinfo/lng-odp >> > > >> > > >> > > _______________________________________________ >> > > lng-odp mailing list >> > > lng-odp@lists.linaro.org >> > > http://lists.linaro.org/mailman/listinfo/lng-odp >> > >> > _______________________________________________ >> > lng-odp mailing list >> > lng-odp@lists.linaro.org >> > http://lists.linaro.org/mailman/listinfo/lng-odp >> >> >> _______________________________________________ >> lng-odp mailing list >> lng-odp@lists.linaro.org >> http://lists.linaro.org/mailman/listinfo/lng-odp >> >
One isn't obviously superior to the other as this is clearly a matter of personal preference. I have no problem offering choice in this if you want to introduce the "to" routines as an alternative. But I don't see the need to remove the "from" routines. If it's OK to make this change, what would prevent someone else submitting a patch to turn these back around because they felt the original "made more sense"? On what basis would we accept or reject such a patch? Do we flip-flop on things like this without any guidelines based on the last received patch? On Wed, Oct 8, 2014 at 6:17 AM, Savolainen, Petri (NSN - FI/Espoo) < petri.savolainen@nsn.com> wrote: > Hi, > > > > Less is more in API definition. The less there are > functions/options/overlap, the less there is confusion among users and the > less work to implement and maintain it. > > > > -Petri > > > > > > > > *From:* ext Bill Fischofer [mailto:bill.fischofer@linaro.org] > *Sent:* Wednesday, October 08, 2014 2:09 PM > *To:* Anders Roxell > *Cc:* Savolainen, Petri (NSN - FI/Espoo); lng-odp-forward > > *Subject:* Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > It may be minor, but it is a change to the API. I agree it is > straightforward, but since these are trivial conversion routines, why not > add these rather than replacing their predecessors? So we could offer both > odp_buffer_from_packet() and odp_buffer_to_packet() at no real cost. > Post-v1.0 adding the new APIs would be a minor change since it is > backward-compatible, while replacing them would be a major change since it > would require application source code change. > > > > Bill > > > > On Wed, Oct 8, 2014 at 4:30 AM, Anders Roxell <anders.roxell@linaro.org> > wrote: > > > On 8 Oct 2014 11:23, "Savolainen, Petri (NSN - FI/Espoo)" < > petri.savolainen@nsn.com> wrote: > > > > Hi, > > > > It's not a major architectural change. Just find and replace. If there's > nobody against it, could we just merge it and carry on. > > I agree! > > > > > Implementations can choose to either follow the linux-generic closely or > group multiple changes (= update less frequently). It's up to each > implementation which strategy works the best. I think it's easier to follow > a set of many small changes than few big ones (which seem to rewrite an API > in one shot). > > I agree here as well! > > This was why we create different repositories... To speed up the > implementation of linux-generic, right? > > Cheers, > Anders > > > > > -Petri > > > > > > > > > > > -----Original Message----- > > > From: lng-odp-bounces@lists.linaro.org [mailto:lng-odp- > > > bounces@lists.linaro.org] On Behalf Of ext Maxim Uvarov > > > Sent: Tuesday, October 07, 2014 5:11 PM > > > To: lng-odp@lists.linaro.org > > > Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > > > I think that sort of patches should have RFC for better discussion. Due > > > to that changes require everybody to do same changes (all platforms and > > > all odp apps.). It will be nice if we can group such changes when > > > merging because fixing up everything in different repos take some > time... > > > > > > Maxim. > > > > > > On 10/07/2014 05:24 PM, Bill Fischofer wrote: > > > > Yes, but continuing the bootstrap, the Google docs are input to the > > > > doxygen versions which are integrated with the headers built from it. > > > > Agree the doxygen version is intended to be definitive. The prototype > > > > APIs we have pre-v1.0 are incomplete and in many cases inconsistent. > > > > The arch/design process resolves that and allows us to iterate to the > > > > final versions that will be v1.0. Otherwise we're just inventing APIs > > > > on the fly with code without any explicit design review. > > > > > > > > Bill > > > > > > > > On Tue, Oct 7, 2014 at 7:59 AM, Savolainen, Petri (NSN - FI/Espoo) > > > > <petri.savolainen@nsn.com <mailto:petri.savolainen@nsn.com>> wrote: > > > > > > > > API doc is generated with Doxygen from the headers. It's the > > > > easiest way to ensure that API definitions (in C code) and > > > > documentation are in sync. > > > > > > > > Arch docs support the doxygen documentation. > > > > > > > > -Petri > > > > > > > > *From:*ext Bill Fischofer [mailto:bill.fischofer@linaro.org > > > > <mailto:bill.fischofer@linaro.org>] > > > > *Sent:* Tuesday, October 07, 2014 3:54 PM > > > > *To:* Savolainen, Petri (NSN - FI/Espoo) > > > > *Cc:* lng-odp-forward > > > > *Subject:* Re: [lng-odp] [PATCH] Rename buffer_from_packet > function > > > > > > > > I'm not sure I understand this point. The design docs are the API > > > > docs. > > > > > > > > On Tue, Oct 7, 2014 at 7:07 AM, Savolainen, Petri (NSN - > FI/Espoo) > > > > <petri.savolainen@nsn.com <mailto:petri.savolainen@nsn.com>> > wrote: > > > > > > > > Hi. > > > > > > > > Test suite should be written from API documentation, since that's > > > > the contract for users. Arch docs should just provide additional > / > > > > higher level information, so that API documentation is easier to > > > > understand. Too much details in arch doc will duplicate > > > > information (without too much added value). Does we need this > > > > level of detail (function name for conversions) in arch doc - > it's > > > > enough to mention that buf <-> pkt conversion can be done using > > > > the packet API. > > > > > > > > -Petri > > > > > > > > *From:*ext Bill Fischofer [mailto:bill.fischofer@linaro.org > > > > <mailto:bill.fischofer@linaro.org>] > > > > *Sent:* Tuesday, October 07, 2014 12:22 AM > > > > *To:* Petri Savolainen > > > > *Cc:* lng-odp-forward > > > > *Subject:* Re: [lng-odp] [PATCH] Rename buffer_from_packet > function > > > > > > > > Can we coordinate these changes with the ongoing Packet API > design > > > > work? Simply making code changes without that coordination at > this > > > > point is going to get confusing. Not saying there may not be good > > > > reasons for these changes, but we want everything to sync up > since > > > > the ODP Test Suite is going to be written from the design docs, > > > > not from the code. > > > > > > > > Thanks. > > > > > > > > Bill > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > lng-odp mailing list > > > > lng-odp@lists.linaro.org > > > > http://lists.linaro.org/mailman/listinfo/lng-odp > > > > > > > > > _______________________________________________ > > > lng-odp mailing list > > > lng-odp@lists.linaro.org > > > http://lists.linaro.org/mailman/listinfo/lng-odp > > > > _______________________________________________ > > lng-odp mailing list > > lng-odp@lists.linaro.org > > http://lists.linaro.org/mailman/listinfo/lng-odp > > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/lng-odp > > >
It’s not “to” vs “from. It’s that a odp_buffer_xxx function should not use a odp_packet_t as parameter (packet inherits buffer, but not the other way around). -Petri From: ext Bill Fischofer [mailto:bill.fischofer@linaro.org] Sent: Wednesday, October 08, 2014 2:34 PM To: Savolainen, Petri (NSN - FI/Espoo) Cc: Anders Roxell; lng-odp-forward Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function One isn't obviously superior to the other as this is clearly a matter of personal preference. I have no problem offering choice in this if you want to introduce the "to" routines as an alternative. But I don't see the need to remove the "from" routines. If it's OK to make this change, what would prevent someone else submitting a patch to turn these back around because they felt the original "made more sense"? On what basis would we accept or reject such a patch? Do we flip-flop on things like this without any guidelines based on the last received patch? On Wed, Oct 8, 2014 at 6:17 AM, Savolainen, Petri (NSN - FI/Espoo) <petri.savolainen@nsn.com<mailto:petri.savolainen@nsn.com>> wrote: Hi, Less is more in API definition. The less there are functions/options/overlap, the less there is confusion among users and the less work to implement and maintain it. -Petri From: ext Bill Fischofer [mailto:bill.fischofer@linaro.org<mailto:bill.fischofer@linaro.org>] Sent: Wednesday, October 08, 2014 2:09 PM To: Anders Roxell Cc: Savolainen, Petri (NSN - FI/Espoo); lng-odp-forward Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function It may be minor, but it is a change to the API. I agree it is straightforward, but since these are trivial conversion routines, why not add these rather than replacing their predecessors? So we could offer both odp_buffer_from_packet() and odp_buffer_to_packet() at no real cost. Post-v1.0 adding the new APIs would be a minor change since it is backward-compatible, while replacing them would be a major change since it would require application source code change. Bill On Wed, Oct 8, 2014 at 4:30 AM, Anders Roxell <anders.roxell@linaro.org<mailto:anders.roxell@linaro.org>> wrote: On 8 Oct 2014 11:23, "Savolainen, Petri (NSN - FI/Espoo)" <petri.savolainen@nsn.com<mailto:petri.savolainen@nsn.com>> wrote: > > Hi, > > It's not a major architectural change. Just find and replace. If there's nobody against it, could we just merge it and carry on. I agree! > > Implementations can choose to either follow the linux-generic closely or group multiple changes (= update less frequently). It's up to each implementation which strategy works the best. I think it's easier to follow a set of many small changes than few big ones (which seem to rewrite an API in one shot). I agree here as well! This was why we create different repositories... To speed up the implementation of linux-generic, right? Cheers, Anders > > -Petri > > > > > > -----Original Message----- > > From: lng-odp-bounces@lists.linaro.org<mailto:lng-odp-bounces@lists.linaro.org> [mailto:lng-odp-<mailto:lng-odp-> > > bounces@lists.linaro.org<mailto:bounces@lists.linaro.org>] On Behalf Of ext Maxim Uvarov > > Sent: Tuesday, October 07, 2014 5:11 PM > > To: lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org> > > Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > I think that sort of patches should have RFC for better discussion. Due > > to that changes require everybody to do same changes (all platforms and > > all odp apps.). It will be nice if we can group such changes when > > merging because fixing up everything in different repos take some time... > > > > Maxim. > > > > On 10/07/2014 05:24 PM, Bill Fischofer wrote: > > > Yes, but continuing the bootstrap, the Google docs are input to the > > > doxygen versions which are integrated with the headers built from it. > > > Agree the doxygen version is intended to be definitive. The prototype > > > APIs we have pre-v1.0 are incomplete and in many cases inconsistent. > > > The arch/design process resolves that and allows us to iterate to the > > > final versions that will be v1.0. Otherwise we're just inventing APIs > > > on the fly with code without any explicit design review. > > > > > > Bill > > > > > > On Tue, Oct 7, 2014 at 7:59 AM, Savolainen, Petri (NSN - FI/Espoo) > > > <petri.savolainen@nsn.com<mailto:petri.savolainen@nsn.com> <mailto:petri.savolainen@nsn.com<mailto:petri.savolainen@nsn.com>>> wrote: > > > > > > API doc is generated with Doxygen from the headers. It's the > > > easiest way to ensure that API definitions (in C code) and > > > documentation are in sync. > > > > > > Arch docs support the doxygen documentation. > > > > > > -Petri > > > > > > *From:*ext Bill Fischofer [mailto:bill.fischofer@linaro.org<mailto:bill.fischofer@linaro.org> > > > <mailto:bill.fischofer@linaro.org<mailto:bill.fischofer@linaro.org>>] > > > *Sent:* Tuesday, October 07, 2014 3:54 PM > > > *To:* Savolainen, Petri (NSN - FI/Espoo) > > > *Cc:* lng-odp-forward > > > *Subject:* Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > > > I'm not sure I understand this point. The design docs are the API > > > docs. > > > > > > On Tue, Oct 7, 2014 at 7:07 AM, Savolainen, Petri (NSN - FI/Espoo) > > > <petri.savolainen@nsn.com<mailto:petri.savolainen@nsn.com> <mailto:petri.savolainen@nsn.com<mailto:petri.savolainen@nsn.com>>> wrote: > > > > > > Hi. > > > > > > Test suite should be written from API documentation, since that's > > > the contract for users. Arch docs should just provide additional / > > > higher level information, so that API documentation is easier to > > > understand. Too much details in arch doc will duplicate > > > information (without too much added value). Does we need this > > > level of detail (function name for conversions) in arch doc - it's > > > enough to mention that buf <-> pkt conversion can be done using > > > the packet API. > > > > > > -Petri > > > > > > *From:*ext Bill Fischofer [mailto:bill.fischofer@linaro.org<mailto:bill.fischofer@linaro.org> > > > <mailto:bill.fischofer@linaro.org<mailto:bill.fischofer@linaro.org>>] > > > *Sent:* Tuesday, October 07, 2014 12:22 AM > > > *To:* Petri Savolainen > > > *Cc:* lng-odp-forward > > > *Subject:* Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > > > Can we coordinate these changes with the ongoing Packet API design > > > work? Simply making code changes without that coordination at this > > > point is going to get confusing. Not saying there may not be good > > > reasons for these changes, but we want everything to sync up since > > > the ODP Test Suite is going to be written from the design docs, > > > not from the code. > > > > > > Thanks. > > > > > > Bill > > > > > > > > > > > > > > > _______________________________________________ > > > lng-odp mailing list > > > lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org> > > > http://lists.linaro.org/mailman/listinfo/lng-odp > > > > > > _______________________________________________ > > lng-odp mailing list > > lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org> > > http://lists.linaro.org/mailman/listinfo/lng-odp > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org> > http://lists.linaro.org/mailman/listinfo/lng-odp _______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org> http://lists.linaro.org/mailman/listinfo/lng-odp
A conversion routine by definition bridges two types. One could just as well argue that an odp_buffer routine is now returning a packet type. and vice versa. I assume you originally came up with the from routines because they mirror standard C type casting. If this were done via a type cast you'd write: (odp_buffer_t)pkt and (odp_packet_t)buf; On Wed, Oct 8, 2014 at 6:40 AM, Savolainen, Petri (NSN - FI/Espoo) < petri.savolainen@nsn.com> wrote: > It’s not “to” vs “from. It’s that a odp_buffer_xxx function should not > use a odp_packet_t as parameter (packet inherits buffer, but not the other > way around). > > > > -Petri > > > > *From:* ext Bill Fischofer [mailto:bill.fischofer@linaro.org] > *Sent:* Wednesday, October 08, 2014 2:34 PM > *To:* Savolainen, Petri (NSN - FI/Espoo) > *Cc:* Anders Roxell; lng-odp-forward > > *Subject:* Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > One isn't obviously superior to the other as this is clearly a matter of > personal preference. I have no problem offering choice in this if you want > to introduce the "to" routines as an alternative. But I don't see the need > to remove the "from" routines. If it's OK to make this change, what would > prevent someone else submitting a patch to turn these back around because > they felt the original "made more sense"? On what basis would we accept or > reject such a patch? Do we flip-flop on things like this without any > guidelines based on the last received patch? > > > > On Wed, Oct 8, 2014 at 6:17 AM, Savolainen, Petri (NSN - FI/Espoo) < > petri.savolainen@nsn.com> wrote: > > Hi, > > > > Less is more in API definition. The less there are > functions/options/overlap, the less there is confusion among users and the > less work to implement and maintain it. > > > > -Petri > > > > > > > > *From:* ext Bill Fischofer [mailto:bill.fischofer@linaro.org] > *Sent:* Wednesday, October 08, 2014 2:09 PM > *To:* Anders Roxell > *Cc:* Savolainen, Petri (NSN - FI/Espoo); lng-odp-forward > > > *Subject:* Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > It may be minor, but it is a change to the API. I agree it is > straightforward, but since these are trivial conversion routines, why not > add these rather than replacing their predecessors? So we could offer both > odp_buffer_from_packet() and odp_buffer_to_packet() at no real cost. > Post-v1.0 adding the new APIs would be a minor change since it is > backward-compatible, while replacing them would be a major change since it > would require application source code change. > > > > Bill > > > > On Wed, Oct 8, 2014 at 4:30 AM, Anders Roxell <anders.roxell@linaro.org> > wrote: > > > On 8 Oct 2014 11:23, "Savolainen, Petri (NSN - FI/Espoo)" < > petri.savolainen@nsn.com> wrote: > > > > Hi, > > > > It's not a major architectural change. Just find and replace. If there's > nobody against it, could we just merge it and carry on. > > I agree! > > > > > Implementations can choose to either follow the linux-generic closely or > group multiple changes (= update less frequently). It's up to each > implementation which strategy works the best. I think it's easier to follow > a set of many small changes than few big ones (which seem to rewrite an API > in one shot). > > I agree here as well! > > This was why we create different repositories... To speed up the > implementation of linux-generic, right? > > Cheers, > Anders > > > > > -Petri > > > > > > > > > > > -----Original Message----- > > > From: lng-odp-bounces@lists.linaro.org [mailto:lng-odp- > > > bounces@lists.linaro.org] On Behalf Of ext Maxim Uvarov > > > Sent: Tuesday, October 07, 2014 5:11 PM > > > To: lng-odp@lists.linaro.org > > > Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > > > I think that sort of patches should have RFC for better discussion. Due > > > to that changes require everybody to do same changes (all platforms and > > > all odp apps.). It will be nice if we can group such changes when > > > merging because fixing up everything in different repos take some > time... > > > > > > Maxim. > > > > > > On 10/07/2014 05:24 PM, Bill Fischofer wrote: > > > > Yes, but continuing the bootstrap, the Google docs are input to the > > > > doxygen versions which are integrated with the headers built from it. > > > > Agree the doxygen version is intended to be definitive. The prototype > > > > APIs we have pre-v1.0 are incomplete and in many cases inconsistent. > > > > The arch/design process resolves that and allows us to iterate to the > > > > final versions that will be v1.0. Otherwise we're just inventing APIs > > > > on the fly with code without any explicit design review. > > > > > > > > Bill > > > > > > > > On Tue, Oct 7, 2014 at 7:59 AM, Savolainen, Petri (NSN - FI/Espoo) > > > > <petri.savolainen@nsn.com <mailto:petri.savolainen@nsn.com>> wrote: > > > > > > > > API doc is generated with Doxygen from the headers. It's the > > > > easiest way to ensure that API definitions (in C code) and > > > > documentation are in sync. > > > > > > > > Arch docs support the doxygen documentation. > > > > > > > > -Petri > > > > > > > > *From:*ext Bill Fischofer [mailto:bill.fischofer@linaro.org > > > > <mailto:bill.fischofer@linaro.org>] > > > > *Sent:* Tuesday, October 07, 2014 3:54 PM > > > > *To:* Savolainen, Petri (NSN - FI/Espoo) > > > > *Cc:* lng-odp-forward > > > > *Subject:* Re: [lng-odp] [PATCH] Rename buffer_from_packet > function > > > > > > > > I'm not sure I understand this point. The design docs are the API > > > > docs. > > > > > > > > On Tue, Oct 7, 2014 at 7:07 AM, Savolainen, Petri (NSN - > FI/Espoo) > > > > <petri.savolainen@nsn.com <mailto:petri.savolainen@nsn.com>> > wrote: > > > > > > > > Hi. > > > > > > > > Test suite should be written from API documentation, since that's > > > > the contract for users. Arch docs should just provide additional > / > > > > higher level information, so that API documentation is easier to > > > > understand. Too much details in arch doc will duplicate > > > > information (without too much added value). Does we need this > > > > level of detail (function name for conversions) in arch doc - > it's > > > > enough to mention that buf <-> pkt conversion can be done using > > > > the packet API. > > > > > > > > -Petri > > > > > > > > *From:*ext Bill Fischofer [mailto:bill.fischofer@linaro.org > > > > <mailto:bill.fischofer@linaro.org>] > > > > *Sent:* Tuesday, October 07, 2014 12:22 AM > > > > *To:* Petri Savolainen > > > > *Cc:* lng-odp-forward > > > > *Subject:* Re: [lng-odp] [PATCH] Rename buffer_from_packet > function > > > > > > > > Can we coordinate these changes with the ongoing Packet API > design > > > > work? Simply making code changes without that coordination at > this > > > > point is going to get confusing. Not saying there may not be good > > > > reasons for these changes, but we want everything to sync up > since > > > > the ODP Test Suite is going to be written from the design docs, > > > > not from the code. > > > > > > > > Thanks. > > > > > > > > Bill > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > lng-odp mailing list > > > > lng-odp@lists.linaro.org > > > > http://lists.linaro.org/mailman/listinfo/lng-odp > > > > > > > > > _______________________________________________ > > > lng-odp mailing list > > > lng-odp@lists.linaro.org > > > http://lists.linaro.org/mailman/listinfo/lng-odp > > > > _______________________________________________ > > lng-odp mailing list > > lng-odp@lists.linaro.org > > http://lists.linaro.org/mailman/listinfo/lng-odp > > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/lng-odp > > > > >
In the platform discussion this morning the consensus was to not take this patch at this time. The rationale was that although we are at liberty to change the API as often as we want we don't want to introduce unnecessary churn when we can help it, and in this case we think we can. In this case we know the docs don't match the code, and that the documentation is not yet complete and its publication will be very soon. We also expect the final doc to change the API one more time. Given that all platforms and applications will have to change twice in quick succession it makes sense to sync the doc and the API before changing the code. Mike On 8 October 2014 07:45, Bill Fischofer <bill.fischofer@linaro.org> wrote: > A conversion routine by definition bridges two types. One could just as > well argue that an odp_buffer routine is now returning a packet type. and > vice versa. I assume you originally came up with the from routines because > they mirror standard C type casting. If this were done via a type cast > you'd write: > > (odp_buffer_t)pkt > > and > > (odp_packet_t)buf; > > > > On Wed, Oct 8, 2014 at 6:40 AM, Savolainen, Petri (NSN - FI/Espoo) < > petri.savolainen@nsn.com> wrote: > >> It’s not “to” vs “from. It’s that a odp_buffer_xxx function should not >> use a odp_packet_t as parameter (packet inherits buffer, but not the other >> way around). >> >> >> >> -Petri >> >> >> >> *From:* ext Bill Fischofer [mailto:bill.fischofer@linaro.org] >> *Sent:* Wednesday, October 08, 2014 2:34 PM >> *To:* Savolainen, Petri (NSN - FI/Espoo) >> *Cc:* Anders Roxell; lng-odp-forward >> >> *Subject:* Re: [lng-odp] [PATCH] Rename buffer_from_packet function >> >> >> >> One isn't obviously superior to the other as this is clearly a matter of >> personal preference. I have no problem offering choice in this if you want >> to introduce the "to" routines as an alternative. But I don't see the need >> to remove the "from" routines. If it's OK to make this change, what would >> prevent someone else submitting a patch to turn these back around because >> they felt the original "made more sense"? On what basis would we accept or >> reject such a patch? Do we flip-flop on things like this without any >> guidelines based on the last received patch? >> >> >> >> On Wed, Oct 8, 2014 at 6:17 AM, Savolainen, Petri (NSN - FI/Espoo) < >> petri.savolainen@nsn.com> wrote: >> >> Hi, >> >> >> >> Less is more in API definition. The less there are >> functions/options/overlap, the less there is confusion among users and the >> less work to implement and maintain it. >> >> >> >> -Petri >> >> >> >> >> >> >> >> *From:* ext Bill Fischofer [mailto:bill.fischofer@linaro.org] >> *Sent:* Wednesday, October 08, 2014 2:09 PM >> *To:* Anders Roxell >> *Cc:* Savolainen, Petri (NSN - FI/Espoo); lng-odp-forward >> >> >> *Subject:* Re: [lng-odp] [PATCH] Rename buffer_from_packet function >> >> >> >> It may be minor, but it is a change to the API. I agree it is >> straightforward, but since these are trivial conversion routines, why not >> add these rather than replacing their predecessors? So we could offer both >> odp_buffer_from_packet() and odp_buffer_to_packet() at no real cost. >> Post-v1.0 adding the new APIs would be a minor change since it is >> backward-compatible, while replacing them would be a major change since it >> would require application source code change. >> >> >> >> Bill >> >> >> >> On Wed, Oct 8, 2014 at 4:30 AM, Anders Roxell <anders.roxell@linaro.org> >> wrote: >> >> >> On 8 Oct 2014 11:23, "Savolainen, Petri (NSN - FI/Espoo)" < >> petri.savolainen@nsn.com> wrote: >> > >> > Hi, >> > >> > It's not a major architectural change. Just find and replace. If >> there's nobody against it, could we just merge it and carry on. >> >> I agree! >> >> > >> > Implementations can choose to either follow the linux-generic closely >> or group multiple changes (= update less frequently). It's up to each >> implementation which strategy works the best. I think it's easier to follow >> a set of many small changes than few big ones (which seem to rewrite an API >> in one shot). >> >> I agree here as well! >> >> This was why we create different repositories... To speed up the >> implementation of linux-generic, right? >> >> Cheers, >> Anders >> >> > >> > -Petri >> > >> > >> > >> > >> > > -----Original Message----- >> > > From: lng-odp-bounces@lists.linaro.org [mailto:lng-odp- >> > > bounces@lists.linaro.org] On Behalf Of ext Maxim Uvarov >> > > Sent: Tuesday, October 07, 2014 5:11 PM >> > > To: lng-odp@lists.linaro.org >> > > Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function >> > > >> > > I think that sort of patches should have RFC for better discussion. >> Due >> > > to that changes require everybody to do same changes (all platforms >> and >> > > all odp apps.). It will be nice if we can group such changes when >> > > merging because fixing up everything in different repos take some >> time... >> > > >> > > Maxim. >> > > >> > > On 10/07/2014 05:24 PM, Bill Fischofer wrote: >> > > > Yes, but continuing the bootstrap, the Google docs are input to the >> > > > doxygen versions which are integrated with the headers built from >> it. >> > > > Agree the doxygen version is intended to be definitive. The >> prototype >> > > > APIs we have pre-v1.0 are incomplete and in many cases inconsistent. >> > > > The arch/design process resolves that and allows us to iterate to >> the >> > > > final versions that will be v1.0. Otherwise we're just inventing >> APIs >> > > > on the fly with code without any explicit design review. >> > > > >> > > > Bill >> > > > >> > > > On Tue, Oct 7, 2014 at 7:59 AM, Savolainen, Petri (NSN - FI/Espoo) >> > > > <petri.savolainen@nsn.com <mailto:petri.savolainen@nsn.com>> wrote: >> > > > >> > > > API doc is generated with Doxygen from the headers. It's the >> > > > easiest way to ensure that API definitions (in C code) and >> > > > documentation are in sync. >> > > > >> > > > Arch docs support the doxygen documentation. >> > > > >> > > > -Petri >> > > > >> > > > *From:*ext Bill Fischofer [mailto:bill.fischofer@linaro.org >> > > > <mailto:bill.fischofer@linaro.org>] >> > > > *Sent:* Tuesday, October 07, 2014 3:54 PM >> > > > *To:* Savolainen, Petri (NSN - FI/Espoo) >> > > > *Cc:* lng-odp-forward >> > > > *Subject:* Re: [lng-odp] [PATCH] Rename buffer_from_packet >> function >> > > > >> > > > I'm not sure I understand this point. The design docs are the >> API >> > > > docs. >> > > > >> > > > On Tue, Oct 7, 2014 at 7:07 AM, Savolainen, Petri (NSN - >> FI/Espoo) >> > > > <petri.savolainen@nsn.com <mailto:petri.savolainen@nsn.com>> >> wrote: >> > > > >> > > > Hi. >> > > > >> > > > Test suite should be written from API documentation, since >> that's >> > > > the contract for users. Arch docs should just provide >> additional / >> > > > higher level information, so that API documentation is easier to >> > > > understand. Too much details in arch doc will duplicate >> > > > information (without too much added value). Does we need this >> > > > level of detail (function name for conversions) in arch doc - >> it's >> > > > enough to mention that buf <-> pkt conversion can be done using >> > > > the packet API. >> > > > >> > > > -Petri >> > > > >> > > > *From:*ext Bill Fischofer [mailto:bill.fischofer@linaro.org >> > > > <mailto:bill.fischofer@linaro.org>] >> > > > *Sent:* Tuesday, October 07, 2014 12:22 AM >> > > > *To:* Petri Savolainen >> > > > *Cc:* lng-odp-forward >> > > > *Subject:* Re: [lng-odp] [PATCH] Rename buffer_from_packet >> function >> > > > >> > > > Can we coordinate these changes with the ongoing Packet API >> design >> > > > work? Simply making code changes without that coordination at >> this >> > > > point is going to get confusing. Not saying there may not be >> good >> > > > reasons for these changes, but we want everything to sync up >> since >> > > > the ODP Test Suite is going to be written from the design docs, >> > > > not from the code. >> > > > >> > > > Thanks. >> > > > >> > > > Bill >> > > > >> > > > >> > > > >> > > > >> > > > _______________________________________________ >> > > > lng-odp mailing list >> > > > lng-odp@lists.linaro.org >> > > > http://lists.linaro.org/mailman/listinfo/lng-odp >> > > >> > > >> > > _______________________________________________ >> > > lng-odp mailing list >> > > lng-odp@lists.linaro.org >> > > http://lists.linaro.org/mailman/listinfo/lng-odp >> > >> > _______________________________________________ >> > lng-odp mailing list >> > lng-odp@lists.linaro.org >> > http://lists.linaro.org/mailman/listinfo/lng-odp >> >> >> _______________________________________________ >> lng-odp mailing list >> lng-odp@lists.linaro.org >> http://lists.linaro.org/mailman/listinfo/lng-odp >> >> >> >> >> > > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/lng-odp > >
If you consider the number of comments in that document… it will take a while until it’s finished. And then if you look back into the buffer doc, it’s not finished either since segmentation part should be removed from there… and so on. I’d rather fix only the necessary things in current APIs, documents and test those, and call it v1.0. We’ll not have _code_ for v1.0 at the end of the year, if we keep adding stuff into documents just for the sake of completeness. -Petri From: ext Mike Holmes [mailto:mike.holmes@linaro.org] Sent: Wednesday, October 08, 2014 3:16 PM To: Bill Fischofer Cc: Savolainen, Petri (NSN - FI/Espoo); lng-odp-forward Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function In the platform discussion this morning the consensus was to not take this patch at this time. The rationale was that although we are at liberty to change the API as often as we want we don't want to introduce unnecessary churn when we can help it, and in this case we think we can. In this case we know the docs don't match the code, and that the documentation is not yet complete and its publication will be very soon. We also expect the final doc to change the API one more time. Given that all platforms and applications will have to change twice in quick succession it makes sense to sync the doc and the API before changing the code. Mike On 8 October 2014 07:45, Bill Fischofer <bill.fischofer@linaro.org<mailto:bill.fischofer@linaro.org>> wrote: A conversion routine by definition bridges two types. One could just as well argue that an odp_buffer routine is now returning a packet type. and vice versa. I assume you originally came up with the from routines because they mirror standard C type casting. If this were done via a type cast you'd write: (odp_buffer_t)pkt and (odp_packet_t)buf; On Wed, Oct 8, 2014 at 6:40 AM, Savolainen, Petri (NSN - FI/Espoo) <petri.savolainen@nsn.com<mailto:petri.savolainen@nsn.com>> wrote: It’s not “to” vs “from. It’s that a odp_buffer_xxx function should not use a odp_packet_t as parameter (packet inherits buffer, but not the other way around). -Petri From: ext Bill Fischofer [mailto:bill.fischofer@linaro.org<mailto:bill.fischofer@linaro.org>] Sent: Wednesday, October 08, 2014 2:34 PM To: Savolainen, Petri (NSN - FI/Espoo) Cc: Anders Roxell; lng-odp-forward Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function One isn't obviously superior to the other as this is clearly a matter of personal preference. I have no problem offering choice in this if you want to introduce the "to" routines as an alternative. But I don't see the need to remove the "from" routines. If it's OK to make this change, what would prevent someone else submitting a patch to turn these back around because they felt the original "made more sense"? On what basis would we accept or reject such a patch? Do we flip-flop on things like this without any guidelines based on the last received patch? On Wed, Oct 8, 2014 at 6:17 AM, Savolainen, Petri (NSN - FI/Espoo) <petri.savolainen@nsn.com<mailto:petri.savolainen@nsn.com>> wrote: Hi, Less is more in API definition. The less there are functions/options/overlap, the less there is confusion among users and the less work to implement and maintain it. -Petri From: ext Bill Fischofer [mailto:bill.fischofer@linaro.org<mailto:bill.fischofer@linaro.org>] Sent: Wednesday, October 08, 2014 2:09 PM To: Anders Roxell Cc: Savolainen, Petri (NSN - FI/Espoo); lng-odp-forward Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function It may be minor, but it is a change to the API. I agree it is straightforward, but since these are trivial conversion routines, why not add these rather than replacing their predecessors? So we could offer both odp_buffer_from_packet() and odp_buffer_to_packet() at no real cost. Post-v1.0 adding the new APIs would be a minor change since it is backward-compatible, while replacing them would be a major change since it would require application source code change. Bill On Wed, Oct 8, 2014 at 4:30 AM, Anders Roxell <anders.roxell@linaro.org<mailto:anders.roxell@linaro.org>> wrote: On 8 Oct 2014 11:23, "Savolainen, Petri (NSN - FI/Espoo)" <petri.savolainen@nsn.com<mailto:petri.savolainen@nsn.com>> wrote: > > Hi, > > It's not a major architectural change. Just find and replace. If there's nobody against it, could we just merge it and carry on. I agree! > > Implementations can choose to either follow the linux-generic closely or group multiple changes (= update less frequently). It's up to each implementation which strategy works the best. I think it's easier to follow a set of many small changes than few big ones (which seem to rewrite an API in one shot). I agree here as well! This was why we create different repositories... To speed up the implementation of linux-generic, right? Cheers, Anders > > -Petri > > > > > > -----Original Message----- > > From: lng-odp-bounces@lists.linaro.org<mailto:lng-odp-bounces@lists.linaro.org> [mailto:lng-odp-<mailto:lng-odp-> > > bounces@lists.linaro.org<mailto:bounces@lists.linaro.org>] On Behalf Of ext Maxim Uvarov > > Sent: Tuesday, October 07, 2014 5:11 PM > > To: lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org> > > Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > I think that sort of patches should have RFC for better discussion. Due > > to that changes require everybody to do same changes (all platforms and > > all odp apps.). It will be nice if we can group such changes when > > merging because fixing up everything in different repos take some time... > > > > Maxim. > > > > On 10/07/2014 05:24 PM, Bill Fischofer wrote: > > > Yes, but continuing the bootstrap, the Google docs are input to the > > > doxygen versions which are integrated with the headers built from it. > > > Agree the doxygen version is intended to be definitive. The prototype > > > APIs we have pre-v1.0 are incomplete and in many cases inconsistent. > > > The arch/design process resolves that and allows us to iterate to the > > > final versions that will be v1.0. Otherwise we're just inventing APIs > > > on the fly with code without any explicit design review. > > > > > > Bill > > > > > > On Tue, Oct 7, 2014 at 7:59 AM, Savolainen, Petri (NSN - FI/Espoo) > > > <petri.savolainen@nsn.com<mailto:petri.savolainen@nsn.com> <mailto:petri.savolainen@nsn.com<mailto:petri.savolainen@nsn.com>>> wrote: > > > > > > API doc is generated with Doxygen from the headers. It's the > > > easiest way to ensure that API definitions (in C code) and > > > documentation are in sync. > > > > > > Arch docs support the doxygen documentation. > > > > > > -Petri > > > > > > *From:*ext Bill Fischofer [mailto:bill.fischofer@linaro.org<mailto:bill.fischofer@linaro.org> > > > <mailto:bill.fischofer@linaro.org<mailto:bill.fischofer@linaro.org>>] > > > *Sent:* Tuesday, October 07, 2014 3:54 PM > > > *To:* Savolainen, Petri (NSN - FI/Espoo) > > > *Cc:* lng-odp-forward > > > *Subject:* Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > > > I'm not sure I understand this point. The design docs are the API > > > docs. > > > > > > On Tue, Oct 7, 2014 at 7:07 AM, Savolainen, Petri (NSN - FI/Espoo) > > > <petri.savolainen@nsn.com<mailto:petri.savolainen@nsn.com> <mailto:petri.savolainen@nsn.com<mailto:petri.savolainen@nsn.com>>> wrote: > > > > > > Hi. > > > > > > Test suite should be written from API documentation, since that's > > > the contract for users. Arch docs should just provide additional / > > > higher level information, so that API documentation is easier to > > > understand. Too much details in arch doc will duplicate > > > information (without too much added value). Does we need this > > > level of detail (function name for conversions) in arch doc - it's > > > enough to mention that buf <-> pkt conversion can be done using > > > the packet API. > > > > > > -Petri > > > > > > *From:*ext Bill Fischofer [mailto:bill.fischofer@linaro.org<mailto:bill.fischofer@linaro.org> > > > <mailto:bill.fischofer@linaro.org<mailto:bill.fischofer@linaro.org>>] > > > *Sent:* Tuesday, October 07, 2014 12:22 AM > > > *To:* Petri Savolainen > > > *Cc:* lng-odp-forward > > > *Subject:* Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > > > Can we coordinate these changes with the ongoing Packet API design > > > work? Simply making code changes without that coordination at this > > > point is going to get confusing. Not saying there may not be good > > > reasons for these changes, but we want everything to sync up since > > > the ODP Test Suite is going to be written from the design docs, > > > not from the code. > > > > > > Thanks. > > > > > > Bill > > > > > > > > > > > > > > > _______________________________________________ > > > lng-odp mailing list > > > lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org> > > > http://lists.linaro.org/mailman/listinfo/lng-odp > > > > > > _______________________________________________ > > lng-odp mailing list > > lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org> > > http://lists.linaro.org/mailman/listinfo/lng-odp > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org> > http://lists.linaro.org/mailman/listinfo/lng-odp _______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org> http://lists.linaro.org/mailman/listinfo/lng-odp _______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org> http://lists.linaro.org/mailman/listinfo/lng-odp -- Mike Holmes Linaro Sr Technical Manager LNG - ODP
On 8 Oct 2014 14:55, "Savolainen, Petri (NSN - FI/Espoo)" < petri.savolainen@nsn.com> wrote: > > If you consider the number of comments in that document… it will take a while until it’s finished. And then if you look back into the buffer doc, it’s not finished either since segmentation part should be removed from there… and so on. Again I agree with Petri! > > > > I’d rather fix only the necessary things in current APIs, documents and test those, and call it v1.0. We’ll not have _code_ for v1.0 at the end of the year, if we keep adding stuff into documents just for the sake of completeness. If we want to do API changes to an existing header file I think we shall do that as patches and _not_ the way we are trying to do now with a Google docs somewhere else... Why I think this is a good patch is because we _don't_ have two APIs that do the same thing and the patch makes the API clearer, which is something you said earlier in the thread said Bill... =) Anders > > > > > > -Petri > > > > > > > > From: ext Mike Holmes [mailto:mike.holmes@linaro.org] > Sent: Wednesday, October 08, 2014 3:16 PM > To: Bill Fischofer > > Cc: Savolainen, Petri (NSN - FI/Espoo); lng-odp-forward > Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > In the platform discussion this morning the consensus was to not take this patch at this time. > > > > The rationale was that although we are at liberty to change the API as often as we want we don't want to introduce unnecessary churn when we can help it, and in this case we think we can. > > > > In this case we know the docs don't match the code, and that the documentation is not yet complete and its publication will be very soon. > > We also expect the final doc to change the API one more time. Given that all platforms and applications will have to change twice in quick succession it makes sense to sync the doc and the API before changing the code. > > > > Mike > > > > On 8 October 2014 07:45, Bill Fischofer <bill.fischofer@linaro.org> wrote: > > A conversion routine by definition bridges two types. One could just as well argue that an odp_buffer routine is now returning a packet type. and vice versa. I assume you originally came up with the from routines because they mirror standard C type casting. If this were done via a type cast you'd write: > > > > (odp_buffer_t)pkt > > > > and > > > > (odp_packet_t)buf; > > > > > > > > On Wed, Oct 8, 2014 at 6:40 AM, Savolainen, Petri (NSN - FI/Espoo) < petri.savolainen@nsn.com> wrote: > > It’s not “to” vs “from. It’s that a odp_buffer_xxx function should not use a odp_packet_t as parameter (packet inherits buffer, but not the other way around). > > > > -Petri > > > > From: ext Bill Fischofer [mailto:bill.fischofer@linaro.org] > Sent: Wednesday, October 08, 2014 2:34 PM > To: Savolainen, Petri (NSN - FI/Espoo) > Cc: Anders Roxell; lng-odp-forward > > > Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > One isn't obviously superior to the other as this is clearly a matter of personal preference. I have no problem offering choice in this if you want to introduce the "to" routines as an alternative. But I don't see the need to remove the "from" routines. If it's OK to make this change, what would prevent someone else submitting a patch to turn these back around because they felt the original "made more sense"? On what basis would we accept or reject such a patch? Do we flip-flop on things like this without any guidelines based on the last received patch? > > > > On Wed, Oct 8, 2014 at 6:17 AM, Savolainen, Petri (NSN - FI/Espoo) < petri.savolainen@nsn.com> wrote: > > Hi, > > > > Less is more in API definition. The less there are functions/options/overlap, the less there is confusion among users and the less work to implement and maintain it. > > > > -Petri > > > > > > > > From: ext Bill Fischofer [mailto:bill.fischofer@linaro.org] > Sent: Wednesday, October 08, 2014 2:09 PM > To: Anders Roxell > Cc: Savolainen, Petri (NSN - FI/Espoo); lng-odp-forward > > > Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > It may be minor, but it is a change to the API. I agree it is straightforward, but since these are trivial conversion routines, why not add these rather than replacing their predecessors? So we could offer both odp_buffer_from_packet() and odp_buffer_to_packet() at no real cost. Post-v1.0 adding the new APIs would be a minor change since it is backward-compatible, while replacing them would be a major change since it would require application source code change. > > > > Bill > > > > On Wed, Oct 8, 2014 at 4:30 AM, Anders Roxell <anders.roxell@linaro.org> wrote: > > > On 8 Oct 2014 11:23, "Savolainen, Petri (NSN - FI/Espoo)" < petri.savolainen@nsn.com> wrote: > > > > Hi, > > > > It's not a major architectural change. Just find and replace. If there's nobody against it, could we just merge it and carry on. > > I agree! > > > > > Implementations can choose to either follow the linux-generic closely or group multiple changes (= update less frequently). It's up to each implementation which strategy works the best. I think it's easier to follow a set of many small changes than few big ones (which seem to rewrite an API in one shot). > > I agree here as well! > > This was why we create different repositories... To speed up the implementation of linux-generic, right? > > Cheers, > Anders > > > > > -Petri > > > > > > > > > > > -----Original Message----- > > > From: lng-odp-bounces@lists.linaro.org [mailto:lng-odp- > > > bounces@lists.linaro.org] On Behalf Of ext Maxim Uvarov > > > Sent: Tuesday, October 07, 2014 5:11 PM > > > To: lng-odp@lists.linaro.org > > > Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > > > I think that sort of patches should have RFC for better discussion. Due > > > to that changes require everybody to do same changes (all platforms and > > > all odp apps.). It will be nice if we can group such changes when > > > merging because fixing up everything in different repos take some time... > > > > > > Maxim. > > > > > > On 10/07/2014 05:24 PM, Bill Fischofer wrote: > > > > Yes, but continuing the bootstrap, the Google docs are input to the > > > > doxygen versions which are integrated with the headers built from it. > > > > Agree the doxygen version is intended to be definitive. The prototype > > > > APIs we have pre-v1.0 are incomplete and in many cases inconsistent. > > > > The arch/design process resolves that and allows us to iterate to the > > > > final versions that will be v1.0. Otherwise we're just inventing APIs > > > > on the fly with code without any explicit design review. > > > > > > > > Bill > > > > > > > > On Tue, Oct 7, 2014 at 7:59 AM, Savolainen, Petri (NSN - FI/Espoo) > > > > <petri.savolainen@nsn.com <mailto:petri.savolainen@nsn.com>> wrote: > > > > > > > > API doc is generated with Doxygen from the headers. It's the > > > > easiest way to ensure that API definitions (in C code) and > > > > documentation are in sync. > > > > > > > > Arch docs support the doxygen documentation. > > > > > > > > -Petri > > > > > > > > *From:*ext Bill Fischofer [mailto:bill.fischofer@linaro.org > > > > <mailto:bill.fischofer@linaro.org>] > > > > *Sent:* Tuesday, October 07, 2014 3:54 PM > > > > *To:* Savolainen, Petri (NSN - FI/Espoo) > > > > *Cc:* lng-odp-forward > > > > *Subject:* Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > > > > > I'm not sure I understand this point. The design docs are the API > > > > docs. > > > > > > > > On Tue, Oct 7, 2014 at 7:07 AM, Savolainen, Petri (NSN - FI/Espoo) > > > > <petri.savolainen@nsn.com <mailto:petri.savolainen@nsn.com>> wrote: > > > > > > > > Hi. > > > > > > > > Test suite should be written from API documentation, since that's > > > > the contract for users. Arch docs should just provide additional / > > > > higher level information, so that API documentation is easier to > > > > understand. Too much details in arch doc will duplicate > > > > information (without too much added value). Does we need this > > > > level of detail (function name for conversions) in arch doc - it's > > > > enough to mention that buf <-> pkt conversion can be done using > > > > the packet API. > > > > > > > > -Petri > > > > > > > > *From:*ext Bill Fischofer [mailto:bill.fischofer@linaro.org > > > > <mailto:bill.fischofer@linaro.org>] > > > > *Sent:* Tuesday, October 07, 2014 12:22 AM > > > > *To:* Petri Savolainen > > > > *Cc:* lng-odp-forward > > > > *Subject:* Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > > > > > Can we coordinate these changes with the ongoing Packet API design > > > > work? Simply making code changes without that coordination at this > > > > point is going to get confusing. Not saying there may not be good > > > > reasons for these changes, but we want everything to sync up since > > > > the ODP Test Suite is going to be written from the design docs, > > > > not from the code. > > > > > > > > Thanks. > > > > > > > > Bill > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > lng-odp mailing list > > > > lng-odp@lists.linaro.org > > > > http://lists.linaro.org/mailman/listinfo/lng-odp > > > > > > > > > _______________________________________________ > > > lng-odp mailing list > > > lng-odp@lists.linaro.org > > > http://lists.linaro.org/mailman/listinfo/lng-odp > > > > _______________________________________________ > > lng-odp mailing list > > lng-odp@lists.linaro.org > > http://lists.linaro.org/mailman/listinfo/lng-odp > > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/lng-odp > > > > > > > > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/lng-odp > > > > > > -- > > Mike Holmes > > Linaro Sr Technical Manager > > LNG - ODP > > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/lng-odp >
I'm not sure where the idea originated that segmentation is to be removed from buffers. That seems to have been a misunderstanding on Ola's part that was cleared up during today's call. The revised buffer.h patch (and linux-generic implementation) is currently being worked on by Bala. In another thread I indicated I'm fine with this patch. On Wed, Oct 8, 2014 at 2:47 PM, Anders Roxell <anders.roxell@linaro.org> wrote: > > On 8 Oct 2014 14:55, "Savolainen, Petri (NSN - FI/Espoo)" < > petri.savolainen@nsn.com> wrote: > > > > If you consider the number of comments in that document… it will take a > while until it’s finished. And then if you look back into the buffer doc, > it’s not finished either since segmentation part should be removed from > there… and so on. > > Again I agree with Petri! > > > > > > > > > I’d rather fix only the necessary things in current APIs, documents and > test those, and call it v1.0. We’ll not have _code_ for v1.0 at the end of > the year, if we keep adding stuff into documents just for the sake of > completeness. > > If we want to do API changes to an existing header file I think we shall > do that as patches and _not_ the way we are trying to do now with a Google > docs somewhere else... > > Why I think this is a good patch is because we _don't_ have two APIs that > do the same thing and the patch makes the API clearer, which is something > you said earlier in the thread said Bill... =) > > Anders > > > > > > > > > > > > > -Petri > > > > > > > > > > > > > > > > From: ext Mike Holmes [mailto:mike.holmes@linaro.org] > > Sent: Wednesday, October 08, 2014 3:16 PM > > To: Bill Fischofer > > > > Cc: Savolainen, Petri (NSN - FI/Espoo); lng-odp-forward > > Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > > > > > In the platform discussion this morning the consensus was to not take > this patch at this time. > > > > > > > > The rationale was that although we are at liberty to change the API as > often as we want we don't want to introduce unnecessary churn when we can > help it, and in this case we think we can. > > > > > > > > In this case we know the docs don't match the code, and that the > documentation is not yet complete and its publication will be very soon. > > > > We also expect the final doc to change the API one more time. Given > that all platforms and applications will have to change twice in quick > succession it makes sense to sync the doc and the API before changing the > code. > > > > > > > > Mike > > > > > > > > On 8 October 2014 07:45, Bill Fischofer <bill.fischofer@linaro.org> > wrote: > > > > A conversion routine by definition bridges two types. One could just as > well argue that an odp_buffer routine is now returning a packet type. and > vice versa. I assume you originally came up with the from routines because > they mirror standard C type casting. If this were done via a type cast > you'd write: > > > > > > > > (odp_buffer_t)pkt > > > > > > > > and > > > > > > > > (odp_packet_t)buf; > > > > > > > > > > > > > > > > On Wed, Oct 8, 2014 at 6:40 AM, Savolainen, Petri (NSN - FI/Espoo) < > petri.savolainen@nsn.com> wrote: > > > > It’s not “to” vs “from. It’s that a odp_buffer_xxx function should not > use a odp_packet_t as parameter (packet inherits buffer, but not the other > way around). > > > > > > > > -Petri > > > > > > > > From: ext Bill Fischofer [mailto:bill.fischofer@linaro.org] > > Sent: Wednesday, October 08, 2014 2:34 PM > > To: Savolainen, Petri (NSN - FI/Espoo) > > Cc: Anders Roxell; lng-odp-forward > > > > > > Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > > > > > One isn't obviously superior to the other as this is clearly a matter of > personal preference. I have no problem offering choice in this if you want > to introduce the "to" routines as an alternative. But I don't see the need > to remove the "from" routines. If it's OK to make this change, what would > prevent someone else submitting a patch to turn these back around because > they felt the original "made more sense"? On what basis would we accept or > reject such a patch? Do we flip-flop on things like this without any > guidelines based on the last received patch? > > > > > > > > On Wed, Oct 8, 2014 at 6:17 AM, Savolainen, Petri (NSN - FI/Espoo) < > petri.savolainen@nsn.com> wrote: > > > > Hi, > > > > > > > > Less is more in API definition. The less there are > functions/options/overlap, the less there is confusion among users and the > less work to implement and maintain it. > > > > > > > > -Petri > > > > > > > > > > > > > > > > From: ext Bill Fischofer [mailto:bill.fischofer@linaro.org] > > Sent: Wednesday, October 08, 2014 2:09 PM > > To: Anders Roxell > > Cc: Savolainen, Petri (NSN - FI/Espoo); lng-odp-forward > > > > > > Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > > > > > It may be minor, but it is a change to the API. I agree it is > straightforward, but since these are trivial conversion routines, why not > add these rather than replacing their predecessors? So we could offer both > odp_buffer_from_packet() and odp_buffer_to_packet() at no real cost. > Post-v1.0 adding the new APIs would be a minor change since it is > backward-compatible, while replacing them would be a major change since it > would require application source code change. > > > > > > > > Bill > > > > > > > > On Wed, Oct 8, 2014 at 4:30 AM, Anders Roxell <anders.roxell@linaro.org> > wrote: > > > > > > On 8 Oct 2014 11:23, "Savolainen, Petri (NSN - FI/Espoo)" < > petri.savolainen@nsn.com> wrote: > > > > > > Hi, > > > > > > It's not a major architectural change. Just find and replace. If > there's nobody against it, could we just merge it and carry on. > > > > I agree! > > > > > > > > Implementations can choose to either follow the linux-generic closely > or group multiple changes (= update less frequently). It's up to each > implementation which strategy works the best. I think it's easier to follow > a set of many small changes than few big ones (which seem to rewrite an API > in one shot). > > > > I agree here as well! > > > > This was why we create different repositories... To speed up the > implementation of linux-generic, right? > > > > Cheers, > > Anders > > > > > > > > -Petri > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: lng-odp-bounces@lists.linaro.org [mailto:lng-odp- > > > > bounces@lists.linaro.org] On Behalf Of ext Maxim Uvarov > > > > Sent: Tuesday, October 07, 2014 5:11 PM > > > > To: lng-odp@lists.linaro.org > > > > Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > > > > > I think that sort of patches should have RFC for better discussion. > Due > > > > to that changes require everybody to do same changes (all platforms > and > > > > all odp apps.). It will be nice if we can group such changes when > > > > merging because fixing up everything in different repos take some > time... > > > > > > > > Maxim. > > > > > > > > On 10/07/2014 05:24 PM, Bill Fischofer wrote: > > > > > Yes, but continuing the bootstrap, the Google docs are input to the > > > > > doxygen versions which are integrated with the headers built from > it. > > > > > Agree the doxygen version is intended to be definitive. The > prototype > > > > > APIs we have pre-v1.0 are incomplete and in many cases > inconsistent. > > > > > The arch/design process resolves that and allows us to iterate to > the > > > > > final versions that will be v1.0. Otherwise we're just inventing > APIs > > > > > on the fly with code without any explicit design review. > > > > > > > > > > Bill > > > > > > > > > > On Tue, Oct 7, 2014 at 7:59 AM, Savolainen, Petri (NSN - FI/Espoo) > > > > > <petri.savolainen@nsn.com <mailto:petri.savolainen@nsn.com>> > wrote: > > > > > > > > > > API doc is generated with Doxygen from the headers. It's the > > > > > easiest way to ensure that API definitions (in C code) and > > > > > documentation are in sync. > > > > > > > > > > Arch docs support the doxygen documentation. > > > > > > > > > > -Petri > > > > > > > > > > *From:*ext Bill Fischofer [mailto:bill.fischofer@linaro.org > > > > > <mailto:bill.fischofer@linaro.org>] > > > > > *Sent:* Tuesday, October 07, 2014 3:54 PM > > > > > *To:* Savolainen, Petri (NSN - FI/Espoo) > > > > > *Cc:* lng-odp-forward > > > > > *Subject:* Re: [lng-odp] [PATCH] Rename buffer_from_packet > function > > > > > > > > > > I'm not sure I understand this point. The design docs are the > API > > > > > docs. > > > > > > > > > > On Tue, Oct 7, 2014 at 7:07 AM, Savolainen, Petri (NSN - > FI/Espoo) > > > > > <petri.savolainen@nsn.com <mailto:petri.savolainen@nsn.com>> > wrote: > > > > > > > > > > Hi. > > > > > > > > > > Test suite should be written from API documentation, since > that's > > > > > the contract for users. Arch docs should just provide > additional / > > > > > higher level information, so that API documentation is easier > to > > > > > understand. Too much details in arch doc will duplicate > > > > > information (without too much added value). Does we need this > > > > > level of detail (function name for conversions) in arch doc - > it's > > > > > enough to mention that buf <-> pkt conversion can be done using > > > > > the packet API. > > > > > > > > > > -Petri > > > > > > > > > > *From:*ext Bill Fischofer [mailto:bill.fischofer@linaro.org > > > > > <mailto:bill.fischofer@linaro.org>] > > > > > *Sent:* Tuesday, October 07, 2014 12:22 AM > > > > > *To:* Petri Savolainen > > > > > *Cc:* lng-odp-forward > > > > > *Subject:* Re: [lng-odp] [PATCH] Rename buffer_from_packet > function > > > > > > > > > > Can we coordinate these changes with the ongoing Packet API > design > > > > > work? Simply making code changes without that coordination at > this > > > > > point is going to get confusing. Not saying there may not be > good > > > > > reasons for these changes, but we want everything to sync up > since > > > > > the ODP Test Suite is going to be written from the design docs, > > > > > not from the code. > > > > > > > > > > Thanks. > > > > > > > > > > Bill > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > lng-odp mailing list > > > > > lng-odp@lists.linaro.org > > > > > http://lists.linaro.org/mailman/listinfo/lng-odp > > > > > > > > > > > > _______________________________________________ > > > > lng-odp mailing list > > > > lng-odp@lists.linaro.org > > > > http://lists.linaro.org/mailman/listinfo/lng-odp > > > > > > _______________________________________________ > > > lng-odp mailing list > > > lng-odp@lists.linaro.org > > > http://lists.linaro.org/mailman/listinfo/lng-odp > > > > > > _______________________________________________ > > lng-odp mailing list > > lng-odp@lists.linaro.org > > http://lists.linaro.org/mailman/listinfo/lng-odp > > > > > > > > > > > > > > > > > > _______________________________________________ > > lng-odp mailing list > > lng-odp@lists.linaro.org > > http://lists.linaro.org/mailman/listinfo/lng-odp > > > > > > > > > > > > -- > > > > Mike Holmes > > > > Linaro Sr Technical Manager > > > > LNG - ODP > > > > > > _______________________________________________ > > lng-odp mailing list > > lng-odp@lists.linaro.org > > http://lists.linaro.org/mailman/listinfo/lng-odp > > >
On 2014-10-06 17:25, Petri Savolainen wrote: > Rename odp_buffer_from_packet() to odp_packet_to_buffer(). > It's a function of packet API vs buffer API. > > Signed-off-by: Petri Savolainen <petri.savolainen@linaro.org> Tested-by: Anders Roxel <anders.roxell@linaro.org> > --- > example/generator/odp_generator.c | 2 +- > example/ipsec/odp_ipsec.c | 10 +++++----- > helper/include/odph_packet.h | 6 +++--- > platform/linux-generic/include/api/odp_packet.h | 6 +++--- > platform/linux-generic/odp_crypto.c | 4 ++-- > platform/linux-generic/odp_packet.c | 8 ++++---- > platform/linux-generic/odp_packet_io.c | 6 +++--- > 7 files changed, 21 insertions(+), 21 deletions(-) > > diff --git a/example/generator/odp_generator.c b/example/generator/odp_generator.c > index 6055324..5538d0c 100644 > --- a/example/generator/odp_generator.c > +++ b/example/generator/odp_generator.c > @@ -397,7 +397,7 @@ static void print_pkts(int thr, odp_packet_t pkt_tbl[], unsigned len) > > odp_atomic_inc_u64(&counters.ip); > rlen += sprintf(msg, "receive Packet proto:IP "); > - buf = odp_buffer_addr(odp_buffer_from_packet(pkt)); > + buf = odp_buffer_addr(odp_packet_to_buffer(pkt)); > ip = (odph_ipv4hdr_t *)(buf + odp_packet_l3_offset(pkt)); > rlen += sprintf(msg + rlen, "id %d ", > odp_be_to_cpu_16(ip->id)); > diff --git a/example/ipsec/odp_ipsec.c b/example/ipsec/odp_ipsec.c > index ec6c87a..56539ba 100644 > --- a/example/ipsec/odp_ipsec.c > +++ b/example/ipsec/odp_ipsec.c > @@ -738,7 +738,7 @@ pkt_disposition_e do_ipsec_in_classify(odp_packet_t pkt, > *skip = FALSE; > if (odp_crypto_operation(¶ms, > &posted, > - odp_buffer_from_packet(pkt))) { > + odp_packet_to_buffer(pkt))) { > abort(); > } > return (posted) ? PKT_POSTED : PKT_CONTINUE; > @@ -764,7 +764,7 @@ pkt_disposition_e do_ipsec_in_finish(odp_packet_t pkt, > int trl_len = 0; > > /* Check crypto result */ > - event = odp_buffer_from_packet(pkt); > + event = odp_packet_to_buffer(pkt); > odp_crypto_get_operation_compl_status(event, &cipher_rc, &auth_rc); > if (!is_crypto_compl_status_ok(&cipher_rc)) > return PKT_DROP; > @@ -935,7 +935,7 @@ pkt_disposition_e do_ipsec_out_classify(odp_packet_t pkt, > > /* Send packet to the atmoic queue to assign sequence numbers */ > *skip = FALSE; > - odp_queue_enq(seqnumq, odp_buffer_from_packet(pkt)); > + odp_queue_enq(seqnumq, odp_packet_to_buffer(pkt)); > > return PKT_POSTED; > } > @@ -974,7 +974,7 @@ pkt_disposition_e do_ipsec_out_seq(odp_packet_t pkt, > /* Issue crypto request */ > if (odp_crypto_operation(&ctx->ipsec.params, > &posted, > - odp_buffer_from_packet(pkt))) { > + odp_packet_to_buffer(pkt))) { > abort(); > } > return (posted) ? PKT_POSTED : PKT_CONTINUE; > @@ -998,7 +998,7 @@ pkt_disposition_e do_ipsec_out_finish(odp_packet_t pkt, > odph_ipv4hdr_t *ip; > > /* Check crypto result */ > - event = odp_buffer_from_packet(pkt); > + event = odp_packet_to_buffer(pkt); > odp_crypto_get_operation_compl_status(event, &cipher_rc, &auth_rc); > if (!is_crypto_compl_status_ok(&cipher_rc)) > return PKT_DROP; > diff --git a/helper/include/odph_packet.h b/helper/include/odph_packet.h > index c18f48d..3d53593 100644 > --- a/helper/include/odph_packet.h > +++ b/helper/include/odph_packet.h > @@ -31,7 +31,7 @@ extern "C" { > */ > static inline int odph_packet_is_valid(odp_packet_t pkt) > { > - odp_buffer_t buf = odp_buffer_from_packet(pkt); > + odp_buffer_t buf = odp_packet_to_buffer(pkt); > > return odp_buffer_is_valid(buf); > } > @@ -67,7 +67,7 @@ static inline odp_packet_t odph_packet_alloc(odp_buffer_pool_t pool_id) > */ > static inline void odph_packet_free(odp_packet_t pkt) > { > - odp_buffer_t buf = odp_buffer_from_packet(pkt); > + odp_buffer_t buf = odp_packet_to_buffer(pkt); > > odp_buffer_free(buf); > } > @@ -84,7 +84,7 @@ static inline void odph_packet_free(odp_packet_t pkt) > */ > static inline size_t odph_packet_buf_size(odp_packet_t pkt) > { > - odp_buffer_t buf = odp_buffer_from_packet(pkt); > + odp_buffer_t buf = odp_packet_to_buffer(pkt); > > return odp_buffer_size(buf); > } > diff --git a/platform/linux-generic/include/api/odp_packet.h b/platform/linux-generic/include/api/odp_packet.h > index 316279b..8204000 100644 > --- a/platform/linux-generic/include/api/odp_packet.h > +++ b/platform/linux-generic/include/api/odp_packet.h > @@ -63,7 +63,7 @@ typedef struct odp_packet_seg_info_t { > void odp_packet_init(odp_packet_t pkt); > > /** > - * Convert from packet handle to buffer handle > + * Convert a buffer handle to a packet handle > * > * @param buf Buffer handle > * > @@ -72,13 +72,13 @@ void odp_packet_init(odp_packet_t pkt); > odp_packet_t odp_packet_from_buffer(odp_buffer_t buf); > > /** > - * Convert from buffer handle to packet handle > + * Convert a packet handle to a buffer handle > * > * @param pkt Packet handle > * > * @return Buffer handle > */ > -odp_buffer_t odp_buffer_from_packet(odp_packet_t pkt); > +odp_buffer_t odp_packet_to_buffer(odp_packet_t pkt); > > /** > * Set the packet length > diff --git a/platform/linux-generic/odp_crypto.c b/platform/linux-generic/odp_crypto.c > index b37ad6b..1475437 100644 > --- a/platform/linux-generic/odp_crypto.c > +++ b/platform/linux-generic/odp_crypto.c > @@ -367,9 +367,9 @@ odp_crypto_operation(odp_crypto_op_params_t *params, > if (odp_unlikely(ODP_PACKET_INVALID == params->out_pkt)) > abort(); > odp_packet_copy(params->out_pkt, params->pkt); > - if (completion_event == odp_buffer_from_packet(params->pkt)) > + if (completion_event == odp_packet_to_buffer(params->pkt)) > completion_event = > - odp_buffer_from_packet(params->out_pkt); > + odp_packet_to_buffer(params->out_pkt); > odph_packet_free(params->pkt); > params->pkt = ODP_PACKET_INVALID; > } > diff --git a/platform/linux-generic/odp_packet.c b/platform/linux-generic/odp_packet.c > index 435bc8b..82ea879 100644 > --- a/platform/linux-generic/odp_packet.c > +++ b/platform/linux-generic/odp_packet.c > @@ -41,7 +41,7 @@ odp_packet_t odp_packet_from_buffer(odp_buffer_t buf) > return (odp_packet_t)buf; > } > > -odp_buffer_t odp_buffer_from_packet(odp_packet_t pkt) > +odp_buffer_t odp_packet_to_buffer(odp_packet_t pkt) > { > return (odp_buffer_t)pkt; > } > @@ -58,7 +58,7 @@ size_t odp_packet_get_len(odp_packet_t pkt) > > uint8_t *odp_packet_addr(odp_packet_t pkt) > { > - return odp_buffer_addr(odp_buffer_from_packet(pkt)); > + return odp_buffer_addr(odp_packet_to_buffer(pkt)); > } > > uint8_t *odp_packet_data(odp_packet_t pkt) > @@ -381,8 +381,8 @@ int odp_packet_copy(odp_packet_t pkt_dst, odp_packet_t pkt_src) > pkt_hdr_dst->buf_hdr.cur_offset = pkt_hdr_src->buf_hdr.cur_offset; > > /* Create a copy of the scatter list */ > - odp_buffer_copy_scatter(odp_buffer_from_packet(pkt_dst), > - odp_buffer_from_packet(pkt_src)); > + odp_buffer_copy_scatter(odp_packet_to_buffer(pkt_dst), > + odp_packet_to_buffer(pkt_src)); > > return 0; > } > diff --git a/platform/linux-generic/odp_packet_io.c b/platform/linux-generic/odp_packet_io.c > index 0c30f0f..d6f86ce 100644 > --- a/platform/linux-generic/odp_packet_io.c > +++ b/platform/linux-generic/odp_packet_io.c > @@ -431,11 +431,11 @@ odp_buffer_hdr_t *pktin_dequeue(queue_entry_t *qentry) > > if (pkts > 0) { > pkt = pkt_tbl[0]; > - buf = odp_buffer_from_packet(pkt); > + buf = odp_packet_to_buffer(pkt); > buf_hdr = odp_buf_to_hdr(buf); > > for (i = 1, j = 0; i < pkts; ++i) { > - buf = odp_buffer_from_packet(pkt_tbl[i]); > + buf = odp_packet_to_buffer(pkt_tbl[i]); > tmp_hdr_tbl[j++] = odp_buf_to_hdr(buf); > } > queue_enq_multi(qentry, tmp_hdr_tbl, j); > @@ -467,7 +467,7 @@ int pktin_deq_multi(queue_entry_t *qentry, odp_buffer_hdr_t *buf_hdr[], int num) > QUEUE_MULTI_MAX); > if (pkts > 0) { > for (i = 0; i < pkts; ++i) { > - buf = odp_buffer_from_packet(pkt_tbl[i]); > + buf = odp_packet_to_buffer(pkt_tbl[i]); > tmp_hdr_tbl[i] = odp_buf_to_hdr(buf); > } > queue_enq_multi(qentry, tmp_hdr_tbl, pkts); > -- > 2.1.1 > > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/lng-odp
On 8 October 2014 21:52, Bill Fischofer <bill.fischofer@linaro.org> wrote: > I'm not sure where the idea originated that segmentation is to be removed > from buffers. That seems to have been a misunderstanding on Ola's part > that was cleared up during today's call. The revised buffer.h patch (and > linux-generic implementation) is currently being worked on by Bala. > > In another thread I indicated I'm fine with this patch. > You should have said that in this thread! and you need to add Reviewed-by: name <email> here then. =) Cheers, Anders > On Wed, Oct 8, 2014 at 2:47 PM, Anders Roxell <anders.roxell@linaro.org> > wrote: > >> >> On 8 Oct 2014 14:55, "Savolainen, Petri (NSN - FI/Espoo)" < >> petri.savolainen@nsn.com> wrote: >> > >> > If you consider the number of comments in that document… it will take a >> while until it’s finished. And then if you look back into the buffer doc, >> it’s not finished either since segmentation part should be removed from >> there… and so on. >> >> Again I agree with Petri! >> >> > >> > >> > >> > I’d rather fix only the necessary things in current APIs, documents and >> test those, and call it v1.0. We’ll not have _code_ for v1.0 at the end of >> the year, if we keep adding stuff into documents just for the sake of >> completeness. >> >> If we want to do API changes to an existing header file I think we shall >> do that as patches and _not_ the way we are trying to do now with a Google >> docs somewhere else... >> >> Why I think this is a good patch is because we _don't_ have two APIs that >> do the same thing and the patch makes the API clearer, which is something >> you said earlier in the thread said Bill... =) >> >> Anders >> >> > >> > >> > >> > >> > >> > -Petri >> > >> > >> > >> > >> > >> > >> > >> > From: ext Mike Holmes [mailto:mike.holmes@linaro.org] >> > Sent: Wednesday, October 08, 2014 3:16 PM >> > To: Bill Fischofer >> > >> > Cc: Savolainen, Petri (NSN - FI/Espoo); lng-odp-forward >> > Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function >> > >> > >> > >> > In the platform discussion this morning the consensus was to not take >> this patch at this time. >> > >> > >> > >> > The rationale was that although we are at liberty to change the API as >> often as we want we don't want to introduce unnecessary churn when we can >> help it, and in this case we think we can. >> > >> > >> > >> > In this case we know the docs don't match the code, and that the >> documentation is not yet complete and its publication will be very soon. >> > >> > We also expect the final doc to change the API one more time. Given >> that all platforms and applications will have to change twice in quick >> succession it makes sense to sync the doc and the API before changing the >> code. >> > >> > >> > >> > Mike >> > >> > >> > >> > On 8 October 2014 07:45, Bill Fischofer <bill.fischofer@linaro.org> >> wrote: >> > >> > A conversion routine by definition bridges two types. One could just >> as well argue that an odp_buffer routine is now returning a packet type. >> and vice versa. I assume you originally came up with the from routines >> because they mirror standard C type casting. If this were done via a type >> cast you'd write: >> > >> > >> > >> > (odp_buffer_t)pkt >> > >> > >> > >> > and >> > >> > >> > >> > (odp_packet_t)buf; >> > >> > >> > >> > >> > >> > >> > >> > On Wed, Oct 8, 2014 at 6:40 AM, Savolainen, Petri (NSN - FI/Espoo) < >> petri.savolainen@nsn.com> wrote: >> > >> > It’s not “to” vs “from. It’s that a odp_buffer_xxx function should not >> use a odp_packet_t as parameter (packet inherits buffer, but not the other >> way around). >> > >> > >> > >> > -Petri >> > >> > >> > >> > From: ext Bill Fischofer [mailto:bill.fischofer@linaro.org] >> > Sent: Wednesday, October 08, 2014 2:34 PM >> > To: Savolainen, Petri (NSN - FI/Espoo) >> > Cc: Anders Roxell; lng-odp-forward >> > >> > >> > Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function >> > >> > >> > >> > One isn't obviously superior to the other as this is clearly a matter >> of personal preference. I have no problem offering choice in this if you >> want to introduce the "to" routines as an alternative. But I don't see the >> need to remove the "from" routines. If it's OK to make this change, what >> would prevent someone else submitting a patch to turn these back around >> because they felt the original "made more sense"? On what basis would we >> accept or reject such a patch? Do we flip-flop on things like this without >> any guidelines based on the last received patch? >> > >> > >> > >> > On Wed, Oct 8, 2014 at 6:17 AM, Savolainen, Petri (NSN - FI/Espoo) < >> petri.savolainen@nsn.com> wrote: >> > >> > Hi, >> > >> > >> > >> > Less is more in API definition. The less there are >> functions/options/overlap, the less there is confusion among users and the >> less work to implement and maintain it. >> > >> > >> > >> > -Petri >> > >> > >> > >> > >> > >> > >> > >> > From: ext Bill Fischofer [mailto:bill.fischofer@linaro.org] >> > Sent: Wednesday, October 08, 2014 2:09 PM >> > To: Anders Roxell >> > Cc: Savolainen, Petri (NSN - FI/Espoo); lng-odp-forward >> > >> > >> > Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function >> > >> > >> > >> > It may be minor, but it is a change to the API. I agree it is >> straightforward, but since these are trivial conversion routines, why not >> add these rather than replacing their predecessors? So we could offer both >> odp_buffer_from_packet() and odp_buffer_to_packet() at no real cost. >> Post-v1.0 adding the new APIs would be a minor change since it is >> backward-compatible, while replacing them would be a major change since it >> would require application source code change. >> > >> > >> > >> > Bill >> > >> > >> > >> > On Wed, Oct 8, 2014 at 4:30 AM, Anders Roxell <anders.roxell@linaro.org> >> wrote: >> > >> > >> > On 8 Oct 2014 11:23, "Savolainen, Petri (NSN - FI/Espoo)" < >> petri.savolainen@nsn.com> wrote: >> > > >> > > Hi, >> > > >> > > It's not a major architectural change. Just find and replace. If >> there's nobody against it, could we just merge it and carry on. >> > >> > I agree! >> > >> > > >> > > Implementations can choose to either follow the linux-generic closely >> or group multiple changes (= update less frequently). It's up to each >> implementation which strategy works the best. I think it's easier to follow >> a set of many small changes than few big ones (which seem to rewrite an API >> in one shot). >> > >> > I agree here as well! >> > >> > This was why we create different repositories... To speed up the >> implementation of linux-generic, right? >> > >> > Cheers, >> > Anders >> > >> > > >> > > -Petri >> > > >> > > >> > > >> > > >> > > > -----Original Message----- >> > > > From: lng-odp-bounces@lists.linaro.org [mailto:lng-odp- >> > > > bounces@lists.linaro.org] On Behalf Of ext Maxim Uvarov >> > > > Sent: Tuesday, October 07, 2014 5:11 PM >> > > > To: lng-odp@lists.linaro.org >> > > > Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function >> > > > >> > > > I think that sort of patches should have RFC for better discussion. >> Due >> > > > to that changes require everybody to do same changes (all platforms >> and >> > > > all odp apps.). It will be nice if we can group such changes when >> > > > merging because fixing up everything in different repos take some >> time... >> > > > >> > > > Maxim. >> > > > >> > > > On 10/07/2014 05:24 PM, Bill Fischofer wrote: >> > > > > Yes, but continuing the bootstrap, the Google docs are input to >> the >> > > > > doxygen versions which are integrated with the headers built from >> it. >> > > > > Agree the doxygen version is intended to be definitive. The >> prototype >> > > > > APIs we have pre-v1.0 are incomplete and in many cases >> inconsistent. >> > > > > The arch/design process resolves that and allows us to iterate to >> the >> > > > > final versions that will be v1.0. Otherwise we're just inventing >> APIs >> > > > > on the fly with code without any explicit design review. >> > > > > >> > > > > Bill >> > > > > >> > > > > On Tue, Oct 7, 2014 at 7:59 AM, Savolainen, Petri (NSN - FI/Espoo) >> > > > > <petri.savolainen@nsn.com <mailto:petri.savolainen@nsn.com>> >> wrote: >> > > > > >> > > > > API doc is generated with Doxygen from the headers. It's the >> > > > > easiest way to ensure that API definitions (in C code) and >> > > > > documentation are in sync. >> > > > > >> > > > > Arch docs support the doxygen documentation. >> > > > > >> > > > > -Petri >> > > > > >> > > > > *From:*ext Bill Fischofer [mailto:bill.fischofer@linaro.org >> > > > > <mailto:bill.fischofer@linaro.org>] >> > > > > *Sent:* Tuesday, October 07, 2014 3:54 PM >> > > > > *To:* Savolainen, Petri (NSN - FI/Espoo) >> > > > > *Cc:* lng-odp-forward >> > > > > *Subject:* Re: [lng-odp] [PATCH] Rename buffer_from_packet >> function >> > > > > >> > > > > I'm not sure I understand this point. The design docs are the >> API >> > > > > docs. >> > > > > >> > > > > On Tue, Oct 7, 2014 at 7:07 AM, Savolainen, Petri (NSN - >> FI/Espoo) >> > > > > <petri.savolainen@nsn.com <mailto:petri.savolainen@nsn.com>> >> wrote: >> > > > > >> > > > > Hi. >> > > > > >> > > > > Test suite should be written from API documentation, since >> that's >> > > > > the contract for users. Arch docs should just provide >> additional / >> > > > > higher level information, so that API documentation is easier >> to >> > > > > understand. Too much details in arch doc will duplicate >> > > > > information (without too much added value). Does we need this >> > > > > level of detail (function name for conversions) in arch doc - >> it's >> > > > > enough to mention that buf <-> pkt conversion can be done >> using >> > > > > the packet API. >> > > > > >> > > > > -Petri >> > > > > >> > > > > *From:*ext Bill Fischofer [mailto:bill.fischofer@linaro.org >> > > > > <mailto:bill.fischofer@linaro.org>] >> > > > > *Sent:* Tuesday, October 07, 2014 12:22 AM >> > > > > *To:* Petri Savolainen >> > > > > *Cc:* lng-odp-forward >> > > > > *Subject:* Re: [lng-odp] [PATCH] Rename buffer_from_packet >> function >> > > > > >> > > > > Can we coordinate these changes with the ongoing Packet API >> design >> > > > > work? Simply making code changes without that coordination at >> this >> > > > > point is going to get confusing. Not saying there may not be >> good >> > > > > reasons for these changes, but we want everything to sync up >> since >> > > > > the ODP Test Suite is going to be written from the design >> docs, >> > > > > not from the code. >> > > > > >> > > > > Thanks. >> > > > > >> > > > > Bill >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > _______________________________________________ >> > > > > lng-odp mailing list >> > > > > lng-odp@lists.linaro.org >> > > > > http://lists.linaro.org/mailman/listinfo/lng-odp >> > > > >> > > > >> > > > _______________________________________________ >> > > > lng-odp mailing list >> > > > lng-odp@lists.linaro.org >> > > > http://lists.linaro.org/mailman/listinfo/lng-odp >> > > >> > > _______________________________________________ >> > > lng-odp mailing list >> > > lng-odp@lists.linaro.org >> > > http://lists.linaro.org/mailman/listinfo/lng-odp >> > >> > >> > _______________________________________________ >> > lng-odp mailing list >> > lng-odp@lists.linaro.org >> > http://lists.linaro.org/mailman/listinfo/lng-odp >> > >> > >> > >> > >> > >> > >> > >> > >> > _______________________________________________ >> > lng-odp mailing list >> > lng-odp@lists.linaro.org >> > http://lists.linaro.org/mailman/listinfo/lng-odp >> > >> > >> > >> > >> > >> > -- >> > >> > Mike Holmes >> > >> > Linaro Sr Technical Manager >> > >> > LNG - ODP >> > >> > >> > _______________________________________________ >> > lng-odp mailing list >> > lng-odp@lists.linaro.org >> > http://lists.linaro.org/mailman/listinfo/lng-odp >> > >> > >
Hi, The main use case for segmentation is handling of scatter-gather lists of large packets. Timeout notifications do not need segmentation support. Those are the two buffer types defined so far (with raw buffers you are on your own). So today only packet need that support. IF we create another buffer type in future (e.g. for standard IPC) that’d need segmentation support we may end up still adding it there on the type level (along with other useful meta data), and not on buffer level. So, I’d leave buffer segmentation out from v1.0 since it’s not absolutely needed. It’s easier to add it later, than remove it. -Petri From: ext Bill Fischofer [mailto:bill.fischofer@linaro.org] Sent: Wednesday, October 08, 2014 10:52 PM To: Anders Roxell Cc: Savolainen, Petri (NSN - FI/Espoo); lng-odp-forward Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function I'm not sure where the idea originated that segmentation is to be removed from buffers. That seems to have been a misunderstanding on Ola's part that was cleared up during today's call. The revised buffer.h patch (and linux-generic implementation) is currently being worked on by Bala. In another thread I indicated I'm fine with this patch. On Wed, Oct 8, 2014 at 2:47 PM, Anders Roxell <anders.roxell@linaro.org<mailto:anders.roxell@linaro.org>> wrote: On 8 Oct 2014 14:55, "Savolainen, Petri (NSN - FI/Espoo)" <petri.savolainen@nsn.com<mailto:petri.savolainen@nsn.com>> wrote: > > If you consider the number of comments in that document… it will take a while until it’s finished. And then if you look back into the buffer doc, it’s not finished either since segmentation part should be removed from there… and so on. Again I agree with Petri! > > > > I’d rather fix only the necessary things in current APIs, documents and test those, and call it v1.0. We’ll not have _code_ for v1.0 at the end of the year, if we keep adding stuff into documents just for the sake of completeness. If we want to do API changes to an existing header file I think we shall do that as patches and _not_ the way we are trying to do now with a Google docs somewhere else... Why I think this is a good patch is because we _don't_ have two APIs that do the same thing and the patch makes the API clearer, which is something you said earlier in the thread said Bill... =) Anders > > > > > > -Petri > > > > > > > > From: ext Mike Holmes [mailto:mike.holmes@linaro.org<mailto:mike.holmes@linaro.org>] > Sent: Wednesday, October 08, 2014 3:16 PM > To: Bill Fischofer > > Cc: Savolainen, Petri (NSN - FI/Espoo); lng-odp-forward > Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > In the platform discussion this morning the consensus was to not take this patch at this time. > > > > The rationale was that although we are at liberty to change the API as often as we want we don't want to introduce unnecessary churn when we can help it, and in this case we think we can. > > > > In this case we know the docs don't match the code, and that the documentation is not yet complete and its publication will be very soon. > > We also expect the final doc to change the API one more time. Given that all platforms and applications will have to change twice in quick succession it makes sense to sync the doc and the API before changing the code. > > > > Mike > > > > On 8 October 2014 07:45, Bill Fischofer <bill.fischofer@linaro.org<mailto:bill.fischofer@linaro.org>> wrote: > > A conversion routine by definition bridges two types. One could just as well argue that an odp_buffer routine is now returning a packet type. and vice versa. I assume you originally came up with the from routines because they mirror standard C type casting. If this were done via a type cast you'd write: > > > > (odp_buffer_t)pkt > > > > and > > > > (odp_packet_t)buf; > > > > > > > > On Wed, Oct 8, 2014 at 6:40 AM, Savolainen, Petri (NSN - FI/Espoo) <petri.savolainen@nsn.com<mailto:petri.savolainen@nsn.com>> wrote: > > It’s not “to” vs “from. It’s that a odp_buffer_xxx function should not use a odp_packet_t as parameter (packet inherits buffer, but not the other way around). > > > > -Petri > > > > From: ext Bill Fischofer [mailto:bill.fischofer@linaro.org<mailto:bill.fischofer@linaro.org>] > Sent: Wednesday, October 08, 2014 2:34 PM > To: Savolainen, Petri (NSN - FI/Espoo) > Cc: Anders Roxell; lng-odp-forward > > > Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > One isn't obviously superior to the other as this is clearly a matter of personal preference. I have no problem offering choice in this if you want to introduce the "to" routines as an alternative. But I don't see the need to remove the "from" routines. If it's OK to make this change, what would prevent someone else submitting a patch to turn these back around because they felt the original "made more sense"? On what basis would we accept or reject such a patch? Do we flip-flop on things like this without any guidelines based on the last received patch? > > > > On Wed, Oct 8, 2014 at 6:17 AM, Savolainen, Petri (NSN - FI/Espoo) <petri.savolainen@nsn.com<mailto:petri.savolainen@nsn.com>> wrote: > > Hi, > > > > Less is more in API definition. The less there are functions/options/overlap, the less there is confusion among users and the less work to implement and maintain it. > > > > -Petri > > > > > > > > From: ext Bill Fischofer [mailto:bill.fischofer@linaro.org<mailto:bill.fischofer@linaro.org>] > Sent: Wednesday, October 08, 2014 2:09 PM > To: Anders Roxell > Cc: Savolainen, Petri (NSN - FI/Espoo); lng-odp-forward > > > Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > It may be minor, but it is a change to the API. I agree it is straightforward, but since these are trivial conversion routines, why not add these rather than replacing their predecessors? So we could offer both odp_buffer_from_packet() and odp_buffer_to_packet() at no real cost. Post-v1.0 adding the new APIs would be a minor change since it is backward-compatible, while replacing them would be a major change since it would require application source code change. > > > > Bill > > > > On Wed, Oct 8, 2014 at 4:30 AM, Anders Roxell <anders.roxell@linaro.org<mailto:anders.roxell@linaro.org>> wrote: > > > On 8 Oct 2014 11:23, "Savolainen, Petri (NSN - FI/Espoo)" <petri.savolainen@nsn.com<mailto:petri.savolainen@nsn.com>> wrote: > > > > Hi, > > > > It's not a major architectural change. Just find and replace. If there's nobody against it, could we just merge it and carry on. > > I agree! > > > > > Implementations can choose to either follow the linux-generic closely or group multiple changes (= update less frequently). It's up to each implementation which strategy works the best. I think it's easier to follow a set of many small changes than few big ones (which seem to rewrite an API in one shot). > > I agree here as well! > > This was why we create different repositories... To speed up the implementation of linux-generic, right? > > Cheers, > Anders > > > > > -Petri > > > > > > > > > > > -----Original Message----- > > > From: lng-odp-bounces@lists.linaro.org<mailto:lng-odp-bounces@lists.linaro.org> [mailto:lng-odp-<mailto:lng-odp-> > > > bounces@lists.linaro.org<mailto:bounces@lists.linaro.org>] On Behalf Of ext Maxim Uvarov > > > Sent: Tuesday, October 07, 2014 5:11 PM > > > To: lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org> > > > Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > > > I think that sort of patches should have RFC for better discussion. Due > > > to that changes require everybody to do same changes (all platforms and > > > all odp apps.). It will be nice if we can group such changes when > > > merging because fixing up everything in different repos take some time... > > > > > > Maxim. > > > > > > On 10/07/2014 05:24 PM, Bill Fischofer wrote: > > > > Yes, but continuing the bootstrap, the Google docs are input to the > > > > doxygen versions which are integrated with the headers built from it. > > > > Agree the doxygen version is intended to be definitive. The prototype > > > > APIs we have pre-v1.0 are incomplete and in many cases inconsistent. > > > > The arch/design process resolves that and allows us to iterate to the > > > > final versions that will be v1.0. Otherwise we're just inventing APIs > > > > on the fly with code without any explicit design review. > > > > > > > > Bill > > > > > > > > On Tue, Oct 7, 2014 at 7:59 AM, Savolainen, Petri (NSN - FI/Espoo) > > > > <petri.savolainen@nsn.com<mailto:petri.savolainen@nsn.com> <mailto:petri.savolainen@nsn.com<mailto:petri.savolainen@nsn.com>>> wrote: > > > > > > > > API doc is generated with Doxygen from the headers. It's the > > > > easiest way to ensure that API definitions (in C code) and > > > > documentation are in sync. > > > > > > > > Arch docs support the doxygen documentation. > > > > > > > > -Petri > > > > > > > > *From:*ext Bill Fischofer [mailto:bill.fischofer@linaro.org<mailto:bill.fischofer@linaro.org> > > > > <mailto:bill.fischofer@linaro.org<mailto:bill.fischofer@linaro.org>>] > > > > *Sent:* Tuesday, October 07, 2014 3:54 PM > > > > *To:* Savolainen, Petri (NSN - FI/Espoo) > > > > *Cc:* lng-odp-forward > > > > *Subject:* Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > > > > > I'm not sure I understand this point. The design docs are the API > > > > docs. > > > > > > > > On Tue, Oct 7, 2014 at 7:07 AM, Savolainen, Petri (NSN - FI/Espoo) > > > > <petri.savolainen@nsn.com<mailto:petri.savolainen@nsn.com> <mailto:petri.savolainen@nsn.com<mailto:petri.savolainen@nsn.com>>> wrote: > > > > > > > > Hi. > > > > > > > > Test suite should be written from API documentation, since that's > > > > the contract for users. Arch docs should just provide additional / > > > > higher level information, so that API documentation is easier to > > > > understand. Too much details in arch doc will duplicate > > > > information (without too much added value). Does we need this > > > > level of detail (function name for conversions) in arch doc - it's > > > > enough to mention that buf <-> pkt conversion can be done using > > > > the packet API. > > > > > > > > -Petri > > > > > > > > *From:*ext Bill Fischofer [mailto:bill.fischofer@linaro.org<mailto:bill.fischofer@linaro.org> > > > > <mailto:bill.fischofer@linaro.org<mailto:bill.fischofer@linaro.org>>] > > > > *Sent:* Tuesday, October 07, 2014 12:22 AM > > > > *To:* Petri Savolainen > > > > *Cc:* lng-odp-forward > > > > *Subject:* Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > > > > > Can we coordinate these changes with the ongoing Packet API design > > > > work? Simply making code changes without that coordination at this > > > > point is going to get confusing. Not saying there may not be good > > > > reasons for these changes, but we want everything to sync up since > > > > the ODP Test Suite is going to be written from the design docs, > > > > not from the code. > > > > > > > > Thanks. > > > > > > > > Bill > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > lng-odp mailing list > > > > lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org> > > > > http://lists.linaro.org/mailman/listinfo/lng-odp > > > > > > > > > _______________________________________________ > > > lng-odp mailing list > > > lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org> > > > http://lists.linaro.org/mailman/listinfo/lng-odp > > > > _______________________________________________ > > lng-odp mailing list > > lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org> > > http://lists.linaro.org/mailman/listinfo/lng-odp > > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org> > http://lists.linaro.org/mailman/listinfo/lng-odp > > > > > > > > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org> > http://lists.linaro.org/mailman/listinfo/lng-odp > > > > > > -- > > Mike Holmes > > Linaro Sr Technical Manager > > LNG - ODP > > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org> > http://lists.linaro.org/mailman/listinfo/lng-odp >
I don't understand if you are advocating not supporting buffer segmentation at all or just limiting it to the packet buffers level, but if it’s the former than you are shutting out an NPS-400 ODP 1.0 platform implementation (our maximum packet buffer segments are 256 bytes long).
I'd be very happy if you can at least leave the API definition for 1.0, even if linux-generic would only implement single segments.
Thanks,
Gilad
Gilad Ben-Yossef
Software Architect
EZchip Technologies Ltd.
37 Israel Pollak Ave, Kiryat Gat 82025 ,Israel
Tel: +972-4-959-6666 ext. 576, Fax: +972-8-681-1483
Mobile: +972-52-826-0388, US Mobile: +1-973-826-0388
Email: giladb@ezchip.com<mailto:giladb@ezchip.com>, Web: http://www.ezchip.com<http://www.ezchip.com/>
"Ethernet always wins."
— Andy Bechtolsheim
From: lng-odp-bounces@lists.linaro.org [mailto:lng-odp-bounces@lists.linaro.org] On Behalf Of Savolainen, Petri (NSN - FI/Espoo)
Sent: Thursday, October 09, 2014 10:15 AM
To: ext Bill Fischofer; Anders Roxell
Cc: lng-odp-forward
Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function
Hi,
The main use case for segmentation is handling of scatter-gather lists of large packets. Timeout notifications do not need segmentation support. Those are the two buffer types defined so far (with raw buffers you are on your own). So today only packet need that support. IF we create another buffer type in future (e.g. for standard IPC) that’d need segmentation support we may end up still adding it there on the type level (along with other useful meta data), and not on buffer level.
So, I’d leave buffer segmentation out from v1.0 since it’s not absolutely needed. It’s easier to add it later, than remove it.
-Petri
From: ext Bill Fischofer [mailto:bill.fischofer@linaro.org]
Sent: Wednesday, October 08, 2014 10:52 PM
To: Anders Roxell
Cc: Savolainen, Petri (NSN - FI/Espoo); lng-odp-forward
Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function
I'm not sure where the idea originated that segmentation is to be removed from buffers. That seems to have been a misunderstanding on Ola's part that was cleared up during today's call. The revised buffer.h patch (and linux-generic implementation) is currently being worked on by Bala.
In another thread I indicated I'm fine with this patch.
On Wed, Oct 8, 2014 at 2:47 PM, Anders Roxell <anders.roxell@linaro.org<mailto:anders.roxell@linaro.org>> wrote:
On 8 Oct 2014 14:55, "Savolainen, Petri (NSN - FI/Espoo)" <petri.savolainen@nsn.com<mailto:petri.savolainen@nsn.com>> wrote:
>
> If you consider the number of comments in that document… it will take a while until it’s finished. And then if you look back into the buffer doc, it’s not finished either since segmentation part should be removed from there… and so on.
Again I agree with Petri!
>
>
>
> I’d rather fix only the necessary things in current APIs, documents and test those, and call it v1.0. We’ll not have _code_ for v1.0 at the end of the year, if we keep adding stuff into documents just for the sake of completeness.
If we want to do API changes to an existing header file I think we shall do that as patches and _not_ the way we are trying to do now with a Google docs somewhere else...
Why I think this is a good patch is because we _don't_ have two APIs that do the same thing and the patch makes the API clearer, which is something you said earlier in the thread said Bill... =)
Anders
>
>
>
>
>
> -Petri
>
>
>
>
>
>
>
> From: ext Mike Holmes [mailto:mike.holmes@linaro.org<mailto:mike.holmes@linaro.org>]
> Sent: Wednesday, October 08, 2014 3:16 PM
> To: Bill Fischofer
>
> Cc: Savolainen, Petri (NSN - FI/Espoo); lng-odp-forward
> Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function
>
>
>
> In the platform discussion this morning the consensus was to not take this patch at this time.
>
>
>
> The rationale was that although we are at liberty to change the API as often as we want we don't want to introduce unnecessary churn when we can help it, and in this case we think we can.
>
>
>
> In this case we know the docs don't match the code, and that the documentation is not yet complete and its publication will be very soon.
>
> We also expect the final doc to change the API one more time. Given that all platforms and applications will have to change twice in quick succession it makes sense to sync the doc and the API before changing the code.
>
>
>
> Mike
>
>
>
> On 8 October 2014 07:45, Bill Fischofer <bill.fischofer@linaro.org<mailto:bill.fischofer@linaro.org>> wrote:
>
> A conversion routine by definition bridges two types. One could just as well argue that an odp_buffer routine is now returning a packet type. and vice versa. I assume you originally came up with the from routines because they mirror standard C type casting. If this were done via a type cast you'd write:
>
>
>
> (odp_buffer_t)pkt
>
>
>
> and
>
>
>
> (odp_packet_t)buf;
>
>
>
>
>
>
>
> On Wed, Oct 8, 2014 at 6:40 AM, Savolainen, Petri (NSN - FI/Espoo) <petri.savolainen@nsn.com<mailto:petri.savolainen@nsn.com>> wrote:
>
> It’s not “to” vs “from. It’s that a odp_buffer_xxx function should not use a odp_packet_t as parameter (packet inherits buffer, but not the other way around).
>
>
>
> -Petri
>
>
>
> From: ext Bill Fischofer [mailto:bill.fischofer@linaro.org<mailto:bill.fischofer@linaro.org>]
> Sent: Wednesday, October 08, 2014 2:34 PM
> To: Savolainen, Petri (NSN - FI/Espoo)
> Cc: Anders Roxell; lng-odp-forward
>
>
> Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function
>
>
>
> One isn't obviously superior to the other as this is clearly a matter of personal preference. I have no problem offering choice in this if you want to introduce the "to" routines as an alternative. But I don't see the need to remove the "from" routines. If it's OK to make this change, what would prevent someone else submitting a patch to turn these back around because they felt the original "made more sense"? On what basis would we accept or reject such a patch? Do we flip-flop on things like this without any guidelines based on the last received patch?
>
>
>
> On Wed, Oct 8, 2014 at 6:17 AM, Savolainen, Petri (NSN - FI/Espoo) <petri.savolainen@nsn.com<mailto:petri.savolainen@nsn.com>> wrote:
>
> Hi,
>
>
>
> Less is more in API definition. The less there are functions/options/overlap, the less there is confusion among users and the less work to implement and maintain it.
>
>
>
> -Petri
>
>
>
>
>
>
>
> From: ext Bill Fischofer [mailto:bill.fischofer@linaro.org<mailto:bill.fischofer@linaro.org>]
> Sent: Wednesday, October 08, 2014 2:09 PM
> To: Anders Roxell
> Cc: Savolainen, Petri (NSN - FI/Espoo); lng-odp-forward
>
>
> Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function
>
>
>
> It may be minor, but it is a change to the API. I agree it is straightforward, but since these are trivial conversion routines, why not add these rather than replacing their predecessors? So we could offer both odp_buffer_from_packet() and odp_buffer_to_packet() at no real cost. Post-v1.0 adding the new APIs would be a minor change since it is backward-compatible, while replacing them would be a major change since it would require application source code change.
>
>
>
> Bill
>
>
>
> On Wed, Oct 8, 2014 at 4:30 AM, Anders Roxell <anders.roxell@linaro.org<mailto:anders.roxell@linaro.org>> wrote:
>
>
> On 8 Oct 2014 11:23, "Savolainen, Petri (NSN - FI/Espoo)" <petri.savolainen@nsn.com<mailto:petri.savolainen@nsn.com>> wrote:
> >
> > Hi,
> >
> > It's not a major architectural change. Just find and replace. If there's nobody against it, could we just merge it and carry on.
>
> I agree!
>
> >
> > Implementations can choose to either follow the linux-generic closely or group multiple changes (= update less frequently). It's up to each implementation which strategy works the best. I think it's easier to follow a set of many small changes than few big ones (which seem to rewrite an API in one shot).
>
> I agree here as well!
>
> This was why we create different repositories... To speed up the implementation of linux-generic, right?
>
> Cheers,
> Anders
>
> >
> > -Petri
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: lng-odp-bounces@lists.linaro.org<mailto:lng-odp-bounces@lists.linaro.org> [mailto:lng-odp-<mailto:lng-odp->
> > > bounces@lists.linaro.org<mailto:bounces@lists.linaro.org>] On Behalf Of ext Maxim Uvarov
> > > Sent: Tuesday, October 07, 2014 5:11 PM
> > > To: lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org>
> > > Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function
> > >
> > > I think that sort of patches should have RFC for better discussion. Due
> > > to that changes require everybody to do same changes (all platforms and
> > > all odp apps.). It will be nice if we can group such changes when
> > > merging because fixing up everything in different repos take some time...
> > >
> > > Maxim.
> > >
> > > On 10/07/2014 05:24 PM, Bill Fischofer wrote:
> > > > Yes, but continuing the bootstrap, the Google docs are input to the
> > > > doxygen versions which are integrated with the headers built from it.
> > > > Agree the doxygen version is intended to be definitive. The prototype
> > > > APIs we have pre-v1.0 are incomplete and in many cases inconsistent.
> > > > The arch/design process resolves that and allows us to iterate to the
> > > > final versions that will be v1.0. Otherwise we're just inventing APIs
> > > > on the fly with code without any explicit design review.
> > > >
> > > > Bill
> > > >
> > > > On Tue, Oct 7, 2014 at 7:59 AM, Savolainen, Petri (NSN - FI/Espoo)
> > > > <petri.savolainen@nsn.com<mailto:petri.savolainen@nsn.com> <mailto:petri.savolainen@nsn.com<mailto:petri.savolainen@nsn.com>>> wrote:
> > > >
> > > > API doc is generated with Doxygen from the headers. It's the
> > > > easiest way to ensure that API definitions (in C code) and
> > > > documentation are in sync.
> > > >
> > > > Arch docs support the doxygen documentation.
> > > >
> > > > -Petri
> > > >
> > > > *From:*ext Bill Fischofer [mailto:bill.fischofer@linaro.org<mailto:bill.fischofer@linaro.org>
> > > > <mailto:bill.fischofer@linaro.org<mailto:bill.fischofer@linaro.org>>]
> > > > *Sent:* Tuesday, October 07, 2014 3:54 PM
> > > > *To:* Savolainen, Petri (NSN - FI/Espoo)
> > > > *Cc:* lng-odp-forward
> > > > *Subject:* Re: [lng-odp] [PATCH] Rename buffer_from_packet function
> > > >
> > > > I'm not sure I understand this point. The design docs are the API
> > > > docs.
> > > >
> > > > On Tue, Oct 7, 2014 at 7:07 AM, Savolainen, Petri (NSN - FI/Espoo)
> > > > <petri.savolainen@nsn.com<mailto:petri.savolainen@nsn.com> <mailto:petri.savolainen@nsn.com<mailto:petri.savolainen@nsn.com>>> wrote:
> > > >
> > > > Hi.
> > > >
> > > > Test suite should be written from API documentation, since that's
> > > > the contract for users. Arch docs should just provide additional /
> > > > higher level information, so that API documentation is easier to
> > > > understand. Too much details in arch doc will duplicate
> > > > information (without too much added value). Does we need this
> > > > level of detail (function name for conversions) in arch doc - it's
> > > > enough to mention that buf <-> pkt conversion can be done using
> > > > the packet API.
> > > >
> > > > -Petri
> > > >
> > > > *From:*ext Bill Fischofer [mailto:bill.fischofer@linaro.org<mailto:bill.fischofer@linaro.org>
> > > > <mailto:bill.fischofer@linaro.org<mailto:bill.fischofer@linaro.org>>]
> > > > *Sent:* Tuesday, October 07, 2014 12:22 AM
> > > > *To:* Petri Savolainen
> > > > *Cc:* lng-odp-forward
> > > > *Subject:* Re: [lng-odp] [PATCH] Rename buffer_from_packet function
> > > >
> > > > Can we coordinate these changes with the ongoing Packet API design
> > > > work? Simply making code changes without that coordination at this
> > > > point is going to get confusing. Not saying there may not be good
> > > > reasons for these changes, but we want everything to sync up since
> > > > the ODP Test Suite is going to be written from the design docs,
> > > > not from the code.
> > > >
> > > > Thanks.
> > > >
> > > > Bill
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > lng-odp mailing list
> > > > lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org>
> > > > http://lists.linaro.org/mailman/listinfo/lng-odp
> > >
> > >
> > > _______________________________________________
> > > lng-odp mailing list
> > > lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org>
> > > http://lists.linaro.org/mailman/listinfo/lng-odp
> >
> > _______________________________________________
> > lng-odp mailing list
> > lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org>
> > http://lists.linaro.org/mailman/listinfo/lng-odp
>
>
> _______________________________________________
> lng-odp mailing list
> lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org>
> http://lists.linaro.org/mailman/listinfo/lng-odp
>
>
>
>
>
>
>
>
> _______________________________________________
> lng-odp mailing list
> lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org>
> http://lists.linaro.org/mailman/listinfo/lng-odp
>
>
>
>
>
> --
>
> Mike Holmes
>
> Linaro Sr Technical Manager
>
> LNG - ODP
>
>
> _______________________________________________
> lng-odp mailing list
> lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org>
> http://lists.linaro.org/mailman/listinfo/lng-odp
>
The ODP API buffer segmentation support was specifically designed with SoCs that have real hardware buffer managers in mind, since fixed HW-defined buffer segments and predefined pools are common in these chips. One of the main design goals for ODP (and IMO its main advantage over pure SW solutions like DPDK) is that the APIs do not presume an implementation model. Bill On Sun, Oct 12, 2014 at 12:22 AM, Gilad Ben Yossef <giladb@ezchip.com> wrote: > > > I don't understand if you are advocating not supporting buffer > segmentation at all or just limiting it to the packet buffers level, but if > it’s the former than you are shutting out an NPS-400 ODP 1.0 platform > implementation (our maximum packet buffer segments are 256 bytes long). > > > > I'd be very happy if you can at least leave the API definition for 1.0, > even if linux-generic would only implement single segments. > > > > > > Thanks, > > Gilad > > > > > > > > *Gilad Ben-Yossef* > > Software Architect > > EZchip Technologies Ltd. > > 37 Israel Pollak Ave, Kiryat Gat 82025 ,Israel > > Tel: +972-4-959-6666 ext. 576, Fax: +972-8-681-1483 > Mobile: +972-52-826-0388, US Mobile: +1-973-826-0388 > > Email: giladb@ezchip.com, Web: http://www.ezchip.com > > > > *"Ethernet always wins."* > > — Andy Bechtolsheim > > > > *From:* lng-odp-bounces@lists.linaro.org [mailto: > lng-odp-bounces@lists.linaro.org] *On Behalf Of *Savolainen, Petri (NSN - > FI/Espoo) > *Sent:* Thursday, October 09, 2014 10:15 AM > *To:* ext Bill Fischofer; Anders Roxell > *Cc:* lng-odp-forward > > *Subject:* Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > Hi, > > > > The main use case for segmentation is handling of scatter-gather lists of > large packets. Timeout notifications do not need segmentation support. > Those are the two buffer types defined so far (with raw buffers you are on > your own). So today only packet need that support. IF we create another > buffer type in future (e.g. for standard IPC) that’d need segmentation > support we may end up still adding it there on the type level (along with > other useful meta data), and not on buffer level. > > > > So, I’d leave buffer segmentation out from v1.0 since it’s not absolutely > needed. It’s easier to add it later, than remove it. > > > > -Petri > > > > > > > > *From:* ext Bill Fischofer [mailto:bill.fischofer@linaro.org > <bill.fischofer@linaro.org>] > *Sent:* Wednesday, October 08, 2014 10:52 PM > *To:* Anders Roxell > *Cc:* Savolainen, Petri (NSN - FI/Espoo); lng-odp-forward > *Subject:* Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > I'm not sure where the idea originated that segmentation is to be removed > from buffers. That seems to have been a misunderstanding on Ola's part > that was cleared up during today's call. The revised buffer.h patch (and > linux-generic implementation) is currently being worked on by Bala. > > > > In another thread I indicated I'm fine with this patch. > > > > On Wed, Oct 8, 2014 at 2:47 PM, Anders Roxell <anders.roxell@linaro.org> > wrote: > > > On 8 Oct 2014 14:55, "Savolainen, Petri (NSN - FI/Espoo)" < > petri.savolainen@nsn.com> wrote: > > > > If you consider the number of comments in that document… it will take a > while until it’s finished. And then if you look back into the buffer doc, > it’s not finished either since segmentation part should be removed from > there… and so on. > > Again I agree with Petri! > > > > > > > > > I’d rather fix only the necessary things in current APIs, documents and > test those, and call it v1.0. We’ll not have _code_ for v1.0 at the end of > the year, if we keep adding stuff into documents just for the sake of > completeness. > > If we want to do API changes to an existing header file I think we shall > do that as patches and _not_ the way we are trying to do now with a Google > docs somewhere else... > > Why I think this is a good patch is because we _don't_ have two APIs that > do the same thing and the patch makes the API clearer, which is something > you said earlier in the thread said Bill... =) > > Anders > > > > > > > > > > > > > -Petri > > > > > > > > > > > > > > > > From: ext Mike Holmes [mailto:mike.holmes@linaro.org] > > Sent: Wednesday, October 08, 2014 3:16 PM > > To: Bill Fischofer > > > > Cc: Savolainen, Petri (NSN - FI/Espoo); lng-odp-forward > > Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > > > > > In the platform discussion this morning the consensus was to not take > this patch at this time. > > > > > > > > The rationale was that although we are at liberty to change the API as > often as we want we don't want to introduce unnecessary churn when we can > help it, and in this case we think we can. > > > > > > > > In this case we know the docs don't match the code, and that the > documentation is not yet complete and its publication will be very soon. > > > > We also expect the final doc to change the API one more time. Given > that all platforms and applications will have to change twice in quick > succession it makes sense to sync the doc and the API before changing the > code. > > > > > > > > Mike > > > > > > > > On 8 October 2014 07:45, Bill Fischofer <bill.fischofer@linaro.org> > wrote: > > > > A conversion routine by definition bridges two types. One could just as > well argue that an odp_buffer routine is now returning a packet type. and > vice versa. I assume you originally came up with the from routines because > they mirror standard C type casting. If this were done via a type cast > you'd write: > > > > > > > > (odp_buffer_t)pkt > > > > > > > > and > > > > > > > > (odp_packet_t)buf; > > > > > > > > > > > > > > > > On Wed, Oct 8, 2014 at 6:40 AM, Savolainen, Petri (NSN - FI/Espoo) < > petri.savolainen@nsn.com> wrote: > > > > It’s not “to” vs “from. It’s that a odp_buffer_xxx function should not > use a odp_packet_t as parameter (packet inherits buffer, but not the other > way around). > > > > > > > > -Petri > > > > > > > > From: ext Bill Fischofer [mailto:bill.fischofer@linaro.org] > > Sent: Wednesday, October 08, 2014 2:34 PM > > To: Savolainen, Petri (NSN - FI/Espoo) > > Cc: Anders Roxell; lng-odp-forward > > > > > > Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > > > > > One isn't obviously superior to the other as this is clearly a matter of > personal preference. I have no problem offering choice in this if you want > to introduce the "to" routines as an alternative. But I don't see the need > to remove the "from" routines. If it's OK to make this change, what would > prevent someone else submitting a patch to turn these back around because > they felt the original "made more sense"? On what basis would we accept or > reject such a patch? Do we flip-flop on things like this without any > guidelines based on the last received patch? > > > > > > > > On Wed, Oct 8, 2014 at 6:17 AM, Savolainen, Petri (NSN - FI/Espoo) < > petri.savolainen@nsn.com> wrote: > > > > Hi, > > > > > > > > Less is more in API definition. The less there are > functions/options/overlap, the less there is confusion among users and the > less work to implement and maintain it. > > > > > > > > -Petri > > > > > > > > > > > > > > > > From: ext Bill Fischofer [mailto:bill.fischofer@linaro.org] > > Sent: Wednesday, October 08, 2014 2:09 PM > > To: Anders Roxell > > Cc: Savolainen, Petri (NSN - FI/Espoo); lng-odp-forward > > > > > > Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > > > > > It may be minor, but it is a change to the API. I agree it is > straightforward, but since these are trivial conversion routines, why not > add these rather than replacing their predecessors? So we could offer both > odp_buffer_from_packet() and odp_buffer_to_packet() at no real cost. > Post-v1.0 adding the new APIs would be a minor change since it is > backward-compatible, while replacing them would be a major change since it > would require application source code change. > > > > > > > > Bill > > > > > > > > On Wed, Oct 8, 2014 at 4:30 AM, Anders Roxell <anders.roxell@linaro.org> > wrote: > > > > > > On 8 Oct 2014 11:23, "Savolainen, Petri (NSN - FI/Espoo)" < > petri.savolainen@nsn.com> wrote: > > > > > > Hi, > > > > > > It's not a major architectural change. Just find and replace. If > there's nobody against it, could we just merge it and carry on. > > > > I agree! > > > > > > > > Implementations can choose to either follow the linux-generic closely > or group multiple changes (= update less frequently). It's up to each > implementation which strategy works the best. I think it's easier to follow > a set of many small changes than few big ones (which seem to rewrite an API > in one shot). > > > > I agree here as well! > > > > This was why we create different repositories... To speed up the > implementation of linux-generic, right? > > > > Cheers, > > Anders > > > > > > > > -Petri > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: lng-odp-bounces@lists.linaro.org [mailto:lng-odp- > > > > bounces@lists.linaro.org] On Behalf Of ext Maxim Uvarov > > > > Sent: Tuesday, October 07, 2014 5:11 PM > > > > To: lng-odp@lists.linaro.org > > > > Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > > > > > I think that sort of patches should have RFC for better discussion. > Due > > > > to that changes require everybody to do same changes (all platforms > and > > > > all odp apps.). It will be nice if we can group such changes when > > > > merging because fixing up everything in different repos take some > time... > > > > > > > > Maxim. > > > > > > > > On 10/07/2014 05:24 PM, Bill Fischofer wrote: > > > > > Yes, but continuing the bootstrap, the Google docs are input to the > > > > > doxygen versions which are integrated with the headers built from > it. > > > > > Agree the doxygen version is intended to be definitive. The > prototype > > > > > APIs we have pre-v1.0 are incomplete and in many cases > inconsistent. > > > > > The arch/design process resolves that and allows us to iterate to > the > > > > > final versions that will be v1.0. Otherwise we're just inventing > APIs > > > > > on the fly with code without any explicit design review. > > > > > > > > > > Bill > > > > > > > > > > On Tue, Oct 7, 2014 at 7:59 AM, Savolainen, Petri (NSN - FI/Espoo) > > > > > <petri.savolainen@nsn.com <mailto:petri.savolainen@nsn.com>> > wrote: > > > > > > > > > > API doc is generated with Doxygen from the headers. It's the > > > > > easiest way to ensure that API definitions (in C code) and > > > > > documentation are in sync. > > > > > > > > > > Arch docs support the doxygen documentation. > > > > > > > > > > -Petri > > > > > > > > > > *From:*ext Bill Fischofer [mailto:bill.fischofer@linaro.org > > > > > <mailto:bill.fischofer@linaro.org>] > > > > > *Sent:* Tuesday, October 07, 2014 3:54 PM > > > > > *To:* Savolainen, Petri (NSN - FI/Espoo) > > > > > *Cc:* lng-odp-forward > > > > > *Subject:* Re: [lng-odp] [PATCH] Rename buffer_from_packet > function > > > > > > > > > > I'm not sure I understand this point. The design docs are the > API > > > > > docs. > > > > > > > > > > On Tue, Oct 7, 2014 at 7:07 AM, Savolainen, Petri (NSN - > FI/Espoo) > > > > > <petri.savolainen@nsn.com <mailto:petri.savolainen@nsn.com>> > wrote: > > > > > > > > > > Hi. > > > > > > > > > > Test suite should be written from API documentation, since > that's > > > > > the contract for users. Arch docs should just provide > additional / > > > > > higher level information, so that API documentation is easier > to > > > > > understand. Too much details in arch doc will duplicate > > > > > information (without too much added value). Does we need this > > > > > level of detail (function name for conversions) in arch doc - > it's > > > > > enough to mention that buf <-> pkt conversion can be done using > > > > > the packet API. > > > > > > > > > > -Petri > > > > > > > > > > *From:*ext Bill Fischofer [mailto:bill.fischofer@linaro.org > > > > > <mailto:bill.fischofer@linaro.org>] > > > > > *Sent:* Tuesday, October 07, 2014 12:22 AM > > > > > *To:* Petri Savolainen > > > > > *Cc:* lng-odp-forward > > > > > *Subject:* Re: [lng-odp] [PATCH] Rename buffer_from_packet > function > > > > > > > > > > Can we coordinate these changes with the ongoing Packet API > design > > > > > work? Simply making code changes without that coordination at > this > > > > > point is going to get confusing. Not saying there may not be > good > > > > > reasons for these changes, but we want everything to sync up > since > > > > > the ODP Test Suite is going to be written from the design docs, > > > > > not from the code. > > > > > > > > > > Thanks. > > > > > > > > > > Bill > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > lng-odp mailing list > > > > > lng-odp@lists.linaro.org > > > > > http://lists.linaro.org/mailman/listinfo/lng-odp > > > > > > > > > > > > _______________________________________________ > > > > lng-odp mailing list > > > > lng-odp@lists.linaro.org > > > > http://lists.linaro.org/mailman/listinfo/lng-odp > > > > > > _______________________________________________ > > > lng-odp mailing list > > > lng-odp@lists.linaro.org > > > http://lists.linaro.org/mailman/listinfo/lng-odp > > > > > > _______________________________________________ > > lng-odp mailing list > > lng-odp@lists.linaro.org > > http://lists.linaro.org/mailman/listinfo/lng-odp > > > > > > > > > > > > > > > > > > _______________________________________________ > > lng-odp mailing list > > lng-odp@lists.linaro.org > > http://lists.linaro.org/mailman/listinfo/lng-odp > > > > > > > > > > > > -- > > > > Mike Holmes > > > > Linaro Sr Technical Manager > > > > LNG - ODP > > > > > > _______________________________________________ > > lng-odp mailing list > > lng-odp@lists.linaro.org > > http://lists.linaro.org/mailman/listinfo/lng-odp > > > > >
Hi, My comment is not about implementation, it’s about application requirements. If buffer segmentation is needed only for packets (packet type buffers), we should define segmentation on that level - not on both levels (buffer and packet) just for completeness. When the next buffer type emerges that need segmentation, we could again defined it on that level and not on both. May be application use case for that new buffer type would need a bit different buffer segmentation support (e.g. do not need copy, join, etc additional features…). -Petri From: ext Bill Fischofer [mailto:bill.fischofer@linaro.org] Sent: Sunday, October 12, 2014 2:06 PM To: Gilad Ben Yossef Cc: Savolainen, Petri (NSN - FI/Espoo); Anders Roxell; lng-odp-forward Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function The ODP API buffer segmentation support was specifically designed with SoCs that have real hardware buffer managers in mind, since fixed HW-defined buffer segments and predefined pools are common in these chips. One of the main design goals for ODP (and IMO its main advantage over pure SW solutions like DPDK) is that the APIs do not presume an implementation model. Bill On Sun, Oct 12, 2014 at 12:22 AM, Gilad Ben Yossef <giladb@ezchip.com<mailto:giladb@ezchip.com>> wrote: I don't understand if you are advocating not supporting buffer segmentation at all or just limiting it to the packet buffers level, but if it’s the former than you are shutting out an NPS-400 ODP 1.0 platform implementation (our maximum packet buffer segments are 256 bytes long). I'd be very happy if you can at least leave the API definition for 1.0, even if linux-generic would only implement single segments. Thanks, Gilad Gilad Ben-Yossef Software Architect EZchip Technologies Ltd. 37 Israel Pollak Ave, Kiryat Gat 82025 ,Israel Tel: +972-4-959-6666 ext. 576<tel:%2B972-4-959-6666%20ext.%20576>, Fax: +972-8-681-1483<tel:%2B972-8-681-1483> Mobile: +972-52-826-0388<tel:%2B972-52-826-0388>, US Mobile: +1-973-826-0388<tel:%2B1-973-826-0388> Email: giladb@ezchip.com<mailto:giladb@ezchip.com>, Web: http://www.ezchip.com<http://www.ezchip.com/> "Ethernet always wins." — Andy Bechtolsheim From: lng-odp-bounces@lists.linaro.org<mailto:lng-odp-bounces@lists.linaro.org> [mailto:lng-odp-bounces@lists.linaro.org<mailto:lng-odp-bounces@lists.linaro.org>] On Behalf Of Savolainen, Petri (NSN - FI/Espoo) Sent: Thursday, October 09, 2014 10:15 AM To: ext Bill Fischofer; Anders Roxell Cc: lng-odp-forward Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function Hi, The main use case for segmentation is handling of scatter-gather lists of large packets. Timeout notifications do not need segmentation support. Those are the two buffer types defined so far (with raw buffers you are on your own). So today only packet need that support. IF we create another buffer type in future (e.g. for standard IPC) that’d need segmentation support we may end up still adding it there on the type level (along with other useful meta data), and not on buffer level. So, I’d leave buffer segmentation out from v1.0 since it’s not absolutely needed. It’s easier to add it later, than remove it. -Petri From: ext Bill Fischofer [mailto:bill.fischofer@linaro.org] Sent: Wednesday, October 08, 2014 10:52 PM To: Anders Roxell Cc: Savolainen, Petri (NSN - FI/Espoo); lng-odp-forward Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function I'm not sure where the idea originated that segmentation is to be removed from buffers. That seems to have been a misunderstanding on Ola's part that was cleared up during today's call. The revised buffer.h patch (and linux-generic implementation) is currently being worked on by Bala. In another thread I indicated I'm fine with this patch. On Wed, Oct 8, 2014 at 2:47 PM, Anders Roxell <anders.roxell@linaro.org<mailto:anders.roxell@linaro.org>> wrote: On 8 Oct 2014 14:55, "Savolainen, Petri (NSN - FI/Espoo)" <petri.savolainen@nsn.com<mailto:petri.savolainen@nsn.com>> wrote: > > If you consider the number of comments in that document… it will take a while until it’s finished. And then if you look back into the buffer doc, it’s not finished either since segmentation part should be removed from there… and so on. Again I agree with Petri! > > > > I’d rather fix only the necessary things in current APIs, documents and test those, and call it v1.0. We’ll not have _code_ for v1.0 at the end of the year, if we keep adding stuff into documents just for the sake of completeness. If we want to do API changes to an existing header file I think we shall do that as patches and _not_ the way we are trying to do now with a Google docs somewhere else... Why I think this is a good patch is because we _don't_ have two APIs that do the same thing and the patch makes the API clearer, which is something you said earlier in the thread said Bill... =) Anders > > > > > > -Petri > > > > > > > > From: ext Mike Holmes [mailto:mike.holmes@linaro.org<mailto:mike.holmes@linaro.org>] > Sent: Wednesday, October 08, 2014 3:16 PM > To: Bill Fischofer > > Cc: Savolainen, Petri (NSN - FI/Espoo); lng-odp-forward > Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > In the platform discussion this morning the consensus was to not take this patch at this time. > > > > The rationale was that although we are at liberty to change the API as often as we want we don't want to introduce unnecessary churn when we can help it, and in this case we think we can. > > > > In this case we know the docs don't match the code, and that the documentation is not yet complete and its publication will be very soon. > > We also expect the final doc to change the API one more time. Given that all platforms and applications will have to change twice in quick succession it makes sense to sync the doc and the API before changing the code. > > > > Mike > > > > On 8 October 2014 07:45, Bill Fischofer <bill.fischofer@linaro.org<mailto:bill.fischofer@linaro.org>> wrote: > > A conversion routine by definition bridges two types. One could just as well argue that an odp_buffer routine is now returning a packet type. and vice versa. I assume you originally came up with the from routines because they mirror standard C type casting. If this were done via a type cast you'd write: > > > > (odp_buffer_t)pkt > > > > and > > > > (odp_packet_t)buf; > > > > > > > > On Wed, Oct 8, 2014 at 6:40 AM, Savolainen, Petri (NSN - FI/Espoo) <petri.savolainen@nsn.com<mailto:petri.savolainen@nsn.com>> wrote: > > It’s not “to” vs “from. It’s that a odp_buffer_xxx function should not use a odp_packet_t as parameter (packet inherits buffer, but not the other way around). > > > > -Petri > > > > From: ext Bill Fischofer [mailto:bill.fischofer@linaro.org<mailto:bill.fischofer@linaro.org>] > Sent: Wednesday, October 08, 2014 2:34 PM > To: Savolainen, Petri (NSN - FI/Espoo) > Cc: Anders Roxell; lng-odp-forward > > > Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > One isn't obviously superior to the other as this is clearly a matter of personal preference. I have no problem offering choice in this if you want to introduce the "to" routines as an alternative. But I don't see the need to remove the "from" routines. If it's OK to make this change, what would prevent someone else submitting a patch to turn these back around because they felt the original "made more sense"? On what basis would we accept or reject such a patch? Do we flip-flop on things like this without any guidelines based on the last received patch? > > > > On Wed, Oct 8, 2014 at 6:17 AM, Savolainen, Petri (NSN - FI/Espoo) <petri.savolainen@nsn.com<mailto:petri.savolainen@nsn.com>> wrote: > > Hi, > > > > Less is more in API definition. The less there are functions/options/overlap, the less there is confusion among users and the less work to implement and maintain it. > > > > -Petri > > > > > > > > From: ext Bill Fischofer [mailto:bill.fischofer@linaro.org<mailto:bill.fischofer@linaro.org>] > Sent: Wednesday, October 08, 2014 2:09 PM > To: Anders Roxell > Cc: Savolainen, Petri (NSN - FI/Espoo); lng-odp-forward > > > Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > It may be minor, but it is a change to the API. I agree it is straightforward, but since these are trivial conversion routines, why not add these rather than replacing their predecessors? So we could offer both odp_buffer_from_packet() and odp_buffer_to_packet() at no real cost. Post-v1.0 adding the new APIs would be a minor change since it is backward-compatible, while replacing them would be a major change since it would require application source code change. > > > > Bill > > > > On Wed, Oct 8, 2014 at 4:30 AM, Anders Roxell <anders.roxell@linaro.org<mailto:anders.roxell@linaro.org>> wrote: > > > On 8 Oct 2014 11:23, "Savolainen, Petri (NSN - FI/Espoo)" <petri.savolainen@nsn.com<mailto:petri.savolainen@nsn.com>> wrote: > > > > Hi, > > > > It's not a major architectural change. Just find and replace. If there's nobody against it, could we just merge it and carry on. > > I agree! > > > > > Implementations can choose to either follow the linux-generic closely or group multiple changes (= update less frequently). It's up to each implementation which strategy works the best. I think it's easier to follow a set of many small changes than few big ones (which seem to rewrite an API in one shot). > > I agree here as well! > > This was why we create different repositories... To speed up the implementation of linux-generic, right? > > Cheers, > Anders > > > > > -Petri > > > > > > > > > > > -----Original Message----- > > > From: lng-odp-bounces@lists.linaro.org<mailto:lng-odp-bounces@lists.linaro.org> [mailto:lng-odp-<mailto:lng-odp-> > > > bounces@lists.linaro.org<mailto:bounces@lists.linaro.org>] On Behalf Of ext Maxim Uvarov > > > Sent: Tuesday, October 07, 2014 5:11 PM > > > To: lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org> > > > Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > > > I think that sort of patches should have RFC for better discussion. Due > > > to that changes require everybody to do same changes (all platforms and > > > all odp apps.). It will be nice if we can group such changes when > > > merging because fixing up everything in different repos take some time... > > > > > > Maxim. > > > > > > On 10/07/2014 05:24 PM, Bill Fischofer wrote: > > > > Yes, but continuing the bootstrap, the Google docs are input to the > > > > doxygen versions which are integrated with the headers built from it. > > > > Agree the doxygen version is intended to be definitive. The prototype > > > > APIs we have pre-v1.0 are incomplete and in many cases inconsistent. > > > > The arch/design process resolves that and allows us to iterate to the > > > > final versions that will be v1.0. Otherwise we're just inventing APIs > > > > on the fly with code without any explicit design review. > > > > > > > > Bill > > > > > > > > On Tue, Oct 7, 2014 at 7:59 AM, Savolainen, Petri (NSN - FI/Espoo) > > > > <petri.savolainen@nsn.com<mailto:petri.savolainen@nsn.com> <mailto:petri.savolainen@nsn.com<mailto:petri.savolainen@nsn.com>>> wrote: > > > > > > > > API doc is generated with Doxygen from the headers. It's the > > > > easiest way to ensure that API definitions (in C code) and > > > > documentation are in sync. > > > > > > > > Arch docs support the doxygen documentation. > > > > > > > > -Petri > > > > > > > > *From:*ext Bill Fischofer [mailto:bill.fischofer@linaro.org<mailto:bill.fischofer@linaro.org> > > > > <mailto:bill.fischofer@linaro.org<mailto:bill.fischofer@linaro.org>>] > > > > *Sent:* Tuesday, October 07, 2014 3:54 PM > > > > *To:* Savolainen, Petri (NSN - FI/Espoo) > > > > *Cc:* lng-odp-forward > > > > *Subject:* Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > > > > > I'm not sure I understand this point. The design docs are the API > > > > docs. > > > > > > > > On Tue, Oct 7, 2014 at 7:07 AM, Savolainen, Petri (NSN - FI/Espoo) > > > > <petri.savolainen@nsn.com<mailto:petri.savolainen@nsn.com> <mailto:petri.savolainen@nsn.com<mailto:petri.savolainen@nsn.com>>> wrote: > > > > > > > > Hi. > > > > > > > > Test suite should be written from API documentation, since that's > > > > the contract for users. Arch docs should just provide additional / > > > > higher level information, so that API documentation is easier to > > > > understand. Too much details in arch doc will duplicate > > > > information (without too much added value). Does we need this > > > > level of detail (function name for conversions) in arch doc - it's > > > > enough to mention that buf <-> pkt conversion can be done using > > > > the packet API. > > > > > > > > -Petri > > > > > > > > *From:*ext Bill Fischofer [mailto:bill.fischofer@linaro.org<mailto:bill.fischofer@linaro.org> > > > > <mailto:bill.fischofer@linaro.org<mailto:bill.fischofer@linaro.org>>] > > > > *Sent:* Tuesday, October 07, 2014 12:22 AM > > > > *To:* Petri Savolainen > > > > *Cc:* lng-odp-forward > > > > *Subject:* Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > > > > > Can we coordinate these changes with the ongoing Packet API design > > > > work? Simply making code changes without that coordination at this > > > > point is going to get confusing. Not saying there may not be good > > > > reasons for these changes, but we want everything to sync up since > > > > the ODP Test Suite is going to be written from the design docs, > > > > not from the code. > > > > > > > > Thanks. > > > > > > > > Bill > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > lng-odp mailing list > > > > lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org> > > > > http://lists.linaro.org/mailman/listinfo/lng-odp > > > > > > > > > _______________________________________________ > > > lng-odp mailing list > > > lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org> > > > http://lists.linaro.org/mailman/listinfo/lng-odp > > > > _______________________________________________ > > lng-odp mailing list > > lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org> > > http://lists.linaro.org/mailman/listinfo/lng-odp > > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org> > http://lists.linaro.org/mailman/listinfo/lng-odp > > > > > > > > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org> > http://lists.linaro.org/mailman/listinfo/lng-odp > > > > > > -- > > Mike Holmes > > Linaro Sr Technical Manager > > LNG - ODP > > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org> > http://lists.linaro.org/mailman/listinfo/lng-odp >
Gilad, Are your NPS *non-packet* buffers also limited to 256 bytes? That could pose a problem, I can imagine applications which want to use larger monolithic buffers. Maybe such large buffers would not have to be proper ODP buffers that can be using with queues and scheduling etc but currently ODP lacks other forms of application-level memory management (you could always roll your own using shared memory regions). -- Ola On 12 October 2014 07:22, Gilad Ben Yossef <giladb@ezchip.com> wrote: > > > I don't understand if you are advocating not supporting buffer > segmentation at all or just limiting it to the packet buffers level, but if > it’s the former than you are shutting out an NPS-400 ODP 1.0 platform > implementation (our maximum packet buffer segments are 256 bytes long). > > > > I'd be very happy if you can at least leave the API definition for 1.0, > even if linux-generic would only implement single segments. > > > > > > Thanks, > > Gilad > > > > > > > > *Gilad Ben-Yossef* > > Software Architect > > EZchip Technologies Ltd. > > 37 Israel Pollak Ave, Kiryat Gat 82025 ,Israel > > Tel: +972-4-959-6666 ext. 576, Fax: +972-8-681-1483 > Mobile: +972-52-826-0388, US Mobile: +1-973-826-0388 > > Email: giladb@ezchip.com, Web: http://www.ezchip.com > > > > *"Ethernet always wins."* > > — Andy Bechtolsheim > > > > *From:* lng-odp-bounces@lists.linaro.org [mailto: > lng-odp-bounces@lists.linaro.org] *On Behalf Of *Savolainen, Petri (NSN - > FI/Espoo) > *Sent:* Thursday, October 09, 2014 10:15 AM > *To:* ext Bill Fischofer; Anders Roxell > *Cc:* lng-odp-forward > *Subject:* Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > Hi, > > > > The main use case for segmentation is handling of scatter-gather lists of > large packets. Timeout notifications do not need segmentation support. > Those are the two buffer types defined so far (with raw buffers you are on > your own). So today only packet need that support. IF we create another > buffer type in future (e.g. for standard IPC) that’d need segmentation > support we may end up still adding it there on the type level (along with > other useful meta data), and not on buffer level. > > > > So, I’d leave buffer segmentation out from v1.0 since it’s not absolutely > needed. It’s easier to add it later, than remove it. > > > > -Petri > > > > > > > > *From:* ext Bill Fischofer [mailto:bill.fischofer@linaro.org > <bill.fischofer@linaro.org>] > *Sent:* Wednesday, October 08, 2014 10:52 PM > *To:* Anders Roxell > *Cc:* Savolainen, Petri (NSN - FI/Espoo); lng-odp-forward > *Subject:* Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > I'm not sure where the idea originated that segmentation is to be removed > from buffers. That seems to have been a misunderstanding on Ola's part > that was cleared up during today's call. The revised buffer.h patch (and > linux-generic implementation) is currently being worked on by Bala. > > > > In another thread I indicated I'm fine with this patch. > > > > On Wed, Oct 8, 2014 at 2:47 PM, Anders Roxell <anders.roxell@linaro.org> > wrote: > > > On 8 Oct 2014 14:55, "Savolainen, Petri (NSN - FI/Espoo)" < > petri.savolainen@nsn.com> wrote: > > > > If you consider the number of comments in that document… it will take a > while until it’s finished. And then if you look back into the buffer doc, > it’s not finished either since segmentation part should be removed from > there… and so on. > > Again I agree with Petri! > > > > > > > > > I’d rather fix only the necessary things in current APIs, documents and > test those, and call it v1.0. We’ll not have _code_ for v1.0 at the end of > the year, if we keep adding stuff into documents just for the sake of > completeness. > > If we want to do API changes to an existing header file I think we shall > do that as patches and _not_ the way we are trying to do now with a Google > docs somewhere else... > > Why I think this is a good patch is because we _don't_ have two APIs that > do the same thing and the patch makes the API clearer, which is something > you said earlier in the thread said Bill... =) > > Anders > > > > > > > > > > > > > -Petri > > > > > > > > > > > > > > > > From: ext Mike Holmes [mailto:mike.holmes@linaro.org] > > Sent: Wednesday, October 08, 2014 3:16 PM > > To: Bill Fischofer > > > > Cc: Savolainen, Petri (NSN - FI/Espoo); lng-odp-forward > > Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > > > > > In the platform discussion this morning the consensus was to not take > this patch at this time. > > > > > > > > The rationale was that although we are at liberty to change the API as > often as we want we don't want to introduce unnecessary churn when we can > help it, and in this case we think we can. > > > > > > > > In this case we know the docs don't match the code, and that the > documentation is not yet complete and its publication will be very soon. > > > > We also expect the final doc to change the API one more time. Given > that all platforms and applications will have to change twice in quick > succession it makes sense to sync the doc and the API before changing the > code. > > > > > > > > Mike > > > > > > > > On 8 October 2014 07:45, Bill Fischofer <bill.fischofer@linaro.org> > wrote: > > > > A conversion routine by definition bridges two types. One could just as > well argue that an odp_buffer routine is now returning a packet type. and > vice versa. I assume you originally came up with the from routines because > they mirror standard C type casting. If this were done via a type cast > you'd write: > > > > > > > > (odp_buffer_t)pkt > > > > > > > > and > > > > > > > > (odp_packet_t)buf; > > > > > > > > > > > > > > > > On Wed, Oct 8, 2014 at 6:40 AM, Savolainen, Petri (NSN - FI/Espoo) < > petri.savolainen@nsn.com> wrote: > > > > It’s not “to” vs “from. It’s that a odp_buffer_xxx function should not > use a odp_packet_t as parameter (packet inherits buffer, but not the other > way around). > > > > > > > > -Petri > > > > > > > > From: ext Bill Fischofer [mailto:bill.fischofer@linaro.org] > > Sent: Wednesday, October 08, 2014 2:34 PM > > To: Savolainen, Petri (NSN - FI/Espoo) > > Cc: Anders Roxell; lng-odp-forward > > > > > > Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > > > > > One isn't obviously superior to the other as this is clearly a matter of > personal preference. I have no problem offering choice in this if you want > to introduce the "to" routines as an alternative. But I don't see the need > to remove the "from" routines. If it's OK to make this change, what would > prevent someone else submitting a patch to turn these back around because > they felt the original "made more sense"? On what basis would we accept or > reject such a patch? Do we flip-flop on things like this without any > guidelines based on the last received patch? > > > > > > > > On Wed, Oct 8, 2014 at 6:17 AM, Savolainen, Petri (NSN - FI/Espoo) < > petri.savolainen@nsn.com> wrote: > > > > Hi, > > > > > > > > Less is more in API definition. The less there are > functions/options/overlap, the less there is confusion among users and the > less work to implement and maintain it. > > > > > > > > -Petri > > > > > > > > > > > > > > > > From: ext Bill Fischofer [mailto:bill.fischofer@linaro.org] > > Sent: Wednesday, October 08, 2014 2:09 PM > > To: Anders Roxell > > Cc: Savolainen, Petri (NSN - FI/Espoo); lng-odp-forward > > > > > > Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > > > > > It may be minor, but it is a change to the API. I agree it is > straightforward, but since these are trivial conversion routines, why not > add these rather than replacing their predecessors? So we could offer both > odp_buffer_from_packet() and odp_buffer_to_packet() at no real cost. > Post-v1.0 adding the new APIs would be a minor change since it is > backward-compatible, while replacing them would be a major change since it > would require application source code change. > > > > > > > > Bill > > > > > > > > On Wed, Oct 8, 2014 at 4:30 AM, Anders Roxell <anders.roxell@linaro.org> > wrote: > > > > > > On 8 Oct 2014 11:23, "Savolainen, Petri (NSN - FI/Espoo)" < > petri.savolainen@nsn.com> wrote: > > > > > > Hi, > > > > > > It's not a major architectural change. Just find and replace. If > there's nobody against it, could we just merge it and carry on. > > > > I agree! > > > > > > > > Implementations can choose to either follow the linux-generic closely > or group multiple changes (= update less frequently). It's up to each > implementation which strategy works the best. I think it's easier to follow > a set of many small changes than few big ones (which seem to rewrite an API > in one shot). > > > > I agree here as well! > > > > This was why we create different repositories... To speed up the > implementation of linux-generic, right? > > > > Cheers, > > Anders > > > > > > > > -Petri > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: lng-odp-bounces@lists.linaro.org [mailto:lng-odp- > > > > bounces@lists.linaro.org] On Behalf Of ext Maxim Uvarov > > > > Sent: Tuesday, October 07, 2014 5:11 PM > > > > To: lng-odp@lists.linaro.org > > > > Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function > > > > > > > > I think that sort of patches should have RFC for better discussion. > Due > > > > to that changes require everybody to do same changes (all platforms > and > > > > all odp apps.). It will be nice if we can group such changes when > > > > merging because fixing up everything in different repos take some > time... > > > > > > > > Maxim. > > > > > > > > On 10/07/2014 05:24 PM, Bill Fischofer wrote: > > > > > Yes, but continuing the bootstrap, the Google docs are input to the > > > > > doxygen versions which are integrated with the headers built from > it. > > > > > Agree the doxygen version is intended to be definitive. The > prototype > > > > > APIs we have pre-v1.0 are incomplete and in many cases > inconsistent. > > > > > The arch/design process resolves that and allows us to iterate to > the > > > > > final versions that will be v1.0. Otherwise we're just inventing > APIs > > > > > on the fly with code without any explicit design review. > > > > > > > > > > Bill > > > > > > > > > > On Tue, Oct 7, 2014 at 7:59 AM, Savolainen, Petri (NSN - FI/Espoo) > > > > > <petri.savolainen@nsn.com <mailto:petri.savolainen@nsn.com>> > wrote: > > > > > > > > > > API doc is generated with Doxygen from the headers. It's the > > > > > easiest way to ensure that API definitions (in C code) and > > > > > documentation are in sync. > > > > > > > > > > Arch docs support the doxygen documentation. > > > > > > > > > > -Petri > > > > > > > > > > *From:*ext Bill Fischofer [mailto:bill.fischofer@linaro.org > > > > > <mailto:bill.fischofer@linaro.org>] > > > > > *Sent:* Tuesday, October 07, 2014 3:54 PM > > > > > *To:* Savolainen, Petri (NSN - FI/Espoo) > > > > > *Cc:* lng-odp-forward > > > > > *Subject:* Re: [lng-odp] [PATCH] Rename buffer_from_packet > function > > > > > > > > > > I'm not sure I understand this point. The design docs are the > API > > > > > docs. > > > > > > > > > > On Tue, Oct 7, 2014 at 7:07 AM, Savolainen, Petri (NSN - > FI/Espoo) > > > > > <petri.savolainen@nsn.com <mailto:petri.savolainen@nsn.com>> > wrote: > > > > > > > > > > Hi. > > > > > > > > > > Test suite should be written from API documentation, since > that's > > > > > the contract for users. Arch docs should just provide > additional / > > > > > higher level information, so that API documentation is easier > to > > > > > understand. Too much details in arch doc will duplicate > > > > > information (without too much added value). Does we need this > > > > > level of detail (function name for conversions) in arch doc - > it's > > > > > enough to mention that buf <-> pkt conversion can be done using > > > > > the packet API. > > > > > > > > > > -Petri > > > > > > > > > > *From:*ext Bill Fischofer [mailto:bill.fischofer@linaro.org > > > > > <mailto:bill.fischofer@linaro.org>] > > > > > *Sent:* Tuesday, October 07, 2014 12:22 AM > > > > > *To:* Petri Savolainen > > > > > *Cc:* lng-odp-forward > > > > > *Subject:* Re: [lng-odp] [PATCH] Rename buffer_from_packet > function > > > > > > > > > > Can we coordinate these changes with the ongoing Packet API > design > > > > > work? Simply making code changes without that coordination at > this > > > > > point is going to get confusing. Not saying there may not be > good > > > > > reasons for these changes, but we want everything to sync up > since > > > > > the ODP Test Suite is going to be written from the design docs, > > > > > not from the code. > > > > > > > > > > Thanks. > > > > > > > > > > Bill > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > lng-odp mailing list > > > > > lng-odp@lists.linaro.org > > > > > http://lists.linaro.org/mailman/listinfo/lng-odp > > > > > > > > > > > > _______________________________________________ > > > > lng-odp mailing list > > > > lng-odp@lists.linaro.org > > > > http://lists.linaro.org/mailman/listinfo/lng-odp > > > > > > _______________________________________________ > > > lng-odp mailing list > > > lng-odp@lists.linaro.org > > > http://lists.linaro.org/mailman/listinfo/lng-odp > > > > > > _______________________________________________ > > lng-odp mailing list > > lng-odp@lists.linaro.org > > http://lists.linaro.org/mailman/listinfo/lng-odp > > > > > > > > > > > > > > > > > > _______________________________________________ > > lng-odp mailing list > > lng-odp@lists.linaro.org > > http://lists.linaro.org/mailman/listinfo/lng-odp > > > > > > > > > > > > -- > > > > Mike Holmes > > > > Linaro Sr Technical Manager > > > > LNG - ODP > > > > > > _______________________________________________ > > lng-odp mailing list > > lng-odp@lists.linaro.org > > http://lists.linaro.org/mailman/listinfo/lng-odp > > > > > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/lng-odp > >
Hi Ola,
No, only packet buffer segments (anything that goes from/to a pkt_io) are hard limited to 256 bytes but there are considerable performance benefits to segmented buffers on my platform.
If some application wishes to mark as specific buffer pool as not segmented that's fine, but if the application does not care (most apps for most pools) I'd like the freedom to use that.
Thanks,
Gilad
Gilad Ben-Yossef
Software Architect
EZchip Technologies Ltd.
37 Israel Pollak Ave, Kiryat Gat 82025 ,Israel
Tel: +972-4-959-6666 ext. 576, Fax: +972-8-681-1483
Mobile: +972-52-826-0388, US Mobile: +1-973-826-0388
Email: giladb@ezchip.com<mailto:giladb@ezchip.com>, Web: http://www.ezchip.com<http://www.ezchip.com/>
"Ethernet always wins."
— Andy Bechtolsheim
From: Ola Liljedahl [mailto:ola.liljedahl@linaro.org]
Sent: Monday, October 13, 2014 12:13 PM
To: Gilad Ben Yossef
Cc: Savolainen, Petri (NSN - FI/Espoo); ext Bill Fischofer; Anders Roxell; lng-odp-forward
Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function
Gilad,
Are your NPS *non-packet* buffers also limited to 256 bytes? That could pose a problem, I can imagine applications which want to use larger monolithic buffers. Maybe such large buffers would not have to be proper ODP buffers that can be using with queues and scheduling etc but currently ODP lacks other forms of application-level memory management (you could always roll your own using shared memory regions).
-- Ola
On 12 October 2014 07:22, Gilad Ben Yossef <giladb@ezchip.com<mailto:giladb@ezchip.com>> wrote:
I don't understand if you are advocating not supporting buffer segmentation at all or just limiting it to the packet buffers level, but if it’s the former than you are shutting out an NPS-400 ODP 1.0 platform implementation (our maximum packet buffer segments are 256 bytes long).
I'd be very happy if you can at least leave the API definition for 1.0, even if linux-generic would only implement single segments.
Thanks,
Gilad
Gilad Ben-Yossef
Software Architect
EZchip Technologies Ltd.
37 Israel Pollak Ave, Kiryat Gat 82025 ,Israel
Tel: +972-4-959-6666 ext. 576<tel:%2B972-4-959-6666%20ext.%20576>, Fax: +972-8-681-1483<tel:%2B972-8-681-1483>
Mobile: +972-52-826-0388<tel:%2B972-52-826-0388>, US Mobile: +1-973-826-0388<tel:%2B1-973-826-0388>
Email: giladb@ezchip.com<mailto:giladb@ezchip.com>, Web: http://www.ezchip.com<http://www.ezchip.com/>
"Ethernet always wins."
— Andy Bechtolsheim
From: lng-odp-bounces@lists.linaro.org<mailto:lng-odp-bounces@lists.linaro.org> [mailto:lng-odp-bounces@lists.linaro.org<mailto:lng-odp-bounces@lists.linaro.org>] On Behalf Of Savolainen, Petri (NSN - FI/Espoo)
Sent: Thursday, October 09, 2014 10:15 AM
To: ext Bill Fischofer; Anders Roxell
Cc: lng-odp-forward
Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function
Hi,
The main use case for segmentation is handling of scatter-gather lists of large packets. Timeout notifications do not need segmentation support. Those are the two buffer types defined so far (with raw buffers you are on your own). So today only packet need that support. IF we create another buffer type in future (e.g. for standard IPC) that’d need segmentation support we may end up still adding it there on the type level (along with other useful meta data), and not on buffer level.
So, I’d leave buffer segmentation out from v1.0 since it’s not absolutely needed. It’s easier to add it later, than remove it.
-Petri
From: ext Bill Fischofer [mailto:bill.fischofer@linaro.org]
Sent: Wednesday, October 08, 2014 10:52 PM
To: Anders Roxell
Cc: Savolainen, Petri (NSN - FI/Espoo); lng-odp-forward
Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function
I'm not sure where the idea originated that segmentation is to be removed from buffers. That seems to have been a misunderstanding on Ola's part that was cleared up during today's call. The revised buffer.h patch (and linux-generic implementation) is currently being worked on by Bala.
In another thread I indicated I'm fine with this patch.
On Wed, Oct 8, 2014 at 2:47 PM, Anders Roxell <anders.roxell@linaro.org<mailto:anders.roxell@linaro.org>> wrote:
On 8 Oct 2014 14:55, "Savolainen, Petri (NSN - FI/Espoo)" <petri.savolainen@nsn.com<mailto:petri.savolainen@nsn.com>> wrote:
>
> If you consider the number of comments in that document… it will take a while until it’s finished. And then if you look back into the buffer doc, it’s not finished either since segmentation part should be removed from there… and so on.
Again I agree with Petri!
>
>
>
> I’d rather fix only the necessary things in current APIs, documents and test those, and call it v1.0. We’ll not have _code_ for v1.0 at the end of the year, if we keep adding stuff into documents just for the sake of completeness.
If we want to do API changes to an existing header file I think we shall do that as patches and _not_ the way we are trying to do now with a Google docs somewhere else...
Why I think this is a good patch is because we _don't_ have two APIs that do the same thing and the patch makes the API clearer, which is something you said earlier in the thread said Bill... =)
Anders
>
>
>
>
>
> -Petri
>
>
>
>
>
>
>
> From: ext Mike Holmes [mailto:mike.holmes@linaro.org<mailto:mike.holmes@linaro.org>]
> Sent: Wednesday, October 08, 2014 3:16 PM
> To: Bill Fischofer
>
> Cc: Savolainen, Petri (NSN - FI/Espoo); lng-odp-forward
> Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function
>
>
>
> In the platform discussion this morning the consensus was to not take this patch at this time.
>
>
>
> The rationale was that although we are at liberty to change the API as often as we want we don't want to introduce unnecessary churn when we can help it, and in this case we think we can.
>
>
>
> In this case we know the docs don't match the code, and that the documentation is not yet complete and its publication will be very soon.
>
> We also expect the final doc to change the API one more time. Given that all platforms and applications will have to change twice in quick succession it makes sense to sync the doc and the API before changing the code.
>
>
>
> Mike
>
>
>
> On 8 October 2014 07:45, Bill Fischofer <bill.fischofer@linaro.org<mailto:bill.fischofer@linaro.org>> wrote:
>
> A conversion routine by definition bridges two types. One could just as well argue that an odp_buffer routine is now returning a packet type. and vice versa. I assume you originally came up with the from routines because they mirror standard C type casting. If this were done via a type cast you'd write:
>
>
>
> (odp_buffer_t)pkt
>
>
>
> and
>
>
>
> (odp_packet_t)buf;
>
>
>
>
>
>
>
> On Wed, Oct 8, 2014 at 6:40 AM, Savolainen, Petri (NSN - FI/Espoo) <petri.savolainen@nsn.com<mailto:petri.savolainen@nsn.com>> wrote:
>
> It’s not “to” vs “from. It’s that a odp_buffer_xxx function should not use a odp_packet_t as parameter (packet inherits buffer, but not the other way around).
>
>
>
> -Petri
>
>
>
> From: ext Bill Fischofer [mailto:bill.fischofer@linaro.org<mailto:bill.fischofer@linaro.org>]
> Sent: Wednesday, October 08, 2014 2:34 PM
> To: Savolainen, Petri (NSN - FI/Espoo)
> Cc: Anders Roxell; lng-odp-forward
>
>
> Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function
>
>
>
> One isn't obviously superior to the other as this is clearly a matter of personal preference. I have no problem offering choice in this if you want to introduce the "to" routines as an alternative. But I don't see the need to remove the "from" routines. If it's OK to make this change, what would prevent someone else submitting a patch to turn these back around because they felt the original "made more sense"? On what basis would we accept or reject such a patch? Do we flip-flop on things like this without any guidelines based on the last received patch?
>
>
>
> On Wed, Oct 8, 2014 at 6:17 AM, Savolainen, Petri (NSN - FI/Espoo) <petri.savolainen@nsn.com<mailto:petri.savolainen@nsn.com>> wrote:
>
> Hi,
>
>
>
> Less is more in API definition. The less there are functions/options/overlap, the less there is confusion among users and the less work to implement and maintain it.
>
>
>
> -Petri
>
>
>
>
>
>
>
> From: ext Bill Fischofer [mailto:bill.fischofer@linaro.org<mailto:bill.fischofer@linaro.org>]
> Sent: Wednesday, October 08, 2014 2:09 PM
> To: Anders Roxell
> Cc: Savolainen, Petri (NSN - FI/Espoo); lng-odp-forward
>
>
> Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function
>
>
>
> It may be minor, but it is a change to the API. I agree it is straightforward, but since these are trivial conversion routines, why not add these rather than replacing their predecessors? So we could offer both odp_buffer_from_packet() and odp_buffer_to_packet() at no real cost. Post-v1.0 adding the new APIs would be a minor change since it is backward-compatible, while replacing them would be a major change since it would require application source code change.
>
>
>
> Bill
>
>
>
> On Wed, Oct 8, 2014 at 4:30 AM, Anders Roxell <anders.roxell@linaro.org<mailto:anders.roxell@linaro.org>> wrote:
>
>
> On 8 Oct 2014 11:23, "Savolainen, Petri (NSN - FI/Espoo)" <petri.savolainen@nsn.com<mailto:petri.savolainen@nsn.com>> wrote:
> >
> > Hi,
> >
> > It's not a major architectural change. Just find and replace. If there's nobody against it, could we just merge it and carry on.
>
> I agree!
>
> >
> > Implementations can choose to either follow the linux-generic closely or group multiple changes (= update less frequently). It's up to each implementation which strategy works the best. I think it's easier to follow a set of many small changes than few big ones (which seem to rewrite an API in one shot).
>
> I agree here as well!
>
> This was why we create different repositories... To speed up the implementation of linux-generic, right?
>
> Cheers,
> Anders
>
> >
> > -Petri
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: lng-odp-bounces@lists.linaro.org<mailto:lng-odp-bounces@lists.linaro.org> [mailto:lng-odp-<mailto:lng-odp->
> > > bounces@lists.linaro.org<mailto:bounces@lists.linaro.org>] On Behalf Of ext Maxim Uvarov
> > > Sent: Tuesday, October 07, 2014 5:11 PM
> > > To: lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org>
> > > Subject: Re: [lng-odp] [PATCH] Rename buffer_from_packet function
> > >
> > > I think that sort of patches should have RFC for better discussion. Due
> > > to that changes require everybody to do same changes (all platforms and
> > > all odp apps.). It will be nice if we can group such changes when
> > > merging because fixing up everything in different repos take some time...
> > >
> > > Maxim.
> > >
> > > On 10/07/2014 05:24 PM, Bill Fischofer wrote:
> > > > Yes, but continuing the bootstrap, the Google docs are input to the
> > > > doxygen versions which are integrated with the headers built from it.
> > > > Agree the doxygen version is intended to be definitive. The prototype
> > > > APIs we have pre-v1.0 are incomplete and in many cases inconsistent.
> > > > The arch/design process resolves that and allows us to iterate to the
> > > > final versions that will be v1.0. Otherwise we're just inventing APIs
> > > > on the fly with code without any explicit design review.
> > > >
> > > > Bill
> > > >
> > > > On Tue, Oct 7, 2014 at 7:59 AM, Savolainen, Petri (NSN - FI/Espoo)
> > > > <petri.savolainen@nsn.com<mailto:petri.savolainen@nsn.com> <mailto:petri.savolainen@nsn.com<mailto:petri.savolainen@nsn.com>>> wrote:
> > > >
> > > > API doc is generated with Doxygen from the headers. It's the
> > > > easiest way to ensure that API definitions (in C code) and
> > > > documentation are in sync.
> > > >
> > > > Arch docs support the doxygen documentation.
> > > >
> > > > -Petri
> > > >
> > > > *From:*ext Bill Fischofer [mailto:bill.fischofer@linaro.org<mailto:bill.fischofer@linaro.org>
> > > > <mailto:bill.fischofer@linaro.org<mailto:bill.fischofer@linaro.org>>]
> > > > *Sent:* Tuesday, October 07, 2014 3:54 PM
> > > > *To:* Savolainen, Petri (NSN - FI/Espoo)
> > > > *Cc:* lng-odp-forward
> > > > *Subject:* Re: [lng-odp] [PATCH] Rename buffer_from_packet function
> > > >
> > > > I'm not sure I understand this point. The design docs are the API
> > > > docs.
> > > >
> > > > On Tue, Oct 7, 2014 at 7:07 AM, Savolainen, Petri (NSN - FI/Espoo)
> > > > <petri.savolainen@nsn.com<mailto:petri.savolainen@nsn.com> <mailto:petri.savolainen@nsn.com<mailto:petri.savolainen@nsn.com>>> wrote:
> > > >
> > > > Hi.
> > > >
> > > > Test suite should be written from API documentation, since that's
> > > > the contract for users. Arch docs should just provide additional /
> > > > higher level information, so that API documentation is easier to
> > > > understand. Too much details in arch doc will duplicate
> > > > information (without too much added value). Does we need this
> > > > level of detail (function name for conversions) in arch doc - it's
> > > > enough to mention that buf <-> pkt conversion can be done using
> > > > the packet API.
> > > >
> > > > -Petri
> > > >
> > > > *From:*ext Bill Fischofer [mailto:bill.fischofer@linaro.org<mailto:bill.fischofer@linaro.org>
> > > > <mailto:bill.fischofer@linaro.org<mailto:bill.fischofer@linaro.org>>]
> > > > *Sent:* Tuesday, October 07, 2014 12:22 AM
> > > > *To:* Petri Savolainen
> > > > *Cc:* lng-odp-forward
> > > > *Subject:* Re: [lng-odp] [PATCH] Rename buffer_from_packet function
> > > >
> > > > Can we coordinate these changes with the ongoing Packet API design
> > > > work? Simply making code changes without that coordination at this
> > > > point is going to get confusing. Not saying there may not be good
> > > > reasons for these changes, but we want everything to sync up since
> > > > the ODP Test Suite is going to be written from the design docs,
> > > > not from the code.
> > > >
> > > > Thanks.
> > > >
> > > > Bill
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > lng-odp mailing list
> > > > lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org>
> > > > http://lists.linaro.org/mailman/listinfo/lng-odp
> > >
> > >
> > > _______________________________________________
> > > lng-odp mailing list
> > > lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org>
> > > http://lists.linaro.org/mailman/listinfo/lng-odp
> >
> > _______________________________________________
> > lng-odp mailing list
> > lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org>
> > http://lists.linaro.org/mailman/listinfo/lng-odp
>
>
> _______________________________________________
> lng-odp mailing list
> lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org>
> http://lists.linaro.org/mailman/listinfo/lng-odp
>
>
>
>
>
>
>
>
> _______________________________________________
> lng-odp mailing list
> lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org>
> http://lists.linaro.org/mailman/listinfo/lng-odp
>
>
>
>
>
> --
>
> Mike Holmes
>
> Linaro Sr Technical Manager
>
> LNG - ODP
>
>
> _______________________________________________
> lng-odp mailing list
> lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org>
> http://lists.linaro.org/mailman/listinfo/lng-odp
>
_______________________________________________
lng-odp mailing list
lng-odp@lists.linaro.org<mailto:lng-odp@lists.linaro.org>
http://lists.linaro.org/mailman/listinfo/lng-odp
Ping. It's time to merge! This is now in the spec. > -----Original Message----- > From: ext Petri Savolainen [mailto:petri.savolainen@linaro.org] > Sent: Monday, October 06, 2014 5:26 PM > To: lng-odp@lists.linaro.org > Cc: Petri Savolainen > Subject: [PATCH] Rename buffer_from_packet function > > Rename odp_buffer_from_packet() to odp_packet_to_buffer(). > It's a function of packet API vs buffer API. > > Signed-off-by: Petri Savolainen <petri.savolainen@linaro.org> > --- > example/generator/odp_generator.c | 2 +- > example/ipsec/odp_ipsec.c | 10 +++++----- > helper/include/odph_packet.h | 6 +++--- > platform/linux-generic/include/api/odp_packet.h | 6 +++--- > platform/linux-generic/odp_crypto.c | 4 ++-- > platform/linux-generic/odp_packet.c | 8 ++++---- > platform/linux-generic/odp_packet_io.c | 6 +++--- > 7 files changed, 21 insertions(+), 21 deletions(-) > > diff --git a/example/generator/odp_generator.c > b/example/generator/odp_generator.c > index 6055324..5538d0c 100644 > --- a/example/generator/odp_generator.c > +++ b/example/generator/odp_generator.c > @@ -397,7 +397,7 @@ static void print_pkts(int thr, odp_packet_t > pkt_tbl[], unsigned len) > > odp_atomic_inc_u64(&counters.ip); > rlen += sprintf(msg, "receive Packet proto:IP "); > - buf = odp_buffer_addr(odp_buffer_from_packet(pkt)); > + buf = odp_buffer_addr(odp_packet_to_buffer(pkt)); > ip = (odph_ipv4hdr_t *)(buf + odp_packet_l3_offset(pkt)); > rlen += sprintf(msg + rlen, "id %d ", > odp_be_to_cpu_16(ip->id)); > diff --git a/example/ipsec/odp_ipsec.c b/example/ipsec/odp_ipsec.c > index ec6c87a..56539ba 100644 > --- a/example/ipsec/odp_ipsec.c > +++ b/example/ipsec/odp_ipsec.c > @@ -738,7 +738,7 @@ pkt_disposition_e do_ipsec_in_classify(odp_packet_t > pkt, > *skip = FALSE; > if (odp_crypto_operation(¶ms, > &posted, > - odp_buffer_from_packet(pkt))) { > + odp_packet_to_buffer(pkt))) { > abort(); > } > return (posted) ? PKT_POSTED : PKT_CONTINUE; > @@ -764,7 +764,7 @@ pkt_disposition_e do_ipsec_in_finish(odp_packet_t pkt, > int trl_len = 0; > > /* Check crypto result */ > - event = odp_buffer_from_packet(pkt); > + event = odp_packet_to_buffer(pkt); > odp_crypto_get_operation_compl_status(event, &cipher_rc, &auth_rc); > if (!is_crypto_compl_status_ok(&cipher_rc)) > return PKT_DROP; > @@ -935,7 +935,7 @@ pkt_disposition_e do_ipsec_out_classify(odp_packet_t > pkt, > > /* Send packet to the atmoic queue to assign sequence numbers */ > *skip = FALSE; > - odp_queue_enq(seqnumq, odp_buffer_from_packet(pkt)); > + odp_queue_enq(seqnumq, odp_packet_to_buffer(pkt)); > > return PKT_POSTED; > } > @@ -974,7 +974,7 @@ pkt_disposition_e do_ipsec_out_seq(odp_packet_t pkt, > /* Issue crypto request */ > if (odp_crypto_operation(&ctx->ipsec.params, > &posted, > - odp_buffer_from_packet(pkt))) { > + odp_packet_to_buffer(pkt))) { > abort(); > } > return (posted) ? PKT_POSTED : PKT_CONTINUE; > @@ -998,7 +998,7 @@ pkt_disposition_e do_ipsec_out_finish(odp_packet_t > pkt, > odph_ipv4hdr_t *ip; > > /* Check crypto result */ > - event = odp_buffer_from_packet(pkt); > + event = odp_packet_to_buffer(pkt); > odp_crypto_get_operation_compl_status(event, &cipher_rc, &auth_rc); > if (!is_crypto_compl_status_ok(&cipher_rc)) > return PKT_DROP; > diff --git a/helper/include/odph_packet.h b/helper/include/odph_packet.h > index c18f48d..3d53593 100644 > --- a/helper/include/odph_packet.h > +++ b/helper/include/odph_packet.h > @@ -31,7 +31,7 @@ extern "C" { > */ > static inline int odph_packet_is_valid(odp_packet_t pkt) > { > - odp_buffer_t buf = odp_buffer_from_packet(pkt); > + odp_buffer_t buf = odp_packet_to_buffer(pkt); > > return odp_buffer_is_valid(buf); > } > @@ -67,7 +67,7 @@ static inline odp_packet_t > odph_packet_alloc(odp_buffer_pool_t pool_id) > */ > static inline void odph_packet_free(odp_packet_t pkt) > { > - odp_buffer_t buf = odp_buffer_from_packet(pkt); > + odp_buffer_t buf = odp_packet_to_buffer(pkt); > > odp_buffer_free(buf); > } > @@ -84,7 +84,7 @@ static inline void odph_packet_free(odp_packet_t pkt) > */ > static inline size_t odph_packet_buf_size(odp_packet_t pkt) > { > - odp_buffer_t buf = odp_buffer_from_packet(pkt); > + odp_buffer_t buf = odp_packet_to_buffer(pkt); > > return odp_buffer_size(buf); > } > diff --git a/platform/linux-generic/include/api/odp_packet.h > b/platform/linux-generic/include/api/odp_packet.h > index 316279b..8204000 100644 > --- a/platform/linux-generic/include/api/odp_packet.h > +++ b/platform/linux-generic/include/api/odp_packet.h > @@ -63,7 +63,7 @@ typedef struct odp_packet_seg_info_t { > void odp_packet_init(odp_packet_t pkt); > > /** > - * Convert from packet handle to buffer handle > + * Convert a buffer handle to a packet handle > * > * @param buf Buffer handle > * > @@ -72,13 +72,13 @@ void odp_packet_init(odp_packet_t pkt); > odp_packet_t odp_packet_from_buffer(odp_buffer_t buf); > > /** > - * Convert from buffer handle to packet handle > + * Convert a packet handle to a buffer handle > * > * @param pkt Packet handle > * > * @return Buffer handle > */ > -odp_buffer_t odp_buffer_from_packet(odp_packet_t pkt); > +odp_buffer_t odp_packet_to_buffer(odp_packet_t pkt); > > /** > * Set the packet length > diff --git a/platform/linux-generic/odp_crypto.c b/platform/linux- > generic/odp_crypto.c > index b37ad6b..1475437 100644 > --- a/platform/linux-generic/odp_crypto.c > +++ b/platform/linux-generic/odp_crypto.c > @@ -367,9 +367,9 @@ odp_crypto_operation(odp_crypto_op_params_t *params, > if (odp_unlikely(ODP_PACKET_INVALID == params->out_pkt)) > abort(); > odp_packet_copy(params->out_pkt, params->pkt); > - if (completion_event == odp_buffer_from_packet(params->pkt)) > + if (completion_event == odp_packet_to_buffer(params->pkt)) > completion_event = > - odp_buffer_from_packet(params->out_pkt); > + odp_packet_to_buffer(params->out_pkt); > odph_packet_free(params->pkt); > params->pkt = ODP_PACKET_INVALID; > } > diff --git a/platform/linux-generic/odp_packet.c b/platform/linux- > generic/odp_packet.c > index 435bc8b..82ea879 100644 > --- a/platform/linux-generic/odp_packet.c > +++ b/platform/linux-generic/odp_packet.c > @@ -41,7 +41,7 @@ odp_packet_t odp_packet_from_buffer(odp_buffer_t buf) > return (odp_packet_t)buf; > } > > -odp_buffer_t odp_buffer_from_packet(odp_packet_t pkt) > +odp_buffer_t odp_packet_to_buffer(odp_packet_t pkt) > { > return (odp_buffer_t)pkt; > } > @@ -58,7 +58,7 @@ size_t odp_packet_get_len(odp_packet_t pkt) > > uint8_t *odp_packet_addr(odp_packet_t pkt) > { > - return odp_buffer_addr(odp_buffer_from_packet(pkt)); > + return odp_buffer_addr(odp_packet_to_buffer(pkt)); > } > > uint8_t *odp_packet_data(odp_packet_t pkt) > @@ -381,8 +381,8 @@ int odp_packet_copy(odp_packet_t pkt_dst, odp_packet_t > pkt_src) > pkt_hdr_dst->buf_hdr.cur_offset = pkt_hdr_src->buf_hdr.cur_offset; > > /* Create a copy of the scatter list */ > - odp_buffer_copy_scatter(odp_buffer_from_packet(pkt_dst), > - odp_buffer_from_packet(pkt_src)); > + odp_buffer_copy_scatter(odp_packet_to_buffer(pkt_dst), > + odp_packet_to_buffer(pkt_src)); > > return 0; > } > diff --git a/platform/linux-generic/odp_packet_io.c b/platform/linux- > generic/odp_packet_io.c > index 0c30f0f..d6f86ce 100644 > --- a/platform/linux-generic/odp_packet_io.c > +++ b/platform/linux-generic/odp_packet_io.c > @@ -431,11 +431,11 @@ odp_buffer_hdr_t *pktin_dequeue(queue_entry_t > *qentry) > > if (pkts > 0) { > pkt = pkt_tbl[0]; > - buf = odp_buffer_from_packet(pkt); > + buf = odp_packet_to_buffer(pkt); > buf_hdr = odp_buf_to_hdr(buf); > > for (i = 1, j = 0; i < pkts; ++i) { > - buf = odp_buffer_from_packet(pkt_tbl[i]); > + buf = odp_packet_to_buffer(pkt_tbl[i]); > tmp_hdr_tbl[j++] = odp_buf_to_hdr(buf); > } > queue_enq_multi(qentry, tmp_hdr_tbl, j); > @@ -467,7 +467,7 @@ int pktin_deq_multi(queue_entry_t *qentry, > odp_buffer_hdr_t *buf_hdr[], int num) > QUEUE_MULTI_MAX); > if (pkts > 0) { > for (i = 0; i < pkts; ++i) { > - buf = odp_buffer_from_packet(pkt_tbl[i]); > + buf = odp_packet_to_buffer(pkt_tbl[i]); > tmp_hdr_tbl[i] = odp_buf_to_hdr(buf); > } > queue_enq_multi(qentry, tmp_hdr_tbl, pkts); > -- > 2.1.1
Merged! Maxim. On 10/23/2014 12:11 PM, Savolainen, Petri (NSN - FI/Espoo) wrote: > Ping. It's time to merge! This is now in the spec. > > >> -----Original Message----- >> From: ext Petri Savolainen [mailto:petri.savolainen@linaro.org] >> Sent: Monday, October 06, 2014 5:26 PM >> To: lng-odp@lists.linaro.org >> Cc: Petri Savolainen >> Subject: [PATCH] Rename buffer_from_packet function >> >> Rename odp_buffer_from_packet() to odp_packet_to_buffer(). >> It's a function of packet API vs buffer API. >> >> Signed-off-by: Petri Savolainen <petri.savolainen@linaro.org> >> --- >> example/generator/odp_generator.c | 2 +- >> example/ipsec/odp_ipsec.c | 10 +++++----- >> helper/include/odph_packet.h | 6 +++--- >> platform/linux-generic/include/api/odp_packet.h | 6 +++--- >> platform/linux-generic/odp_crypto.c | 4 ++-- >> platform/linux-generic/odp_packet.c | 8 ++++---- >> platform/linux-generic/odp_packet_io.c | 6 +++--- >> 7 files changed, 21 insertions(+), 21 deletions(-) >> >> diff --git a/example/generator/odp_generator.c >> b/example/generator/odp_generator.c >> index 6055324..5538d0c 100644 >> --- a/example/generator/odp_generator.c >> +++ b/example/generator/odp_generator.c >> @@ -397,7 +397,7 @@ static void print_pkts(int thr, odp_packet_t >> pkt_tbl[], unsigned len) >> >> odp_atomic_inc_u64(&counters.ip); >> rlen += sprintf(msg, "receive Packet proto:IP "); >> - buf = odp_buffer_addr(odp_buffer_from_packet(pkt)); >> + buf = odp_buffer_addr(odp_packet_to_buffer(pkt)); >> ip = (odph_ipv4hdr_t *)(buf + odp_packet_l3_offset(pkt)); >> rlen += sprintf(msg + rlen, "id %d ", >> odp_be_to_cpu_16(ip->id)); >> diff --git a/example/ipsec/odp_ipsec.c b/example/ipsec/odp_ipsec.c >> index ec6c87a..56539ba 100644 >> --- a/example/ipsec/odp_ipsec.c >> +++ b/example/ipsec/odp_ipsec.c >> @@ -738,7 +738,7 @@ pkt_disposition_e do_ipsec_in_classify(odp_packet_t >> pkt, >> *skip = FALSE; >> if (odp_crypto_operation(¶ms, >> &posted, >> - odp_buffer_from_packet(pkt))) { >> + odp_packet_to_buffer(pkt))) { >> abort(); >> } >> return (posted) ? PKT_POSTED : PKT_CONTINUE; >> @@ -764,7 +764,7 @@ pkt_disposition_e do_ipsec_in_finish(odp_packet_t pkt, >> int trl_len = 0; >> >> /* Check crypto result */ >> - event = odp_buffer_from_packet(pkt); >> + event = odp_packet_to_buffer(pkt); >> odp_crypto_get_operation_compl_status(event, &cipher_rc, &auth_rc); >> if (!is_crypto_compl_status_ok(&cipher_rc)) >> return PKT_DROP; >> @@ -935,7 +935,7 @@ pkt_disposition_e do_ipsec_out_classify(odp_packet_t >> pkt, >> >> /* Send packet to the atmoic queue to assign sequence numbers */ >> *skip = FALSE; >> - odp_queue_enq(seqnumq, odp_buffer_from_packet(pkt)); >> + odp_queue_enq(seqnumq, odp_packet_to_buffer(pkt)); >> >> return PKT_POSTED; >> } >> @@ -974,7 +974,7 @@ pkt_disposition_e do_ipsec_out_seq(odp_packet_t pkt, >> /* Issue crypto request */ >> if (odp_crypto_operation(&ctx->ipsec.params, >> &posted, >> - odp_buffer_from_packet(pkt))) { >> + odp_packet_to_buffer(pkt))) { >> abort(); >> } >> return (posted) ? PKT_POSTED : PKT_CONTINUE; >> @@ -998,7 +998,7 @@ pkt_disposition_e do_ipsec_out_finish(odp_packet_t >> pkt, >> odph_ipv4hdr_t *ip; >> >> /* Check crypto result */ >> - event = odp_buffer_from_packet(pkt); >> + event = odp_packet_to_buffer(pkt); >> odp_crypto_get_operation_compl_status(event, &cipher_rc, &auth_rc); >> if (!is_crypto_compl_status_ok(&cipher_rc)) >> return PKT_DROP; >> diff --git a/helper/include/odph_packet.h b/helper/include/odph_packet.h >> index c18f48d..3d53593 100644 >> --- a/helper/include/odph_packet.h >> +++ b/helper/include/odph_packet.h >> @@ -31,7 +31,7 @@ extern "C" { >> */ >> static inline int odph_packet_is_valid(odp_packet_t pkt) >> { >> - odp_buffer_t buf = odp_buffer_from_packet(pkt); >> + odp_buffer_t buf = odp_packet_to_buffer(pkt); >> >> return odp_buffer_is_valid(buf); >> } >> @@ -67,7 +67,7 @@ static inline odp_packet_t >> odph_packet_alloc(odp_buffer_pool_t pool_id) >> */ >> static inline void odph_packet_free(odp_packet_t pkt) >> { >> - odp_buffer_t buf = odp_buffer_from_packet(pkt); >> + odp_buffer_t buf = odp_packet_to_buffer(pkt); >> >> odp_buffer_free(buf); >> } >> @@ -84,7 +84,7 @@ static inline void odph_packet_free(odp_packet_t pkt) >> */ >> static inline size_t odph_packet_buf_size(odp_packet_t pkt) >> { >> - odp_buffer_t buf = odp_buffer_from_packet(pkt); >> + odp_buffer_t buf = odp_packet_to_buffer(pkt); >> >> return odp_buffer_size(buf); >> } >> diff --git a/platform/linux-generic/include/api/odp_packet.h >> b/platform/linux-generic/include/api/odp_packet.h >> index 316279b..8204000 100644 >> --- a/platform/linux-generic/include/api/odp_packet.h >> +++ b/platform/linux-generic/include/api/odp_packet.h >> @@ -63,7 +63,7 @@ typedef struct odp_packet_seg_info_t { >> void odp_packet_init(odp_packet_t pkt); >> >> /** >> - * Convert from packet handle to buffer handle >> + * Convert a buffer handle to a packet handle >> * >> * @param buf Buffer handle >> * >> @@ -72,13 +72,13 @@ void odp_packet_init(odp_packet_t pkt); >> odp_packet_t odp_packet_from_buffer(odp_buffer_t buf); >> >> /** >> - * Convert from buffer handle to packet handle >> + * Convert a packet handle to a buffer handle >> * >> * @param pkt Packet handle >> * >> * @return Buffer handle >> */ >> -odp_buffer_t odp_buffer_from_packet(odp_packet_t pkt); >> +odp_buffer_t odp_packet_to_buffer(odp_packet_t pkt); >> >> /** >> * Set the packet length >> diff --git a/platform/linux-generic/odp_crypto.c b/platform/linux- >> generic/odp_crypto.c >> index b37ad6b..1475437 100644 >> --- a/platform/linux-generic/odp_crypto.c >> +++ b/platform/linux-generic/odp_crypto.c >> @@ -367,9 +367,9 @@ odp_crypto_operation(odp_crypto_op_params_t *params, >> if (odp_unlikely(ODP_PACKET_INVALID == params->out_pkt)) >> abort(); >> odp_packet_copy(params->out_pkt, params->pkt); >> - if (completion_event == odp_buffer_from_packet(params->pkt)) >> + if (completion_event == odp_packet_to_buffer(params->pkt)) >> completion_event = >> - odp_buffer_from_packet(params->out_pkt); >> + odp_packet_to_buffer(params->out_pkt); >> odph_packet_free(params->pkt); >> params->pkt = ODP_PACKET_INVALID; >> } >> diff --git a/platform/linux-generic/odp_packet.c b/platform/linux- >> generic/odp_packet.c >> index 435bc8b..82ea879 100644 >> --- a/platform/linux-generic/odp_packet.c >> +++ b/platform/linux-generic/odp_packet.c >> @@ -41,7 +41,7 @@ odp_packet_t odp_packet_from_buffer(odp_buffer_t buf) >> return (odp_packet_t)buf; >> } >> >> -odp_buffer_t odp_buffer_from_packet(odp_packet_t pkt) >> +odp_buffer_t odp_packet_to_buffer(odp_packet_t pkt) >> { >> return (odp_buffer_t)pkt; >> } >> @@ -58,7 +58,7 @@ size_t odp_packet_get_len(odp_packet_t pkt) >> >> uint8_t *odp_packet_addr(odp_packet_t pkt) >> { >> - return odp_buffer_addr(odp_buffer_from_packet(pkt)); >> + return odp_buffer_addr(odp_packet_to_buffer(pkt)); >> } >> >> uint8_t *odp_packet_data(odp_packet_t pkt) >> @@ -381,8 +381,8 @@ int odp_packet_copy(odp_packet_t pkt_dst, odp_packet_t >> pkt_src) >> pkt_hdr_dst->buf_hdr.cur_offset = pkt_hdr_src->buf_hdr.cur_offset; >> >> /* Create a copy of the scatter list */ >> - odp_buffer_copy_scatter(odp_buffer_from_packet(pkt_dst), >> - odp_buffer_from_packet(pkt_src)); >> + odp_buffer_copy_scatter(odp_packet_to_buffer(pkt_dst), >> + odp_packet_to_buffer(pkt_src)); >> >> return 0; >> } >> diff --git a/platform/linux-generic/odp_packet_io.c b/platform/linux- >> generic/odp_packet_io.c >> index 0c30f0f..d6f86ce 100644 >> --- a/platform/linux-generic/odp_packet_io.c >> +++ b/platform/linux-generic/odp_packet_io.c >> @@ -431,11 +431,11 @@ odp_buffer_hdr_t *pktin_dequeue(queue_entry_t >> *qentry) >> >> if (pkts > 0) { >> pkt = pkt_tbl[0]; >> - buf = odp_buffer_from_packet(pkt); >> + buf = odp_packet_to_buffer(pkt); >> buf_hdr = odp_buf_to_hdr(buf); >> >> for (i = 1, j = 0; i < pkts; ++i) { >> - buf = odp_buffer_from_packet(pkt_tbl[i]); >> + buf = odp_packet_to_buffer(pkt_tbl[i]); >> tmp_hdr_tbl[j++] = odp_buf_to_hdr(buf); >> } >> queue_enq_multi(qentry, tmp_hdr_tbl, j); >> @@ -467,7 +467,7 @@ int pktin_deq_multi(queue_entry_t *qentry, >> odp_buffer_hdr_t *buf_hdr[], int num) >> QUEUE_MULTI_MAX); >> if (pkts > 0) { >> for (i = 0; i < pkts; ++i) { >> - buf = odp_buffer_from_packet(pkt_tbl[i]); >> + buf = odp_packet_to_buffer(pkt_tbl[i]); >> tmp_hdr_tbl[i] = odp_buf_to_hdr(buf); >> } >> queue_enq_multi(qentry, tmp_hdr_tbl, pkts); >> -- >> 2.1.1 > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/lng-odp
diff --git a/example/generator/odp_generator.c b/example/generator/odp_generator.c index 6055324..5538d0c 100644 --- a/example/generator/odp_generator.c +++ b/example/generator/odp_generator.c @@ -397,7 +397,7 @@ static void print_pkts(int thr, odp_packet_t pkt_tbl[], unsigned len) odp_atomic_inc_u64(&counters.ip); rlen += sprintf(msg, "receive Packet proto:IP "); - buf = odp_buffer_addr(odp_buffer_from_packet(pkt)); + buf = odp_buffer_addr(odp_packet_to_buffer(pkt)); ip = (odph_ipv4hdr_t *)(buf + odp_packet_l3_offset(pkt)); rlen += sprintf(msg + rlen, "id %d ", odp_be_to_cpu_16(ip->id)); diff --git a/example/ipsec/odp_ipsec.c b/example/ipsec/odp_ipsec.c index ec6c87a..56539ba 100644 --- a/example/ipsec/odp_ipsec.c +++ b/example/ipsec/odp_ipsec.c @@ -738,7 +738,7 @@ pkt_disposition_e do_ipsec_in_classify(odp_packet_t pkt, *skip = FALSE; if (odp_crypto_operation(¶ms, &posted, - odp_buffer_from_packet(pkt))) { + odp_packet_to_buffer(pkt))) { abort(); } return (posted) ? PKT_POSTED : PKT_CONTINUE; @@ -764,7 +764,7 @@ pkt_disposition_e do_ipsec_in_finish(odp_packet_t pkt, int trl_len = 0; /* Check crypto result */ - event = odp_buffer_from_packet(pkt); + event = odp_packet_to_buffer(pkt); odp_crypto_get_operation_compl_status(event, &cipher_rc, &auth_rc); if (!is_crypto_compl_status_ok(&cipher_rc)) return PKT_DROP; @@ -935,7 +935,7 @@ pkt_disposition_e do_ipsec_out_classify(odp_packet_t pkt, /* Send packet to the atmoic queue to assign sequence numbers */ *skip = FALSE; - odp_queue_enq(seqnumq, odp_buffer_from_packet(pkt)); + odp_queue_enq(seqnumq, odp_packet_to_buffer(pkt)); return PKT_POSTED; } @@ -974,7 +974,7 @@ pkt_disposition_e do_ipsec_out_seq(odp_packet_t pkt, /* Issue crypto request */ if (odp_crypto_operation(&ctx->ipsec.params, &posted, - odp_buffer_from_packet(pkt))) { + odp_packet_to_buffer(pkt))) { abort(); } return (posted) ? PKT_POSTED : PKT_CONTINUE; @@ -998,7 +998,7 @@ pkt_disposition_e do_ipsec_out_finish(odp_packet_t pkt, odph_ipv4hdr_t *ip; /* Check crypto result */ - event = odp_buffer_from_packet(pkt); + event = odp_packet_to_buffer(pkt); odp_crypto_get_operation_compl_status(event, &cipher_rc, &auth_rc); if (!is_crypto_compl_status_ok(&cipher_rc)) return PKT_DROP; diff --git a/helper/include/odph_packet.h b/helper/include/odph_packet.h index c18f48d..3d53593 100644 --- a/helper/include/odph_packet.h +++ b/helper/include/odph_packet.h @@ -31,7 +31,7 @@ extern "C" { */ static inline int odph_packet_is_valid(odp_packet_t pkt) { - odp_buffer_t buf = odp_buffer_from_packet(pkt); + odp_buffer_t buf = odp_packet_to_buffer(pkt); return odp_buffer_is_valid(buf); } @@ -67,7 +67,7 @@ static inline odp_packet_t odph_packet_alloc(odp_buffer_pool_t pool_id) */ static inline void odph_packet_free(odp_packet_t pkt) { - odp_buffer_t buf = odp_buffer_from_packet(pkt); + odp_buffer_t buf = odp_packet_to_buffer(pkt); odp_buffer_free(buf); } @@ -84,7 +84,7 @@ static inline void odph_packet_free(odp_packet_t pkt) */ static inline size_t odph_packet_buf_size(odp_packet_t pkt) { - odp_buffer_t buf = odp_buffer_from_packet(pkt); + odp_buffer_t buf = odp_packet_to_buffer(pkt); return odp_buffer_size(buf); } diff --git a/platform/linux-generic/include/api/odp_packet.h b/platform/linux-generic/include/api/odp_packet.h index 316279b..8204000 100644 --- a/platform/linux-generic/include/api/odp_packet.h +++ b/platform/linux-generic/include/api/odp_packet.h @@ -63,7 +63,7 @@ typedef struct odp_packet_seg_info_t { void odp_packet_init(odp_packet_t pkt); /** - * Convert from packet handle to buffer handle + * Convert a buffer handle to a packet handle * * @param buf Buffer handle * @@ -72,13 +72,13 @@ void odp_packet_init(odp_packet_t pkt); odp_packet_t odp_packet_from_buffer(odp_buffer_t buf); /** - * Convert from buffer handle to packet handle + * Convert a packet handle to a buffer handle * * @param pkt Packet handle * * @return Buffer handle */ -odp_buffer_t odp_buffer_from_packet(odp_packet_t pkt); +odp_buffer_t odp_packet_to_buffer(odp_packet_t pkt); /** * Set the packet length diff --git a/platform/linux-generic/odp_crypto.c b/platform/linux-generic/odp_crypto.c index b37ad6b..1475437 100644 --- a/platform/linux-generic/odp_crypto.c +++ b/platform/linux-generic/odp_crypto.c @@ -367,9 +367,9 @@ odp_crypto_operation(odp_crypto_op_params_t *params, if (odp_unlikely(ODP_PACKET_INVALID == params->out_pkt)) abort(); odp_packet_copy(params->out_pkt, params->pkt); - if (completion_event == odp_buffer_from_packet(params->pkt)) + if (completion_event == odp_packet_to_buffer(params->pkt)) completion_event = - odp_buffer_from_packet(params->out_pkt); + odp_packet_to_buffer(params->out_pkt); odph_packet_free(params->pkt); params->pkt = ODP_PACKET_INVALID; } diff --git a/platform/linux-generic/odp_packet.c b/platform/linux-generic/odp_packet.c index 435bc8b..82ea879 100644 --- a/platform/linux-generic/odp_packet.c +++ b/platform/linux-generic/odp_packet.c @@ -41,7 +41,7 @@ odp_packet_t odp_packet_from_buffer(odp_buffer_t buf) return (odp_packet_t)buf; } -odp_buffer_t odp_buffer_from_packet(odp_packet_t pkt) +odp_buffer_t odp_packet_to_buffer(odp_packet_t pkt) { return (odp_buffer_t)pkt; } @@ -58,7 +58,7 @@ size_t odp_packet_get_len(odp_packet_t pkt) uint8_t *odp_packet_addr(odp_packet_t pkt) { - return odp_buffer_addr(odp_buffer_from_packet(pkt)); + return odp_buffer_addr(odp_packet_to_buffer(pkt)); } uint8_t *odp_packet_data(odp_packet_t pkt) @@ -381,8 +381,8 @@ int odp_packet_copy(odp_packet_t pkt_dst, odp_packet_t pkt_src) pkt_hdr_dst->buf_hdr.cur_offset = pkt_hdr_src->buf_hdr.cur_offset; /* Create a copy of the scatter list */ - odp_buffer_copy_scatter(odp_buffer_from_packet(pkt_dst), - odp_buffer_from_packet(pkt_src)); + odp_buffer_copy_scatter(odp_packet_to_buffer(pkt_dst), + odp_packet_to_buffer(pkt_src)); return 0; } diff --git a/platform/linux-generic/odp_packet_io.c b/platform/linux-generic/odp_packet_io.c index 0c30f0f..d6f86ce 100644 --- a/platform/linux-generic/odp_packet_io.c +++ b/platform/linux-generic/odp_packet_io.c @@ -431,11 +431,11 @@ odp_buffer_hdr_t *pktin_dequeue(queue_entry_t *qentry) if (pkts > 0) { pkt = pkt_tbl[0]; - buf = odp_buffer_from_packet(pkt); + buf = odp_packet_to_buffer(pkt); buf_hdr = odp_buf_to_hdr(buf); for (i = 1, j = 0; i < pkts; ++i) { - buf = odp_buffer_from_packet(pkt_tbl[i]); + buf = odp_packet_to_buffer(pkt_tbl[i]); tmp_hdr_tbl[j++] = odp_buf_to_hdr(buf); } queue_enq_multi(qentry, tmp_hdr_tbl, j); @@ -467,7 +467,7 @@ int pktin_deq_multi(queue_entry_t *qentry, odp_buffer_hdr_t *buf_hdr[], int num) QUEUE_MULTI_MAX); if (pkts > 0) { for (i = 0; i < pkts; ++i) { - buf = odp_buffer_from_packet(pkt_tbl[i]); + buf = odp_packet_to_buffer(pkt_tbl[i]); tmp_hdr_tbl[i] = odp_buf_to_hdr(buf); } queue_enq_multi(qentry, tmp_hdr_tbl, pkts);
Rename odp_buffer_from_packet() to odp_packet_to_buffer(). It's a function of packet API vs buffer API. Signed-off-by: Petri Savolainen <petri.savolainen@linaro.org> --- example/generator/odp_generator.c | 2 +- example/ipsec/odp_ipsec.c | 10 +++++----- helper/include/odph_packet.h | 6 +++--- platform/linux-generic/include/api/odp_packet.h | 6 +++--- platform/linux-generic/odp_crypto.c | 4 ++-- platform/linux-generic/odp_packet.c | 8 ++++---- platform/linux-generic/odp_packet_io.c | 6 +++--- 7 files changed, 21 insertions(+), 21 deletions(-)